Internal Node Recognizer vs Eval tweaks

[akanalytics]

Hi

I'm trying to get my engine, Odonata, to better evaluate trees containing known winning/draw positions. No tablebases here - just programming logic.
I have four test positions.

8/NN6/8/8/8/2K2nk1/4P3/8 w - - 0 1; id 'RECOG.01'; am e2f3; bm Nd6; c0 'white shouldnt take knight as recapture of pawn makes it KNN v k';
k7/1p6/3N4/8/8/8/6N1/K6B w - - 5 1; id 'RECOG.02'; bm Nxb7; c0 'white should take pawn to leave winning KBN v k';
k7/8/K1p5/8/3N4/8/6N1/7B w - - 5 1; id 'RECOG.03'; am Nxc6; bm Kb6; c0 'white shouldnt take pawn with knight as it triggers stalemate';
k6K/8/2pN4/8/3N4/8/8/8 w - - 5 1; id 'RECOG.04'; bm Nxc6; c0 'white should force stalemate by capturing pawn on c6 as black could win';

The popular apprach seems to be adding an "internal node recognizer" which short circuits alphabeta returning a known eval (based on a simple formula) for known drawn/won positions. This seems to fail on RECOG.03, as KBN v K is seen as a win, so it jumps at it triggering a stalemate.

The other approach is to tweak the eval so that it recognises known draws/wins. This will solve N+B checkmates as I can tweak the eval to encourage chasing the king to the right corner, but suffers from the fact that it doesnt short circuit search, so a lot of effort is wasted searching along what should be known winning lines.

Im toying with some sort of "jump reduction" in depth in the node recognizer rather than returning an eval. ie setting depth = 2 - enough to spot a stalemate - but not so much that search time is wasted. Has anyone tried such approaches?

Notes - I know that the 4 cases are searched quickly. In reality Im trying to solve cases where similar positions occur deep and frquently in the search tree. Also, stockfish struggles with RECOG.04, so maybe Im not thinking clearly...

Andy

[Rebel]

Andy, welcome.

You can have a look at http://rebel13.nl/inside_rebel.pdf

And from the menu on your right click Endgame, the last link.

End Game

We have arrived at the last chapter of this page, applicable to the end game.

REBEL doesn't use table bases, instead it uses a 2 dimensional table that catches the most important endings.

During the scanning of the board 2 variables (1 for white and 1 for black) are maintained that are used as an
index to a 2 dimensional array of 16 x 16 (so 256 bytes) that can recognize 16 different ending types. Let's call
these 2 variables "white" and "black", its layout:

.....

[hgm]

Im toying with some sort of "jump reduction" in depth in the node recognizer rather than returning an eval. ie setting depth = 2 - enough to spot a stalemate - but not so much that search time is wasted. Has anyone tried such approaches?

That sounds like a logical approach. I have done something equivalent for draws: only make the draw verdict in end-games like KBKN, KNNK or KRKR when the 50-move counter reaches a certain value (1 or 3). That effectively reduces the depth to 1 or 3 ply at the point where you converted to that end-game. And it allows the engine to find the rare wins.

A similar approach can be taken for speeding up recognition of KQKP-like draws. (Of course you can put in specific rules for this, but I was interested in a general methods that would also work in chess variants, where you would have other super pieces versus a nearly-promoted Pawn.) The idea was that when you have only K plus one piece, either the piece should be able to do the job by itself (which search would discover pretty quickly), or King help is essential. But the latter is only possible if you can actually spend the time to do King moves. So in addition to the normal 50-move counter, you keep a ply counter that resets on King moves. And declare draw if that ply counter gets too high. So endless series of checks with the other piece will quickly (say after 6 or 8 ply) run into a draw verdict (rather than having to wait 100 ply for that). Before that the position can be judged 'as is', i.e. a large material advantage. Lines where you manage to move the King frequently enough then do not get qualified as drawish. You need an additional evaluation term to make sure attention focuses on sensible King moves, e.g. awarding proximity to the last-moved piece of the opponent, to make sure the engine will actually be able to convert the positions that are evaluated as a win.

[MartinBryant]

k6K/8/2pN4/8/3N4/8/8/8 w - - 5 1; id 'RECOG.04'; bm Nxc6; c0 'white should force stalemate by capturing pawn on c6 as black could win';

The 4th position you give is actually a white win as can be seen here...
https://syzygy-tables.info/?fen=k6K/8/2 ... _w_-_-_0_1

[akanalytics]

> The 4th position you give is actually a white win
Indeed it is - thank you! I've rectified my test case...
k1K5/8/8/2p5/8/6B1/5B2/8 w - - 0 1; id 'RECOG.04'; bm Bxc5; c0 'white should force stalemate by capturing pawn on c6 as black could win';

The motivation for a fourth test case is to have an example that without tablebases, the correct line of play is to force a quick stalemate, rather than risk a black win through sub-optimal play of an expected draw.

Thanks for the two earlier replies. The rebel explanation is very clear, and gives me what I would call "evaluation tweaks" in these end game situations. In fact that whole document is a gold mine.

Using the 50 move counter rather than explicitly fiddling with depth seems clever, and I think should code-up cleanly.