building better tablebases for drawn position

[Uri Blass]

The problem with tablebases is that they do not have evaluation except draw or mate.

I think that it may be good to have tablebases with non draw evaluation when the test is tablebase A is better than tablebase B may be based on the percentage of drawn positions that they can win against non perfect engines without tablebases.

In other words I would like the computer to have not only mate score but also static evaluation that is not draw for drawn positions when the engine always choose the move that leads to the best static evaluation in case of drawn position(static score may be also dependent on the 50 move counter) and there may be different score for repetition and for non repetition so the engine is not going to repeat easily if the opponent found the correct defence and try something else.

[phhnguyen]

You used the word “better” but I guess you didn’t clear what an EGTB better is!

Firstly, Syzygy has been overruling the EGTB world not because of its clever code, special data nor its famous DTZ50… but mainly because of having the smallest size. Even that, downloading and storing multi GB or TB of Syzygy is a nightmare for many users. Theory, you can store anything in an EGTB, including evaluation scores as you have mentioned. However, any extra added bit may cause a serious expansion in size and make the EGTB much more harder for users to download and store. That means adding more info to expand the EGTB size is not “better”.

Secondly, any value depending on a specific engine will not be good. The evaluation/score of an engine may not be useful for other engines or even for later versions of that engine. Look at Stockfish as an example: yesterday its static evaluation is an handy-make/hard coding, but today it’s an NNUE!

Third, building an EGTB is a nightmare, boring and expensive task, requiring a lot of effort, expensive computers, time and electric power… I don’t think people want to build another EGTB 7-man if it is not clearly much better.

Now the question is that if we can do what you need using only current EGTBs? Yes, you could and it is quite easy IMHO by one of two ways:

- whenever your engine gets draws from probing an EGTB, just continue with very low depth or qsearch only or evaluation only, then take the best move from the results
- don’t use EGTB at all when playing against a human or other engine without using EGTB. For a given position, just continue as usual, regardless it may be a draw according to an EGTB. The point you hope the rival doesn’t know how to draw that position and you believe you know how to win (that position), why bothering to ask EGTBs

[hgm]

I think this is pointless. For one, there is no unique 'non-perfect player', and you would need a different EGT for every opponent.

But more fundamentally, it makes no sense to pre-calculate things that you can easily calculate on the fly, and put them in a large table. Access to the table would probably be slower than just calculating the thing. For DTM/DTZ it makes sense to tabulate, because there is no easy way to calculate a DTx. It might take a 100-ply search to conclude a position is a draw. But in drawn positions a simple static evaluation would probably suffice. As you know there is no winning tactics to be found.

[Koistinen]

I agree that storing an extra value for each position in the EGT is not worth it,
Still, there is such a thing as difference in difficulty of drawing a drawn game, and having some heuristic for that might be useful.

[syzygy]

The problem with tablebases is that they do not have evaluation except draw or mate.

I think that it may be good to have tablebases with non draw evaluation when the test is tablebase A is better than tablebase B may be based on the percentage of drawn positions that they can win against non perfect engines without tablebases.

This is something that the engine can do. No need to change the tablebases.

[syzygy]

If the root position is a TB draw, then a good solution is to use the TB only to filter out losing root moves (and moves that do not lower DTZ in case of a "cursed win"). (This is what SF does.)

If the root position is not yet in the TB, and the search encounters a TB draw during the search, it may indeed have value to distinguish between draws.

I think if alpha < 0 from the engine's POV, then you can simply take the cut off (assuming non-PV node).

If alpha >= 100cp (say) from the engine's POV, then you can probably take the cut off as well.

If 0 < alpha < 100cp , it could make sense to do a qsearch() or even a regular-depth search, and then adjust the outcome in a suitable manner. (If the engine is going to return the positive evaluation without scaling it down, then I would say you need to do a regular-depth search.)

If there is knowledge about the opponent (human, engine without TB, engine with TB), the parameters used could be adjusted. Against a human there might be no need to scale down the evaluation. Against another engine with full TBs it seems you want to scale down to +0.01 since your engine won't ever win the drawn TB position.

When playing a human or an engine without TBs, the engine could gamble that it will win all cursed wins (and treat them as TB wins, just with higher "distance to win").

[syzygy]

If 0 < alpha < 100cp , it could make sense to do a qsearch() or even a regular-depth search, and then adjust the outcome in a suitable manner. (If the engine is going to return the positive evaluation without scaling it down, then I would say you need to do a regular-depth search.)

If there is knowledge about the opponent (human, engine without TB, engine with TB), the parameters used could be adjusted. Against a human there might be no need to scale down the evaluation. Against another engine with full TBs it seems you want to scale down to +0.01 since your engine won't ever win the drawn TB position.

In practice you will not scale down the returned eval but you will call the (q)search<NonPV> with an adjusted value of alpha.

Some puzzling will be needed to get this right

[syzygy]

If 0 < alpha < 100cp , it could make sense to do a qsearch() or even a regular-depth search, and then adjust the outcome in a suitable manner. (If the engine is going to return the positive evaluation without scaling it down, then I would say you need to do a regular-depth search.)

If there is knowledge about the opponent (human, engine without TB, engine with TB), the parameters used could be adjusted. Against a human there might be no need to scale down the evaluation. Against another engine with full TBs it seems you want to scale down to +0.01 since your engine won't ever win the drawn TB position.

In practice you will not scale down the returned eval but you will call the (q)search<NonPV> with an adjusted value of alpha.

Some puzzling will be needed to get this right

And I might make the 100cp value dependent on remaining depth (or perhaps distance to root). Far away from the root you might just want to evaluate TB draws as 0 to not let this slow down the search.