Syzygy and draw by repetition

Discussion of chess software programming and technical issues.

Moderators: hgm, Rebel, chrisw

bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Syzygy and draw by repetition

Post by bob »

jdart wrote:Yes, I am using Fathom (a slightly modified version of it). So nothing special is done for repetition.

[D] 8/5k2/8/3Q4/8/7K/1p3q2/8 b - - 0 1

Arasan plays Kf6 here (correctly) if searched outside of the game, with no repetition context. But with the context it apparently behaves differently.

--Jon
That seems beyond strange. I would expect the SAME DTZ-optimal move in a game our outside a game, except in cases where DTZ-optimal has to avoid a repetition along the way.

But since this starts off in a 5 piece ending, I would expect the same move no matter what since the engine is sort of out of the loop.
bob
Posts: 20943
Joined: Mon Feb 27, 2006 7:30 pm
Location: Birmingham, AL

Re: Syzygy and draw by repetition

Post by bob »

Dirt wrote:
bob wrote:BTW, I have no requirement that "the move looks sane."
Good. It doesn't bother me either. Moving from DTM to DTZ makes the endings look a lot more insane, though. People will complain.
It bugs me that I have no idea how many moves until the game is over. All I now display is "Won" or "Lost" (for white) or "-Won" or "-Lost" for black to move. But it definitely works to play correct chess.
jwes
Posts: 778
Joined: Sat Jul 01, 2006 7:11 am

Re: Syzygy and draw by repetition

Post by jwes »

Is it that difficult to create DTM50 tables?
syzygy
Posts: 5557
Joined: Tue Feb 28, 2012 11:56 pm

Re: Syzygy and draw by repetition

Post by syzygy »

bob wrote:I would assume tb_probe_root() only returns DTZ-optimal moves? Yet something went wrong here...
See what I wrote above with respect to root_probe().
syzygy
Posts: 5557
Joined: Tue Feb 28, 2012 11:56 pm

Re: Syzygy and draw by repetition

Post by syzygy »

jwes wrote:Is it that difficult to create DTM50 tables?
DTM50 is very difficult. One and the "same" position can be a mate in 10 or a mate in 15 depending on the current value of the 50-move counter. So a DTM50 table has to encode a lot more and rather complicated information.

A simpler solution would be using regular DTM tables with DTZ50 to check that the engine is not unnecessarily crossing the 50-move rule. You could then get a "mate in 60" which plays out as a mate in 65 because of the 50-move rule, but that seems something that most can probably live with.
kbhearn
Posts: 411
Joined: Thu Dec 30, 2010 4:48 am

Re: Syzygy and draw by repetition

Post by kbhearn »

jwes wrote:Is it that difficult to create DTM50 tables?
No and yes.

Creating the tables isn't difficult but they'd only contain accurate information when the 50 move counter is at zero if DTM50 is the only information included. Which is to say an apparent DTM50-optimal move 5, 10, or 20 ply into the 50 move counter may in fact not be fast enough in terms of DTZ to avoid a 50 move draw even though a fast enough DTZ win exists.
Arpad Rusz
Posts: 273
Joined: Sat Apr 17, 2010 2:34 pm
Location: Budapest

Re: Syzygy and draw by repetition

Post by Arpad Rusz »

Some interesting DTM50 results: http://galen.metapath.org/egtb50/
basil00
Posts: 55
Joined: Thu Oct 22, 2015 2:14 am

Re: Syzygy and draw by repetition

Post by basil00 »

jdart wrote:I am still looking at it. I am using the Fathom library, which is a repackaging of the Stockfish code (https://github.com/basil00/Fathom). Apparently the library does not consider repetitions, so it has no way of knowing when scoring root moves whether any might play into a repetition.
That's correct, the Fathom tb_probe_root() does not consider repetitions. This is mainly because Fathom aims to be engine-independent.

There are two options for using Fathom 'safely' (avoid repetitions) in an engine in a winning position:
  1. Always play the DTZ-optimal move returned by tb_probe_root(). (this is the Gullgyzy approach).
  2. Use search() as normal, but call tb_probe_root() with a non-null "results" argument use this to filter drawing/losing root moves. But if a repetition occurs then fall-back to DTZ-optimal mode. Most engines seem to do something like this.
The first method is the simplest, and allows the engine to insta-move in TB positons, but leads to complaints about "unnatural play". That said, the second method can also lead to lame play, e.g. in some positions the engine will aimlessly shuffle pieces around until the 50-move draw approaches. Personally I prefer the former approach and don't care about so-called unnatural play.
User avatar
hgm
Posts: 27788
Joined: Fri Mar 10, 2006 10:06 am
Location: Amsterdam
Full name: H G Muller

Re: Syzygy and draw by repetition

Post by hgm »

50-move-safe DTM is just as easy to build as naive DTM. But it only guarantees the recorded wins if you enter the tables with the ply counter at zero. Apart from artificially set-up positions, the relevant case where this occurs is when you swindle a fallible opponent in a drawn situation. The opponent might hold the draw very long, running up the ply count, and then blunder by making a reversible move into a lost position. Then you have to secure the win starting from a non-zero (and possibly very sub-optimal) ply count. Zeroing the counter might become the dominant concern in that case.

Playing according to DTZ in that case does not seem a very silly thing to do. Playing by "DTZ50-approved DTM" also is a good solution. Probing too close to the root in general is a bad idea. A 6-ply search in general still takes negligible time, so you might as well probe only from the 6-ply level, to plan around possible repetitions.
syzygy
Posts: 5557
Joined: Tue Feb 28, 2012 11:56 pm

Re: Syzygy and draw by repetition

Post by syzygy »

hgm wrote:50-move-safe DTM is just as easy to build as naive DTM. But it only guarantees the recorded wins if you enter the tables with the ply counter at zero.
No, it does not do that. Not if you store one DTM-value per position and if you want to be able to play out the mate using the table.

If you have a DTM table that gives correct information with 50-move counter == 0, then it does not give correct information for positions with 50-move counter > 0. This is not a problem of artificially set-up positions or suboptimally playing opponents but is simply inherent in DTM50. UNLESS you build a very bulky DTM50 table that stores information for each position and for each ply count.

A non-bulky DTM50 table might tell you that the current position is a mate in 60. This mate in 60 could be, for example, 50 moves until a capture and 10 more moves. Now both sides play a move and this time the table might tell you that the new position is a mate in 56: 50 moves until a capture and 6 more moves. Great, a shorter mate, but useless, because we only have 49 moves left to reach a pawn move or capture. The position is of course still won, but we don't know how.