Marek Soszynski wrote:[d]8/5k2/8/8/8/4p2P/5p2/7K b - - 0 74
A simple mate in four, but Stockfish-rtb, with the new tablebases, insists on under-promoting to a knight.
This is how DTZ tables work. It can lead to unnatural play. It attempts to minimize the number of moves to a capture or pawn move (by either side), which means it will prefer a pawn move over a mate in two.
The good thing is that this will never give a problem with the 50-move rule. Another good thing is that this allows the tables to be small.
To fix the unnatural play, the engine needs to be smarter once the game has entered a tablebase position. Instead of playing the move with lowest DTZ value (distance to capture or pawn move), the engine should do a (short) search on the moves that preserve the win and that have a DTZ value well within what's left of the 50-move budget. This avoids trouble with the 50-move rule. In addition, to avoid draw-by-repetition, the engine should detect repetition of an earlier position and if that occurs once, just switch to DTZ-optimal play until a pawn move or capture is reached.
My branch is bases on Ronald de Man's tablebases (http://talkchess.com/forum/viewtopic.php?t=47681). Unfortunately the current implementation is not finished and does not take full profit of Ronald's work ! This is just an experimental toy waiting for bug reports
Comstock is based on robbobases (http://ippolit.wikispaces.com/RobboBases) ; so yes that's a different implementation
Salut Jean-François,
I would like to experiment with RTB, but my old processor is not popcnt/sse4.2 compatible.
If you find the time, could you compile a non popcnt/sse4.2 version (64-bit or 32-bit, as you like).
Marek Soszynski wrote:[d]8/5k2/8/8/8/4p2P/5p2/7K b - - 0 74
A simple mate in four, but Stockfish-rtb, with the new tablebases, insists on under-promoting to a knight.
This is how DTZ tables work. It can lead to unnatural play. It attempts to minimize the number of moves to a capture or pawn move (by either side), which means it will prefer a pawn move over a mate in two.
Of the four moves leading to the quickest checkmate, three are pawn moves.
To be fair, this early Stockfish-rtb is more a proof of concept than a fully practical engine.
Marek Soszynski wrote:To be fair, this early Stockfish-rtb is more a proof of concept than a fully practical engine.
In my private engine I have now implemented a more sophisticated handling of the root position which seems to be working quite nicely. I'll try to port it to Stockfish, but it will take a few days before I have time.
Marek Soszynski wrote:[d]8/5k2/8/8/8/4p2P/5p2/7K b - - 0 74
A simple mate in four, but Stockfish-rtb, with the new tablebases, insists on under-promoting to a knight.
This is how DTZ tables work. It can lead to unnatural play. It attempts to minimize the number of moves to a capture or pawn move (by either side), which means it will prefer a pawn move over a mate in two.
The good thing is that this will never give a problem with the 50-move rule. Another good thing is that this allows the tables to be small.
To fix the unnatural play, the engine needs to be smarter once the game has entered a tablebase position. Instead of playing the move with lowest DTZ value (distance to capture or pawn move), the engine should do a (short) search on the moves that preserve the win and that have a DTZ value well within what's left of the 50-move budget. This avoids trouble with the 50-move rule. In addition, to avoid draw-by-repetition, the engine should detect repetition of an earlier position and if that occurs once, just switch to DTZ-optimal play until a pawn move or capture is reached.
To implement this for Stockfish, one could do following:
- Stockfish maintains a RootMoveList (a list of moves that are searched).
- If we have a tablebase position at root, check which moves preserve the win/draw. Remove other moves from root move list.
- Let the search run as usual.
This would result in "natural" play without ever losing a win/draw. It might not be optimal from time management perspective though.
Marek Soszynski wrote:[d]8/5k2/8/8/8/4p2P/5p2/7K b - - 0 74
A simple mate in four, but Stockfish-rtb, with the new tablebases, insists on under-promoting to a knight.
This is how DTZ tables work. It can lead to unnatural play. It attempts to minimize the number of moves to a capture or pawn move (by either side), which means it will prefer a pawn move over a mate in two.
The good thing is that this will never give a problem with the 50-move rule. Another good thing is that this allows the tables to be small.
To fix the unnatural play, the engine needs to be smarter once the game has entered a tablebase position. Instead of playing the move with lowest DTZ value (distance to capture or pawn move), the engine should do a (short) search on the moves that preserve the win and that have a DTZ value well within what's left of the 50-move budget. This avoids trouble with the 50-move rule. In addition, to avoid draw-by-repetition, the engine should detect repetition of an earlier position and if that occurs once, just switch to DTZ-optimal play until a pawn move or capture is reached.
To implement this for Stockfish, one could do following:
- Stockfish maintains a RootMoveList (a list of moves that are searched).
- If we have a tablebase position at root, check which moves preserve the win/draw. Remove other moves from root move list.
- Let the search run as usual.
This would result in "natural" play without ever losing a win/draw. It might not be optimal from time management perspective though.
Yes, this is very much how I do it now in my own engine. I also reduce the allocated time by a factor 5.
One part that is a bit tricky is that the search "as usual" should probably have a cleared hash table (since TB positions are already stored there as "win" or "draw" and we don't want to use that information). In my own engine I implement this by xor'ing the hash key of the root position with a random value before and after the search. I suppose this will work for Stockfish as well.
In the position given above, my engine would now play 1..f1=Q+ 2.Kh2 Qf2+ 3.Kh1 e2 4.h4 e1=Q# and not anymore (for example) 1...f1=Q+ 2.Kh2 Qxh3+ 3.Kxh3 e2
zamar wrote:
...
To implement this for Stockfish, one could do following:
- Stockfish maintains a RootMoveList (a list of moves that are searched).
- If we have a tablebase position at root, check which moves preserve the win/draw. Remove other moves from root move list.
- Let the search run as usual.
This would result in "natural" play without ever losing a win/draw. It might not be optimal from time management perspective though.
As a generalization : each time it's SF side to move only select best moves (win or draw) from TB and add +20 to score if winning (and divide by 20 when it's draw). This not only on root ...
