New thread for Engine Draw Claims

[GothicChessInventor]

It seems like the Engine Draw Claim thread has spiralled into chaotic discord.

Shall we start over and filter out the noise from what was already learned?

Relevant points (just a primer)

1. The GUI must now arbitrate the "claim" made by an engine regarding certain forms of draws (but not all?)

2. The GUI can "penalize" an engine making a draw claim that is unwarranted/not allowed/or otherwise of the incorrect form by giving it a loss and terminating the game in favor of the other engine?

3. The USCF "Draw due to Insufficient Losing Chances" in a sudden death time control has no bearing. Even if you are in a drawn position with tablebases supporting this, if your opponent is 1 second ahead and can run your engine out of time, then this bitter loss must be accepted.

4. There is a conundrum concerning sending draw claims and moves simultaneously. That being, upon receipt of a move, an engine's default behavior is to act on this move, rather than wait for the GUI to arbitrate a candidate draw. Conversely, sending a draw claim without a move, is considered "bad form", with an anolog equivalent in human play.

Is this the crux of it all? Did I leave any items out?

How about we build on this list of scenarios and enumerate them.

Subsequently, instead of "replying to posts", just refer to the numbered items and offer commentary.

Just a suggestion to help manage the discussions.

[bob]

It seems like the Engine Draw Claim thread has spiralled into chaotic discord.

Shall we start over and filter out the noise from what was already learned?

Relevant points (just a primer)

1. The GUI must now arbitrate the "claim" made by an engine regarding certain forms of draws (but not all?)

I don't see why not "all"... Otherwise it is a faulty GUI, since the rules for drawing a game are clearly laid out in the FIDE rules book...

[quote\

2. The GUI can "penalize" an engine making a draw claim that is unwarranted/not allowed/or otherwise of the incorrect form by giving it a loss and terminating the game in favor of the other engine?[/quote]

This is the one I have been disagreeing with. FIDE rules specifically address this, because the arbiter can disallow things like a 3-fold repetition or 50-move claim if the person making the claim has an incomplete or unreadable score sheet, or the score sheet is incorrect (bogus moves, etc.)

3. The USCF "Draw due to Insufficient Losing Chances" in a sudden death time control has no bearing. Even if you are in a drawn position with tablebases supporting this, if your opponent is 1 second ahead and can run your engine out of time, then this bitter loss must be accepted.

I go along with that. If two players agree to play with a fixed sudden-death time control, it is a bit disingenuous to later say "but it isn't fair if I lose when my flag falls if you can't force mate..." the moral is to not play sudden death if you don't want to lose like that. That was the thing that led to the Fischer-clock approach (increment)...

4. There is a conundrum concerning sending draw claims and moves simultaneously. That being, upon receipt of a move, an engine's default behavior is to act on this move, rather than wait for the GUI to arbitrate a candidate draw. Conversely, sending a draw claim without a move, is considered "bad form", with an anolog equivalent in human play.

Is this the crux of it all? Did I leave any items out?

How about we build on this list of scenarios and enumerate them.

Subsequently, instead of "replying to posts", just refer to the numbered items and offer commentary.

Just a suggestion to help manage the discussions.

[Uri Blass]

My comments:
1)The rules of drawing by the fide rules are not easy to adjudicate by the gui.

[d]kN6/BRRQ4/K5p1/8/6P1/8/8/4q3 b - - 0 1

Suppose that black plays Qa5+ and claim a draw.
Do you expect the interface to calculate that it is a draw because of
9.6 of the fide rule

The game is drawn when a position is reached from which a checkmate cannot occur by any possible series of legal moves, even with the most unskilled play. This immediately ends the game, provided that the move producing this position was legal.


http://www.fide.com/official/handbook.asp?level=EE101

2)I think that the best solution for the draw problem is to allow engines to tell the gui before the game if they want to continue after claiming a draw.

Today many engines are not designed to continue after claiming a draw.
I can explain a reasons for this decision.

a)The authors believe that they have no bug in their claiming draw implementation
b)The authors prefer to know about bugs in order to fix them.
If they get games from external source and the engine continue after claiming a draw incorrectly they may not notice that there was an incorrect claim because in the pgn that they get they do not see draw claim.
If the engine lose because of incorrect claiming then they may look at the game and learned that their engine lost for that reason and it can help them to fix the bug

3)for tablebase position I think that the user should have an optiion to tell the interface to adjudicate known tablebase position based on the expected result or not to do it so if a user want to play sudden death when tablebases positions are adjudicated then the user should be allowed to do it.

Uri

[hgm]

The insufficient losing chances is not a true rule, as it does not have a well-defined meaning: no formula is given to compute "losing chances" from board position and player ratings. As Chess engines can be infinitely stupid, I interpret this rule like that there are always significant losing chances if a checkmate position exists with the material currently on the board.

The way WinBoard 4.3.13 (aka WinBoard_F) handles this is user controllable through the options /materialDraws and /trivialDraws, causing games where no checkmate position _exists_ (KK, KBK, KNK) to be adudicated draw, and adjudicate KNNK, KBKN, KBKB, KNKN, KRKR and KQKQ as draw after 3 moves, respectively.

