evaluating tablebases draws

[syzygy]

Since I don't do TB probes at the root the draw searches are also not done at the root.

That is not what I am asking.

Draw searches are only done if the current position is in the TB and it is a TB draws[/u]

What do you mean by "current position"? I suppose the position you are at in the tree?

So what I do does not fit in your needs since you are asking the root case.

No, my point is that case 1 and case 2 should be treated differently. This is not about probing at the root.

You observed a problem of your engine giving away pieces because of TB probes returning a draw. I have the suspicion that this occurs mostly in case 1.

However at case 1 I suppose one could select only the moves with the best TB theoretical value (wdl TBs) and discard the rest. This way you prune worse branches completely and save time.

This is what I do in case 1. Saving time is not the issue, because the position is already won anyway. But I want to have natural looking play, therefore I discard all suboptimal moves and do a search - without TB probing - on the remaining moves.

At case 2 I really don't know what to do except continue searching the usual way. But maybe you can add specific endgame heuristic knowledge, but since you have TBs with 5 or 6 pieces this means you must add heuristic knowledge to 7 piece endgames and up, and this is too complex.

In case 2 of course I search, so I don't need special heuristics for 7 piece endgames that statically guess the outcome. For 7 piece positions I realy on searching deeper. But for 6 piece positions (when using 6 piece TBs) I know the outcome by probing, so I do not search deeper.

I don't see any point at all in searching deeper. If the position is a draw, what would you want to return? A value that is not a draw? Why?

Again, in case 1 this is different. If the root position is a draw and the game remains drawn after giving away a piece, you still don't want the engine to give away that piece because that looks awful. But in case 2 the game is usually not yet decided and knowing that a bad looking position is in fact a draw can save half a point - if you use that information.

[Uri Blass]

Since I don't do TB probes at the root the draw searches are also not done at the root.

That is not what I am asking.

Draw searches are only done if the current position is in the TB and it is a TB draws[/u]

What do you mean by "current position"? I suppose the position you are at in the tree?

So what I do does not fit in your needs since you are asking the root case.

No, my point is that case 1 and case 2 should be treated differently. This is not about probing at the root.

You observed a problem of your engine giving away pieces because of TB probes returning a draw. I have the suspicion that this occurs mostly in case 1.

However at case 1 I suppose one could select only the moves with the best TB theoretical value (wdl TBs) and discard the rest. This way you prune worse branches completely and save time.

This is what I do in case 1. Saving time is not the issue, because the position is already won anyway. But I want to have natural looking play, therefore I discard all suboptimal moves and do a search - without TB probing - on the remaining moves.

At case 2 I really don't know what to do except continue searching the usual way. But maybe you can add specific endgame heuristic knowledge, but since you have TBs with 5 or 6 pieces this means you must add heuristic knowledge to 7 piece endgames and up, and this is too complex.

In case 2 of course I search, so I don't need special heuristics for 7 piece endgames that statically guess the outcome. For 7 piece positions I realy on searching deeper. But for 6 piece positions (when using 6 piece TBs) I know the outcome by probing, so I do not search deeper.

I don't see any point at all in searching deeper. If the position is a draw, what would you want to return? A value that is not a draw? Why?

Again, in case 1 this is different. If the root position is a draw and the game remains drawn after giving away a piece, you still don't want the engine to give away that piece because that looks awful. But in case 2 the game is usually not yet decided and knowing that a bad looking position is in fact a draw can save half a point - if you use that information.

The reason for returning value that is not a draw is that you may have practical chances to win(at least if the opponent does not use tablebases
and even when your opponent use tablebases)

You may prefer drawn KRP vs KR that you may practically win and not some position that you evaluate as 0.05 pawns for yourself that is not in the tablebases.

If the opponent does not use tablebases then the opponent may avoid the draw of KRP vs KR and give you some nice 0.5 pawns advantage in another non tablebase position.

Even if the opponent is using tablebases it is possible that the opponent does not search deep enough and the fact that you are ready to go to KRP vs KR that is too deep for your opponent to see may give you practically better winning chances.

The last part can practically happen only if the remaining depth in the tablebases position is small and this is the reason that I think that it may be better to return(without a search) a score that is closer to the static evaluation function when the remaining depth is small and closer to draw when the remaining depth is big.

[syzygy]

The reason for returning value that is not a draw is that you may have practical chances to win(at least if the opponent does not use tablebases
and even when your opponent use tablebases)

You may prefer drawn KRP vs KR that you may practically win and not some position that you evaluate as 0.05 pawns for yourself that is not in the tablebases.

But it is very speculative to assume that your opponent cannot perfectly play KRPvKR once such a position is on the board. Of course there are more tricky cases, but still, I think current chess engines easily are sufficiently far removed from objectively optimal play that it is not beneficial to spend resources on trying to achieve subjectively better positions. We don't yet have to dumb down engines in order to stop them from offering a draw after 1.e4.

