Syzygy and draw by repetition

[hgm]

What I had in mind was building a DTM table starting from all winning conversions / zeroings, doing 50 retrograde cycles. That would at least guarantee every position marked as DTM=N would have a move leading to a won position with DTM=N-1 two ply later. It could indeed be that there are also other moves to DTM=N-1, which are not won if you go there because the ply counter is too high. But DTZ50 probing would enable you to avoid those.

[syzygy]

What I had in mind was building a DTM table starting from all winning conversions / zeroings, doing 50 retrograde cycles.

Yes, and as I pointed out such a table has far more limitations than what you were suggesting.

If you're using DTZ50 anyway as a safeguard, there seems to be no good reason for using DTM50 over DTM. The DTM table will deliver sensible moves and the DTZ50 table can be used to check for the relatively rare case where a different move saves the win (or achieves the draw).

[hgm]

I wasn't suggesting anything, other than that a position is a win when the table says it is a win and the ply counter is zero. Normal DTM does not have that property.

I would expect DTM tables that avoid conversion to cursed wins to lead to somewhat more natural play in combination with DTZ50 than DTM tables that don't avoid such conversions.

[syzygy]

I wasn't suggesting anything, other than that a position is a win when the table says it is a win and the ply counter is zero. Normal DTM does not have that property.

Apart from artificially set-up positions, the relevant case where this occurs is when you swindle a fallible opponent in a drawn situation.

Ok, not a suggestion. Just wrong information.

[jdart]

I am doing 2. but not with the addition "But if a repetition occurs then fall-back to DTZ-optimal mode.". So that is likely the problem.

Btw.: I have a pull request pending against Fathom, for a different issue (problems compiling on a non-x86 architecture).

--Jon

[jwes]

What would happen if you used standard DTM tables and always made the move with the shortest DTM that is also a win in the WLD table?

[Dirt]

What would happen if you used standard DTM tables and always made the move with the shortest DTM that is also a win in the WLD table?

That could work, but the only publicly available six piece DTM files I am aware of (Nalimov) are huge. Gaviota tablebases, since they are only five piece, are of reasonable size, but cover only a small part of the problem. You still wouldn't know for certain how far you are from mate, either.

I'm not seeing sufficient benefit to make it worth the trouble.

[syzygy]

What would happen if you used standard DTM tables and always made the move with the shortest DTM that is also a win in the WLD table?

Does not work, because WDL only gives accurate 50-move information if the 50-move counter was just reset.

The solution is to check the DTM move against the DTZ50 table as described above.

DTZ50 = n means:
- if 50-move counter <= 100 - n, then win;
- if 50-move counter > 100 -n, then draw.

See the comments in tbprobe.c for a more precise formulation.

[Dirt]

What would happen if you used standard DTM tables and always made the move with the shortest DTM that is also a win in the WLD table?

Does not work, because WDL only gives accurate 50-move information if the 50-move counter was just reset.

The solution is to check the DTZ50 table instead as described above.

Sorry, I just assumed he had said DTZ table. I think using the DTZ table in combination with DTM would sometimes get you shorter mates, but the 'cost' seems exorbitant.

[basil00]

I am doing 2. but not with the addition "But if a repetition occurs then fall-back to DTZ-optimal mode.". So that is likely the problem.

Yes. Although this problem is not mentioned in the Fathom documentation so this should probably be fixed.

Btw.: I have a pull request pending against Fathom, for a different issue (problems compiling on a non-x86 architecture).

Yes thanks, I should merge it sometime this week. Haven't had a chance to work on hobby projects recently.