jdart wrote:The problem is, with Syzygy, you don't get evals in the customary sense. All chess engines usually report scores that are based on distance to mate. With Syzygy you don't have that. You can sort the winning/drawing moves on DTZ. But if there are also losing moves, what is their score, if the search was cut off with a TB hit?
If the root position is not yet in the TB, then SF returns a score representative of the distance to a TB win or TB loss. So SF will play a line that most quickly leads to a TB position. (This is not always ideal from the human point of view, but it works "perfectly". Improving on this approach without turning to DTM tables is not impossible but rather tricky. Likely simply not worth it, but that depends on how much you care about code simplicity etc.)
The discussion here is about the case where the root position is in the TBs.
Since DTZ50 allows an engine to play TB endings perfectly while respecting the 50-move rule, the primary requirement is to actually play those endings perfectly. This is non-negotiable.
A secondary requirement is to play moves that don't look too stupid. A queen move that forces the losing side to capture the winning side's queen just to minimise DTZ (say in KQQvKR) looks stupid.
SF addresses the primary requirement by first filtering out all root moves that would lose half a point or more (taking into account the 50-move rule). This is done by a simple round of probing the DTZ50-tables for each root move.
The secondary requirement is addressed in a simple way by searching the remaining moves in the normal way, but without probing the TBs. This also has the advantage that mates will be found and reported if they are within the search horizon. The move that comes out on top is the move that is played. (There is the potential problem that this leads to a series of moves that repeats the position. Once that happens, SF switches to playing DTZ-optimal moves, which ensures that three-fold repetition is avoided.)
If the root position has high DTZ, the search might sometimes return a drawish or even negative score, because SF's search cannot yet see that the position is winning. Displaying those scores will only confuse the user. Even displaying a +10 score after SF has already announced a (TB) win is confusing. So instead, a TB win (or TB loss or TB draw) score is displayed. (If the search returns a mate score, then that mate score is displayed.)
The above all works out well with mathematical precision. See the other thread by Kai. The programmer understood very well what he was doing.
However, with the above approach, SF's multipv=N mode does not always display N PVs. That is because the filtering phase may select fewer than N moves.
Correcting for this by simply selecting a few more moves does not work, as each of these extra moves carries the risk of losing half a point or more: they are bad moves. Those bad moves simply may not be played (primary requirement). But SF's probeless search does not and cannot know that, in particular if DTZ is relatively high. So it may happen that one of the bad moves floats to the top of the multipv PVs. One could prevent that by adding lots of code to SF (to make sure that the bad moves stay at the bottom). But I am pretty sure that the SF maintainers would not allow that code injection. And for good reasons, because this is just a minor cosmetic quibble. If one really needs to know the outcomes of all moves, then there are online TB browsers.
Of course nobody is prevented from anyway preparing a patch and offering it to the SF maintainers.
