Yes, that is a bit strange.koedem wrote:I mean, Qb2+ is DTZ1 but when making it Whites Kd1 is DTZ2. I would think DTZ shouldn't go up when you aren't zeroing.syzygy wrote:The value I see is 2, which is off by one. That is normal. The DTZ value is stored in moves unless having it in plies is critical for the 50-move rule. Converting it to plies cannot be done fully accurately.koedem wrote:On an unrelated note, I was checking some other TB position and stumbled upon this position https://syzygy-tables.info/?fen=6Q1/5NR ... _b_-_-_0_1
Why does the DTZ value of the position vs the one of the top move, down the top line look so weird? Am I missing something?
Also Cfish and Stockfish give DTZ=2 ply to both
[d]6Q1/5NR1/8/8/1q6/2k5/8/2K5 b - - 0 1
and
[d]6Q1/5NR1/8/8/8/2k5/1q6/3K4 b - - 0 1
The DTZ table in this case stores DTZ values for positions with white to move. So probing the first position leads to a probe of
[d]6Q1/5NR1/8/8/8/2k5/1q6/2K5 w - - 0 1
Here the correct DTZ = 2 ply. The table stores 0/1/2 ply as 0, 3/4 as 1, 5/6 as 2, etc.(*) It converts k to 1 + 2*k, so in this case 1 + 2*0 = 1 is returned for the DTZ=2 position. The DTZ=3 ply position is therefore shown as having DTZ=2. This is by design (it reduces the size of the tables without deteriorating game ply).
In the same way, probing the second position leads to a probe of
[d]6Q1/5NR1/8/8/8/2k5/3q4/3K4 w - - 0 1
This has DTZ = 0 ply (it's mate). This is stored in the table as 0, so indeed we get back 1 + 2*0 = 1 and the second position is also shown as DTZ=2.
So everything can be explained, but it is not nice.
In Cfish it is fixed in TB_root_probe_dtz():
https://github.com/syzygy1/Cfish/blob/1 ... #L920-L924
Code: Select all
// Make sure that a mating move gets value 1.
if (pos_checkers() && v == 2) {
if (generate_legal(pos, (pos->st-1)->endMoves) == (pos->st-1)->endMoves)
v = 1;
}But it would be better to fix this in TB_probe_dtz(), so that the "d" command returns the correct value and any other code that calls TB_probe_dtz() directly doesn't get confused.
Thanks for the bug report!
(*) If the table contains a position with DTZ = 100 plies, then it stores 0/1 as 0, 2 as 1, 3 as 2, ..., 100 as 99. So in that case the DTZ values are fully accurate (provided the mate-in-1 case is fixed).