King safety evaluation

[emadsen]

take into account "stacked" attackers like a Rook behind a Queen

That's a good point and something my implementation is blind to. My code would only see coordination if a bishop and queen, for example, were targeting the same square near the opponent king but from different rays. Understanding stacked attacks via x-rays would be an improvement for me.

There's just so much detail in these evaluation terms and how they're implemented. I like it though. Even if hand-crafted-eval is weaker than neural networks, I like the direct line from idea to code to confirming strength increase via gauntlet tournaments. It's satisfying to see your engine develop a king attack due to eval terms you just added. Though a bit of a grind to tune all the params to ensure these attacks gain more than they lose.

Neural networks are cool. And stronger than hand-crafted-eval. But one has to accept a fogginess when it comes to reasoning about how they actually evaluate positions.

[Ferdy]

Hi.

During the last couple of days I've been struggling with writing a working king safety evaluation. Every time I try to test it against the oldest version of my engine it seems to either loose 30-60 elo or only gain a negligible 5-10 elo (as compared to the results of others's implementations that get 40-60 elo), and I dont know if it's my implementation or the weights I'm using.
My implementation is as follows:
1. Loop through the files near the king (king file plus the two adjacent files). Here i give a penalty of 25 cp if either side is missing a pawn on that file (semi-open), and 60cp if both do (open). I also give an advancement penalty ranging from 5 to 45 based on the rank of the pawn of the side to move. Additionally, I give a penalty based on how close the opponent's pawn on that file is to the king (ranging from 0 to 20). I halve the two latter scores if the two pawns on the file are directly blocking each others's advancement.
2. I scale the score for the pawn structure around the king based on the opponents's material (scalar: opponent_material/max_possible_material).
3. From mobility I have knowledge of attacks to the king, and I score this with a safety table if there are more than two attackers and the opponent has a queen.

I don't score any king safety in the endgame yet, but I am planning on implementing some king pawn tropism to make the king protect pawns late in the game.

The above implementation is heavily inspired by the wiki post: https://www.chessprogramming.org/King_Safety, and the safety table is done exactly as suggested on that page, with the same weights.

My eval at the moment consists of material, piece square tables, mobility and space, so I am thinking that king safety should be the next step.

Has anybody else had problems with creating a proper king safety evaluation? And is there something that seems wrong with my implementation above?

Thanks in advance

PS: I have checked symmetry with 300 positions, where i did the eval, mirrored the board, and did it again, and this is correct. Therefore I can at least outrule that bug.

Don't put everything at once, implement one after another and measure. 5 to 10 elo is not bad, take it. If your test is a failure in certain implementation, learn from it. Then continue implementing and testing.

Have a look on your search pruning/reduction margin/conditions, move ordering etc. that are dependent on the evaluation. They might need new values or conditions to obtain some gains. If you touch the evaluation, try to also touch the search and vice versa.

Isolate the time and try to test you eval changes using fixed depth testing, let's see if your new eval feature can gain anything.

[niel5946]

Thanks to everyone for the useful answers

After a couple of days trying different changes, deletions and additions, I decided to postpone the implementation of king safety, but I have not been idle
I have written a pretty simplistic SPSA tuning framework based on texel tuning. It takes a vector of parameters and optimizes them. It is multithreaded and works with up to (at least) 64 threads, although the performance decreases as the number of threads becomes larger than the number of CPU cores.
Due to its simplicity there are two issues:
1. It is not very effective when optimizing parameters with a big difference in value. When I tested it with piece values I had to optimize the queen values (multiple since there are both a middlegame and endgame value) separately from pawns, knights bishops and rooks.
2. The SPSA parameters that determine cn and an (see https://en.wikipedia.org/wiki/Simultane ... roximation) has to be set by the user at the moment. These are called C_END and R_END. I intend to automatically determine these based on the evaluation function's sensitivity to changes in each individual parameter and its value.
I have tried to make the implementation very little engine-specific, in hopes that it will be easy for others to use in their own development .
I also intend to change the algorithm to a mix between Adam and SPSA, which is not surprisingly called AdamSPSA (ref. https://arxiv.org/pdf/1910.03591.pdf see page 3 and 4). The reason for this is because convergence were better the first time I created an evaluation tuner.

I just thought I would post about it here since it seems like a rather big part of creating a working king safety evaluation term.

The links to the two files are here: https://github.com/BimmerBass/Loki/blob ... ki/texel.h and https://github.com/BimmerBass/Loki/blob ... /texel.cpp. I would love to get some feedback about the implementation in case something is missing or faulty


NOTE: Since the branch is currently being worked upon, the code is pretty messy with a ton of commented out parts and probably some irrelevant comments which I've forgotten to delete when deleting the code they explained.

I hope this can be of help to others who might have a hard time determining good evaluation weights.