Future versions of WinBoard_F will also have the option /bitbaseDraws=N to adjudicate games based on N-men bitbase probing, IF someone can hand me the code and interface description of a C routine to probe bitbases, and test for me if it works.

[GothicChessInventor]

That implementation is fine, except if there is a mate in > 3 moves for Q vs. Q when the draw is flagged.

Another concern of mine is from this game from the 2007 Gothic Chess Computer Championship

http://www.gothicchess.com/javagames/db ... 6/game.htm

Code: Select all

TSCP Gothic 64 - fmax4_8s
2007 Gothic Chess Computer World Championship (Main Line Chess Club, Gladwyne, PA), 11/24/2007
Round 3 [www.GothicChess.com]

1.Nc3 e5 2.Nh3 Nh6 3.d4 g6 4.d5 d6 5.Ne4 Nd7 6.Qd3 Nf6 7.i3 c6 8.dxc6 bxc6 9.Bi2 Bf5 10.Nhg5 Nxe4 11.Nxe4 Ng4 12.h3 Nf6 13.Nxf6 Bxf6 14.Qa3 Be6 15.Be3 Cc7 16.Rd1 Be7 17.Qa4 Qd7 18.Af3 f5 19.Bd2 O-O-O 20.b3 c5 21.Ba5 Ca6 22.Bxd8 Cxa4 23.Bxe7 Cxa2 24.Bxd6 e4 25.Ae5 Ca6 26.Axd7+ Bxd7 27.Bf4 j5 28.Rd6 Ca5 29.Cd1 Cb7 30.Ra6 g5 31.Bxg5 Rj6 32.Rxj6 ixj6 33.h4 a5 34.Cc1 h6 35.Bf4 Cb6 36.Ca1 Ae6 37.g3 Cc6 38.Bh3 c4 39.Bxj5 Ad4 40.Ca3 c3 41.Bh3 h5 42.Be3 Ae6 43.Bg5 Af8 44.Ca1 f4 45.O-O Bxh3 46.Rxh3 Ae6 47.Rh2 f3 48.exf3 exf3 49.j3 j5 50.Ce1 Ad4 51.Ce8+ Kb7 52.Cj8 Axc2 53.Cxj5 Axb3 54.Cxh5 c2 55.Rh1 a4 56.Ch7+ Cc7 57.Cxc7+ Kxc7 58.Bc1 Ad4 59.Be3 Ab3 60.Bf4+ Kc6 61.h5 a3 62.h6 a2 63.h7 Ad4 64.h8=Q Axh8 65.Rxh8 a1=Q+ 66.Rh1 Qd4 67.Be3 Qd8 68.Kj2 Qd1 69.Ri1 Qd7 70.Rc1 Qh7 71.j4 Kd5 72.g4 Kc4 73.g5 Qh2+ 74.Kj3 Qh5+ 75.Ki2 Qg4+ 76.Kj2 Kd3 77.Kj3 Qh3 78.Re1 Qh5+ 79.Ki2 Qg4+ 80.Kj2 Qg2+ 81.Kj3 Qh3 82.Rc1 Kc3 83.Rg1 Qh2 84.Re1 Qh5+ 85.Ki2 Qg4+ 86.Kj2 Kd3 87.Rc1 Qi4 88.Rh1 Qg2+ 89.Ki1 Ke2 90.j5 Qxj5 91.Ki2 Qg2+ 92.Ki1 Kd3 93.Rc1 Qh3 94.Kj2 Kc3 95.Kj3 Qj5+ 96.Ki2 Qg2+ 97.Ki1 Kd3 98.Rh1 Qi4 99.Ki2 Qg4+ 100.Kj3 Qj7+ 101.Ki4 Qi7+ 102.Kh3 Qh8+ 103.Ki2 Qc8+ 104.Kj2 Qe8 105.Rc1 Qj8+ 106.Ki2 Qc8+ 107.Kj2 Qh3 108.Ri1 Qh2+ 109.Kj1 Kc3 110.Ra1 Qxi3 111.Rc1 Kd3 112.Rh1 Qj3+ 113.Ki1 Ke4 114.Rc1 Qi3+ 115.Kj1 Qj4+ 116.Ki2 Qi4+ 117.Kh2 Qh4+ 118.Ki2 Kd3 119.Ki1 Qh3 120.Rg1 Qi3+ 121.Kh1 Ke2 122.Rc1 Qh3+ 123.Ki1 Qi4+ 124.Kh1 Qg2+ 125.Ki1 Kd3 126.Rh1 Qi4+ 127.Kh2 Qh5+ 128.Ki2 Qi6+ 129.Kh2 Qh7+ 130.Ki2 Qi8+ 131.Kh2 Qh8+ 132.Ki2 Qj8 133.Rc1 Qc8+ 134.Kh2 Qg4 135.Ki1 Qh4 136.Ki2 Kc3 137.Rg1 Qi4+ 138.Kh2 Qj4+ 139.Kh1 Qj3+ 140.Kh2 Qj2+ 141.Kh3 Qj4 142.Ra1 Kd3 143.Ra3+ Ke2 Xboard adjudication: Flag fell 0-1

