lithander wrote: ↑Sat Jun 18, 2022 3:53 am
Sounds like you're making great progress! I'm really curious how strong Blunder 8 will end up being. Is it going to have feature parity with 7.6?
Thanks! The plan is that it will have feature parity, plus IID. But I don't expect IID to contribute much, since it only got about ~13 Elo in self-play.
lithander wrote: ↑Sat Jun 18, 2022 3:53 am
Maybe King Safety is especially complicated (Leorik doesn't use it yet) or maybe it's because I didn't take a calculus course recently but I don't understand why you can't just use the same simple tuner that basically only multiplies a vector of features with a vector of weights and optimizes those weights to minimize the MSE. I just add "pawn structure" features to the vector and "mobility" features and as the size of the feature-vector increases I also get more weights that I then use to guide my actual implementation that's used in the engine. It reminds me of the saying: "when you have a hammer, everything looks like a nail" but so far it seems to work well enough.
Well, you
technically could, depending on the approach you wanted to take for calculating king safety. But for most of the approaches I've seen, modeling the evaluation as just the dot product between a weight and feature vector wouldn't quite work.
The reason why is because, unlike the normal weights, the weights I have that are related to king safety are not directly taken and folded into the middle and endgame score. Instead, they're first plugged into the formula I showed above, and then added to the total evaluation score. This seems like it shouldn't make things that much more complicated, but as far as I could think of, I couldn't find a clever way to model this using
only the dot product between the weights and the features vector. Because what corresponding entries would go in the feature vector?
To explain a little more, the extra weights I added were these:
Code: Select all
var OuterRingAttackPoints = [5]int16{0, 1, 0, 1, 1}
var InnerRingAttackPoints = [5]int16{0, 3, 4, 5, 3}
Which are the bonuses multiplied by the number of squares a piece attacks around the king, indexed by piece type. For example, the queen:
Code: Select all
outerRingAttacks := moves & eval.KingZones[color^1].OuterRing
innerRingAttacks := moves & eval.KingZones[color^1].InnerRing
if outerRingAttacks != 0 || innerRingAttacks != 0 {
eval.KingAttackers[color]++
eval.KingAttackPoints[color] += uint16(outerRingAttacks.CountBits()) * uint16(OuterRingAttackPoints[Queen])
eval.KingAttackPoints[color] += uint16(innerRingAttacks.CountBits()) * uint16(InnerRingAttackPoints[Queen])
}
And for each king:
Code: Select all
evalKing(pos, White, pos.Pieces[White][King].Msb(), &eval)
evalKing(pos, Black, pos.Pieces[Black][King].Msb(), &eval)
The king safety penalty is computed:
Code: Select all
// Evaluate the score of a king.
func evalKing(pos *Position, color, sq uint8, eval *Eval) {
// Take all the king saftey points collected for the enemy,
// and see what kind of penatly we should get.
enemyPoints := eval.KingAttackPoints[color^1]
penatly := int16((enemyPoints * enemyPoints) / 4)
if eval.KingAttackers[color^1] >= 2 && pos.Pieces[color^1][Queen] != 0 {
eval.MGScores[color] -= penatly
}
}
Now suppose we took the normal approach and computed the difference between the total number of squares a white knight is attacking in the outer ring, minus the total number of squares a black knight is attacking, the difference between the total numbers of squares a white bishop is attacking, minus the total number of squares a black bishop is attacking, etc. And suppose we got a feature vector where part of it looked like this:
Which means there's one total black knight outer ring attack, 2 total white bishop outer ring attacks, etc. Now if we're doing things normally, we'd just compute the dot product between the above section of the features vector times the corresponding weights in the weight vector:
Which gives 30. Now, 30 isn't the right answer. If we're following the above formula we'd need to square 30 and then divide it by 4. But as soon as we do this, we're no longer strictly computing the dot product. We're computing the dot product
plus the dot product of those specific parts of the weight and feature vectors, squared. But that means our evaluation function model is now different, and so the partial derivative will be different as well. And there's no way to "fold" the squaring into each individual feature so we can keep using only the dot product since the operation of taking the square doesn't distribute like addition or multiplication, or division.
Let me know if that helps at all since I know it was a lot. Also let me know if I'm missing something obvious here since I had to spend the better part of yesterday evening working on this, so I might have some tunnel vision.
It'd be interesting to try to come up with a king safety evaluation that's only linear. I'm not aware of a current approach that strictly is, and any approach I tried to come up with didn't capture the notation of king safety being a non-linear score, where the score inflates exponentially. This was an approach to the problem I didn't spend as much time on, since I better knew how to tackle the problem of computing new partials. Perhaps following the spirit of Leorik you could come up with something a bit more novel and keep the evaluation strictly linear.
