Endgame evaluation

[xr_a_y]

In Minic I try to build some endgame using a material hash and "known" state of the game.

For example, I set KRK as a win for the side with the rook but KNKN as a draw.
For some configuration I also use a helper evaluation feature (like drive in the good corner for KBNK or drive to edge for KQK or KRK)

I feel like all of this is wrong because I should verify more stuff on a configuration before going to a conclusion. For example a KQKB can be a draw if next possible move if BxQ. So this kind of thing shall only be used after a qsearch. Even after qsearch I guess I have to check for stalemate ?

How do you handle those kind of things ?

[AlvaroBegue]

There are conditions when you can simply return a value without further search. Some ICCA paper by the authors of DarkThought in the 90s called this "interior-node recognizers": https://www.chessprogramming.org/Interi ... Recognizer

For situations where you are not sure (say KQKB), you can still have a heuristic evaluation, but you let the search do its thing if you still have some depth left.

[xr_a_y]

I want to use this kind of thing for both interior node recognizer, thus during the search but only for sure draws, and for evaluation.
I want some endgame being score more or less than their actual material evaluation and I want some helper being use sometimes.

For example, I don't wanna score a winning KRRKR only +5, I want it to be +10
I don't wanna score a hard to win KRKN +2, I want it to be only +1

so I have to do this on eval too and on many configurations.

[jdart]

Tablebases remove the need to have special case evaluators at least near the root of the tree, because generally you don't want to probe everywhere.

The primary use of static eval is in the qsearch, so at that point you don't have the possible capture problem. You can try to improve eval accuracy there but there are still likely going to be cases where you get it wrong.

I do see problems with engines exchanging into a bad endgame, for example from one they could maybe draw into a losing one. It's probably worth having some heuristics for that, for those cases TBs don't cover.

--Jon

[Ferdy]

In Minic I try to build some endgame using a material hash and "known" state of the game.

For example, I set KRK as a win for the side with the rook but KNKN as a draw.
For some configuration I also use a helper evaluation feature (like drive in the good corner for KBNK or drive to edge for KQK or KRK)

I feel like all of this is wrong because I should verify more stuff on a configuration before going to a conclusion. For example a KQKB can be a draw if next possible move if BxQ. So this kind of thing shall only be used after a qsearch. Even after qsearch I guess I have to check for stalemate ?

How do you handle those kind of things ?

You may start in the evaluation, then qsearch then main search, measuring progress each step.

There are situations where adding more conditions to improve win/draw recognition would bring negative rating points. There could be positions where your search can already return a better score after implementing it in the evaluation.

But this is also a good opportunity to see how your search and evaluation cooperates, because we already know which ending is even, winning and losing, and yet the evaluation and search may not get the correct or close to a correct score.

[Joost Buijs]

I use a 16 MB table which is indexed by the material hash, it contains a material scaling factor from 0 to 255%. Most entries are set at 100%, but for all these special cases I use a different percentage which tunes nicely with Texel style tuning. It handles all positions with max. 8P 3N 3B 3R 3Q for both sides, when the index falls out of this range I call a separate routine to handle this, but this does not happen very often.

It is material only, and I don't touch the positional evaluation, in practice it seems to work fine. My engine plays rather weak compared to others, basically it is a search problem, because the search is very ancient it doesn't look deep enough, the evaluation seems to be pretty well though.

The only weakness is king-safety, that could be better, when I have some time to spare I will try to improve this.