Both programs played less than optimally (I'm trying to be nice) but it is clear that neither knew how to finish the game. It was clearly headed for the 50-move rule draw with the last irreversible move made on move 110.

I just hate to see games end like this, but I guess it's a fair win, even though it was a time forfeit.

[hgm]

That implementation is fine, except if there is a mate in > 3 moves for Q vs. Q when the draw is flagged.

Yes, I know. The 3 moves was based on longest win (DTC) in KRKR. I hesitated long if I should add KQKQ here. In the end I decided to do it, as wins in end-games wirth identical pieces are extremely rare, and the end-game occurs relatively often, and wastes a lot of testing time then. It is almost always draw, because the pieces have no safe attack on each other. KCKA or KQKC are not nearly as often draw as KQKQ or KCKC. So in Gothic it would probably be wise to add KCKC and KAKA to the trivial-draw list.

OTOH, I see this just as a temporary solution, for until I have implemented bitbase adjudication. Once that is provided, KQKQ will be taken out of /trivialDraws and be grouped under /bitbaseDraws. I am not sure if bitbases for Gothic Chess already exist.

[GothicChessInventor]

I am not sure if bitbases for Gothic Chess already exist.

I have computed only distance-to-mate endgames for Gothic Chess. Some of the more interesting ones are here:

http://www.gothicchess.com/javascript_endings.html

[hgm]

Well, once WinBoard could directly probe the tablebase, it does not have to know the DTC or DTM. Just if the position is drawn or not. If it is drawn it adjudicates draw, for equal-material end-games. If not the engines play on. Then it doesn't have to know a number of moves to play on, it just plays on until the side that can win mates or bungles it. If it can't find the mate, but stays in the 'won' sector, the 50-move rule will terminate the game. As these equal-material end-games are usually very trivial to draw, once you are in the draw sector.

This only applies to equal-material endings. Things like KCKA will not be considered trivial bitbase draws, and will not beadjudicated. Unless the user also switches on the option to adjudicate any 5-men end-game. Then it immediately decides on the result as soon as there are 5 men left. Win, draw or loss.

[bob]

My comments:
1)The rules of drawing by the fide rules are not easy to adjudicate by the gui.

[d]kN6/BRRQ4/K5p1/8/6P1/8/8/4q3 b - - 0 1

Suppose that black plays Qa5+ and claim a draw.
Do you expect the interface to calculate that it is a draw because of
9.6 of the fide rule

The game is drawn when a position is reached from which a checkmate cannot occur by any possible series of legal moves, even with the most unskilled play. This immediately ends the game, provided that the move producing this position was legal.


http://www.fide.com/official/handbook.asp?level=EE101

2)I think that the best solution for the draw problem is to allow engines to tell the gui before the game if they want to continue after claiming a draw.

Today many engines are not designed to continue after claiming a draw.
I can explain a reasons for this decision.

a)The authors believe that they have no bug in their claiming draw implementation
b)The authors prefer to know about bugs in order to fix them.
If they get games from external source and the engine continue after claiming a draw incorrectly they may not notice that there was an incorrect claim because in the pgn that they get they do not see draw claim.
If the engine lose because of incorrect claiming then they may look at the game and learned that their engine lost for that reason and it can help them to fix the bug

3)for tablebase position I think that the user should have an optiion to tell the interface to adjudicate known tablebase position based on the expected result or not to do it so if a user want to play sudden death when tablebases positions are adjudicated then the user should be allowed to do it.

Uri

I am far less worried about such constructed positions than I am about positions that will _really_ occur in a game. I do believe that the GUI should be able to properly enforce checkmate/stalemate termination, and that it should be able to recognize 3-fold repetitions and 50-move draws, although it can not end the game unless a player claims the draw. As far as the insufficient material to mate issue, for all I care the GUI can ignore those completely and just force the engines to play 'em out. Or do as ICC does and call endings like KB vs KN a draw, even though the KN can win if the KB side helps.

As far as tablebase draws go, I am in 100% disagreement. What if only one of the engines is using tablebases? Let 'em play the game out. If both use tables, how long will the game last until the 50 move rule kicks in? 1 second total? Again, for FIDE rules, endgame tables have no meaning. Follow that here...

[Dirt]

As far as tablebase draws go, I am in 100% disagreement. What if only one of the engines is using tablebases? Let 'em play the game out. If both use tables, how long will the game last until the 50 move rule kicks in? 1 second total? Again, for FIDE rules, endgame tables have no meaning. Follow that here...

How long? It seems like quite a while for Crafty if swindle[*] mode is on. That is optional of course, but so would be the TB adjudication by the GUI. People who don't like it wouldn't be forced to use it.

*I am just assuming this is still supported.