It is different once the game has reached a stage in which the game theoretic outcome is known. If you know the position is lost or drawn, e.g. because the root position is a TB loss or draw (case 1), then it does not hurt to spend resources on trying to lure (swindle) your opponent into making a mistake.

One could also do this in case 2. If the search shows a TB loss in 10 moves, then it might be a good idea to disable TBs and search again (especially with only WDL tables that do not distinguish between difficult and easy wins/losses). For draws this is not so easy, because the search returning a 0.00 value is not proof that the position is a draw.

My main point: I predict that catering for any of your "practical" (but imho contrived) cases will hurt Elo. With the current state of chess engines, engine resources should first go into playing objectively as optimal as possible.

[Cardoso]

Sorry Ronald, I'm not a native English speaker and I have many times difficult to understand the questions. I'm from portugal and my english is quite poor.

What do you mean by "current position"? I suppose the position you are at in the tree?

correct

You observed a problem of your engine giving away pieces because of TB probes returning a draw. I have the suspicion that this occurs mostly in case 1.

correct

But I want to have natural looking play, therefore I discard all suboptimal moves and do a search - without TB probing - on the remaining moves.

Ronald it seems to me you shouldn't turn off TBs for that search, although you can't go wrong choosing a move for this position since all of them have the same optimal gtv, you might end up choosing one that is not the best among the others because the search without TBs could terminate in lost position by TB, but looks good from the point of view of the search with TBs off. What's more s search with TBs on prunes more (although probing TBs takes time). So although you still play moves with the best gtv all the way down, you might play moves that are suboptimal.
In case of winning positions you might end up not making progress towards the win (I'm talking about using WDL TBs only).
BTW how do you currently treat case 2 positions?
In case 2 when you say the position is not in TBs, you mean positions with piece count greater than the piece count of the TBs?
Or do you mean positions that land on the TBs by piece count but the position isn't on the TBs because the compression scheme removed certain types of positions to improve compression?
If it is the latter situation then I might have an idea about Case 2, how about coding a separate search to find only the position's gtv (game theoretical value)? This search should return only 3 values win/draw/loss and perhaps a value that means "unknow" for the case this search failed to get the position's gtv by some unpredicted reason. This type of search would be very fast because it would prune like hell. Also it is perhaps better to use a separate hashtable for this type of search. After you have determined the gtv of the position then you can treat the position as you treat case 1 positions.
Is this too far fetched?

best regards,
Alvaro

[syzygy]

But I want to have natural looking play, therefore I discard all suboptimal moves and do a search - without TB probing - on the remaining moves.

Ronald it seems to me you shouldn't turn off TBs for that search, although you can't go wrong choosing a move for this position since all of them have the same optimal gtv, you might end up choosing one that is not the best among the others because the search without TBs could terminate in lost position by TB, but looks good from the point of view of the search with TBs off. What's more s search with TBs on prunes more (although probing TBs takes time). So although you still play moves with the best gtv all the way down, you might play moves that are suboptimal.
In case of winning positions you might end up not making progress towards the win (I'm talking about using WDL TBs only).

This is true, but here I use my DTZ tables for filtering moves. So in fact I do not search all winning moves, but only the winning moves that win before the 50-move rule kicks in.

With only WDL, in my opinion the safest way is to search on until a capture or pawn move (i.e. a move that makes progress). Those should be probed and the tree should be cut there. (Play would not be very natural, though. But if you have only WDL available you should be happy to be able to win at all.)

To make things a bit more efficient you might also want to probe at all other nodes and only search those moves that preserve the win. But then you have to probe at all nodes and that might slow down as well. I guess it depends a bit on the position. E.g. in KBNvK basically everything is won for white, so probing WDL does not help to guide the search. But with KRPvKR it probably helps to only look at moves by white that win.

BTW how do you currently treat case 2 positions?
In case 2 when you say the position is not in TBs, you mean positions with piece count greater than the piece count of the TBs?
Or do you mean positions that land on the TBs by piece count but the position isn't on the TBs because the compression scheme removed certain types of positions to improve compression?

I mean the first. If all 6-piece tables are installed and a position with 6 pieces is probed, the probing code will return the correct game theoretic value. The engine does not see the details of the compression scheme, the probing code takes care of that.

Note again: by case 2 I mean the case that the root position is in not the TBs, i.e. that the root position has more than 6 pieces in case of 6 piece tables.

What I do in case 2 is probe at all internal nodes of the search tree that have at most 6 pieces (in case the 6 piece tables are available). If the result is draw, I return a draw score and do not search further. If the result is win, I return a "win in #ply" score in the same way as I would return a "mate in #ply" score, where ply is the distance to the root. The "win-in-x" range is "below" the "mate-in-x" range, e.g. mate-in-x is 29900...30000 and win-in-x is 29800...29900. When storing win-in-x values in the hashtable I do the same as one would normally do with mate-in-x values.

In the same way as the search is guaranteed to play out a mate once a mate-in-10 is found, my search is guaranteed to reach a winning tablebase position once a win-in-10 is found. Once the winning tablebase position has been reached, I am in case 1.