Endgame evaluation

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
Post Reply
User avatar
xr_a_y
Posts: 700
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Endgame evaluation

Post by xr_a_y » Fri Apr 26, 2019 10:00 am

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
Posts: 919
Joined: Tue Mar 09, 2010 2:46 pm
Location: New York
Full name: Álvaro Begué (RuyDos)

Re: Endgame evaluation

Post by AlvaroBegue » Fri Apr 26, 2019 12:00 pm

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.

User avatar
xr_a_y
Posts: 700
Joined: Sat Nov 25, 2017 1:28 pm
Location: France

Re: Endgame evaluation

Post by xr_a_y » Fri Apr 26, 2019 1:38 pm

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
Posts: 3804
Joined: Fri Mar 10, 2006 4:23 am
Location: http://www.arasanchess.org

Re: Endgame evaluation

Post by jdart » Fri Apr 26, 2019 1:45 pm

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
Posts: 4043
Joined: Sun Aug 10, 2008 1:15 pm
Location: Philippines

Re: Endgame evaluation

Post by Ferdy » Fri Apr 26, 2019 3:36 pm

xr_a_y wrote:
Fri Apr 26, 2019 10:00 am
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
Posts: 927
Joined: Thu Jul 16, 2009 8:47 am
Location: Almere, The Netherlands

Re: Endgame evaluation

Post by Joost Buijs » Fri Apr 26, 2019 5:30 pm

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.

Post Reply