Winboard Forum

The protocol description for the offer draw command reads:

offer draw
If your engine wants to offer a draw by agreement (as opposed to claiming a draw by rule), it can send the command "offer draw". xboard relays the offer to the user, the ICS, the other engine in Two Machines mode, and the PGN save file as required. In Machine White, Machine Black, or Two Machines mode, the offer is considered valid until your engine has made two more moves. This command must also be used to accept a draw offer. Do not use the 1/2-1/2 command for that, as the offer might be no longer valid, in which case a refusal to play on implied by the RESULT command might make you forfeit the game. "offer draw" should also be used to claim 50-move and 3-fold-repetition draws that will occur after your move, by sending it before making the move. WinBoard will grant draw offers without the opponent having any say in it in situations where draws can be claimed. Only if the draw cannot be claimed, the offer will be passed to your opponent after you make your next move, just before WinBoard relays this move to the opponent.

I used to send a "1/2-1/2" after the move to claim a draw by repetition or 50 move draw. Recently I have changed to using "offer draw" before the move as recommended in the above quote. However, what I see in the debug log is as follows:

Code: Select all

3455344 <second: # tb hit, score=+0.00
3455344 <second:  1       0      0       17 Ke2
3455344 <second:  2       0      0       33 Ke2
3455344 <second:  3       0      0       49 Ke2
3455344 <second: # terminating, tablebase hit
3455344 <second: # terminating search (controller)
3455344 <second: # search done : move = f2-e2
3455344 <second:  3       0      0       49 Ke2
3455344 <second: # state = 0
3455344 <second: # game_end = 0
3455344 <second: # in check_pending
3455344 <second: # 50 move draw
3455344 <second: offer draw
GameEnds(27, Draw agreed, 4)
Interrupting first
3455344 >first : result 1/2-1/2 {Draw agreed}
3455344 >second: result 1/2-1/2 {Draw agreed}
3455344 >first : force
3455344 >first : ping 30
3455344 >second: force
3455344 >second: ping 30
3455344 <second: move f2e2
Undoing extra move from second, gameMode 8
3455344 >second: undo
3455344 <first : pong 30
3455344 <second: # adding to pending list result 1/2-1/2 {Draw agreed}, list size=0
3455344 <second: # got cmd (main): # adding to pending list result 1/2-1/2 {Draw agreed}force


Note that 168. Rc1 was actually the 50th move w/o capture or pawn movement, but White didn't claim the draw. Black did, before making the move f2e2.

Winboard sends "Draw agreed" as the comment after the result string. I'd prefer it say "Draw by 50-move rule" to make it clear that the other engine didn't "agree," instead it is a draw by rule (for repetition it says {XBoard adjudication: repetition draw}).

Game follows. By the way this is Winboard 4.5.2 - possibly the behavior is different in later versions.

[Event "?"]
[Site "-"]
[Date "2012.11.27"]
[Round "?"]
[White "Ruffian 1.0.1"]
[Black "Arasan 15.1"]
[Result "1/2-1/2"]
[ECO "C47"]
[TimeControl "180+0"]

1. e4 e5 2. Nf3 Nf6 3. Nc3 Nc6 4. d4 exd4 5. Nxd4 Bb4 6. Nxc6 bxc6
7. Bd3 O-O 8. O-O d5 9. exd5 cxd5 10. Bg5 c6 11. Ne2 Re8 12. c3 Bd6
13. Qa4 Bd7 14. Qh4 h6 15. Bxf6 Qxf6 16. Qxf6 gxf6 17. Nd4 Rab8
18. b4 c5 19. bxc5 Bxc5 20. Rab1 h5 21. Rfd1 Rxb1 22. Rxb1 Bb6
23. Kf1 Rc8 24. Rb3 Ba4 25. Ra3 Bd7 26. Ke2 Kf8 27. Rb3 Ke7 28. g3
Rc5 29. Kd2 Ra5 30. Rb2 Ra3 31. Bc2 Kd6 32. Kd3 Ra5 33. Bd1 Bg4
34. Be2 Ra4 35. f3 Bd7 36. h4 Ba5 37. f4 Rc4 38. Rb3 Ra4 39. Bxh5
Rxa2 40. Bf3 Bb6 41. h5 Bc8 42. g4 Ba6+ 43. Ke3 Rh2 44. Rb1 Bc5
45. Rd1 Rc2 46. h6 Rxc3+ 47. Kf2 Rb3 48. Kg3 Bxd4 49. Rxd4 Bc4
50. g5 Kc5 51. Rd1 Rb8 52. Bh5 Rf8 53. Rb1 fxg5 54. fxg5 d4 55. Rc1
d3 56. h7 d2 57. Rc2 Rh8 58. Be2 d1=Q 59. Bxd1 Kb4 60. Rb2+ Kc3
61. Rb7 Rxh7 62. Rxa7 Be6 63. Bf3 Rh3+ 64. Kf4 Kd4 65. Ra4+ Kc3
66. Ra6 Rh4+ 67. Ke5 Rh3 68. Ke4 Rh8 69. Rd6 Rb8 70. Rd3+ Kc2
71. Ke3 Rb5 72. Be4 Kb2 73. Kf4 Rb6 74. Rd2+ Kc1 75. Rd4 Bb3 76. Rd7
Be6 77. Rd8 Rb5 78. Rd6 Bb3 79. Rd7 Be6 80. Rd4 Ba2 81. Ra4 Bb3
82. Ra7 Kd2 83. Rd7+ Ke1 84. Rd8 Ra5 85. Rb8 Bc4 86. Rb1+ Kf2
87. Rb2+ Kf1 88. Rb4 Ba6 89. Rd4 Bc8 90. Rd6 Kg1 91. Rc6 Bd7 92. Rf6
Be8 93. Rb6 Bd7 94. Rb1+ Kf2 95. Rb2+ Kg1 96. Rb6 Kf2 97. Rd6 Ra7
98. Rd2+ Ke1 99. Rb2 Be6 100. Ke3 Ra1 101. Bd3 Kd1 102. Rb6 Bd5
103. Rd6 Bb3 104. Be4+ Kc1 105. Rb6 Ra3 106. Rc6+ Kb2 107. Rc7 Bd5+
108. Bd3 Ra4 109. Rc2+ Ka1 110. Rc5 Ba2 111. g6 fxg6 112. Bc2 Ra6
113. Kf4 Bf7 114. Rb5 Rc6 115. Be4 Rc4 116. Kf3 Rd4 117. Rb7 Bd5
118. Bxd5 Rxd5 119. Kg4 Ka2 120. Rb4 Ka1 121. Rb3 Ka2 122. Rc3 Kb1
123. Ra3 Kc1 124. Ra1+ Kc2 125. Re1 Kd2 126. Ra1 Ke2 127. Rb1 Kf2
128. Ra1 Kg2 129. Rb1 Kf2 130. Ra1 Kg2 131. Rb1 Rd3 132. Ra1 Kf2
133. Rb1 Kg2 134. Ra1 Kf2 135. Rb1 Ra3 136. Rc1 Kg2 137. Rb1 Kf2
138. Rc1 Kg2 139. Rb1 Rc3 140. Ra1 Kf2 141. Rb1 Kg2 142. Ra1 Kf2
143. Rb1 Rd3 144. Ra1 Kg2 145. Rb1 Kf2 146. Ra1 Kg2 147. Rb1 Ra3
148. Rc1 Kf2 149. Rb1 Kg2 150. Rc1 Kf2 151. Rb1 Rc3 152. Ra1 Kg2
153. Rb1 Kf2 154. Ra1 Kg2 155. Rb1 Re3 156. Ra1 Kf2 157. Rb1 Kg2
158. Ra1 Kf2 159. Rb1 Re5 160. Ra1 Kg2 161. Rb1 Kf2 162. Ra1 Kg2
163. Rb1 Ra5 164. Rc1 Kf2 165. Rb1 Kg2 166. Rc1 Kf2 167. Rb1 Ra2
168. Rc1 Ke2 1/2-1/2 {Draw agreed}

Before I can sensibly comment on this, I would need to know what your settings were. Was draw adjudication actually switched on, and to which number of moves was it set? (You can see this in the Adjudication Options dialog.)

Note that it is still perfectly OK to use the 1/2-1/2 to claim draws that already materialize before your own move, where you cannot be pre-empted by a quick opponent move, and the draw is thus 100% certain. The "offer draw" is only needed as an advance claim.

Adjudication settings are the default ones - I have not changed them:

Verify Engine Claims - on
Detect Mates - on
Draw if Insufficient Material - on
Adjudicate Trivial Draws - on

Apply 50-move rule and 3-fold repeats.

I am now using 4.6.2 and this seems to put "Draw Agreed" in the comment for repetition draws too. Also it looks like there is a problem:

Code: Select all

12721172 <first : # check_command: draw
12721172 <first : # in accept_draw
12721172 <first : # draw declined
12721172 <first : # check_command: time 6737
12721172 <first : # check_command: otim 2092
12721172 <first : # 9 chars left in buffer: usermove
12721172 <first : # check_command: usermove Qe1+
12721172 <first : # move text = Qe1+
12721172 <first : # predicted move = h4-e1 last move = h4-e1
12721172 <first : # ponder ok
12721172 <first : # execute_move: h4-e1
12721187 <first : # movestogo=0 time_left=6737
12721187 <first : # time_target = 318
12721187 <first : # xtra time = 318
12721187 <first : 19     182    597 13015819 Kh2 Qh4+ Kg1 Qe1+ Kh2 Qh4+ Kg1 Qe1+ Kh2 Qh4+ Kg1 Qe1+ Kh2 Qh4+ Kg1 Qe1+ Kh2 Qh4+ Kg1 Qe1+ Kh2 Qh4+ Kg1 Qe1+ Kh2 Qh4+ Kg1 Qe1+ Kh2 Qh4+ Kg1 Qe1+ Kh2 Qh4+ Kg1 Qe1+ Kh2 Qh4+ Kg1 Qe1+ Kh2 Qh4+ Kg1 Qe1+ Kh2 Qh4+ Kg1 Qe1+ Kh2 Qh4+ Kg1 Qe1+ Kh2 Qh4+ Kg1 Qe1+ Kh2 Qh4+ Kg1 Qe1+ Kh2 Qh4+ Kg1
12721187 <first : # done pondering
12721187 <first : # ponder move = g1-h2
12721187 <first : # out of ponder()
12721187 <first : # in check_pending
12721187 <first : # sending ponder move
12721187 <first : # repetition draw
12721187 <first : offer draw
GameEnds(27, Draw agreed, 4)
12721187 >first : result 1/2-1/2 {Draw agreed}
12721187 >second: result 1/2-1/2 {Draw agreed}
12721187 >first : force
12721187 >first : ping 76
12721187 >second: force
12721187 >second: ping 74
12721187 <first : move g1h2
Undoing extra move from first, gameMode 8


Here Crafty (Black) offered a draw after move 74, which was declined. After the next White move there will be a 3-fold repetition. Arasan detects this and sends "offer draw" and the move. Winboard declares the game drawn after "offer draw" and then discards the move.

Looks like there is an ambiguity in the protocol here - there is a draw offer pending, but after the next move White can claim a draw by repetition. So if White sends "offer draw" and a move, did it accept the draw or did it claim the draw by repetition?

[Event "-"]
[Site "-"]
[Date "2012.11.27"]
[Round "?"]
[White "Arasan 15.1"]
[Black "Crafty-23.4 PS"]
[Result "1/2-1/2"]
[ECO "C88"]
[PlyCount "149"]
[EventDate "2012.??.??"]
[TimeControl "180+1"]

1. e4 e5 2. Nf3 Nc6 3. Bb5 a6 4. Ba4 Nf6 5. O-O Be7 6. Re1 b5 7. Bb3 O-O 8. a4
Bb7 9. d3 Re8 10. Bd2 b4 11. c3 a5 12. Nh4 Ba6 13. Nf5 Bc5 14. Qf3 Rb8 15. Qg3
Nh5 16. Qg4 bxc3 17. Bxf7+ Kxf7 18. Qxh5+ Kg8 19. Qg4 Qf6 20. Bxc3 Nb4 21. Bxb4
Rxb4 22. Rc1 Bxd3 23. Nd2 d6 24. Rc3 Ba6 25. b3 Kh8 26. Rh3 g6 27. Ne3 Bc8 28.
Rf3 Qg7 29. Qg5 Rd4 30. Ra2 Bb4 31. Nef1 Ba6 32. Qe3 Bd3 33. Ra1 Bc5 34. Rc1
Rb8 35. Qe1 Ba3 36. Ra1 Bb2 37. Ra2 Bc3 38. Qe3 Qg8 39. h4 Qg7 40. Rg3 Bb4 41.
h5 Bc5 42. hxg6 Rxa4 43. Qxc5 dxc5 44. Rxa4 Bxf1 45. Nxf1 hxg6 46. Rxa5 c4 47.
bxc4 c6 48. Rd3 Qc7 49. Ra1 Qf7 50. Ne3 Rb7 51. Rd6 Qf4 52. Rxg6 Qxe4 53. Rd6
Kg7 54. Ra8 Kf7 55. c5 Rc7 56. Rb8 Kg7 57. Rb6 Kf8 58. Kh2 Qf4+ 59. Kg1 Rf7 60.
Nd1 e4 61. Rbxc6 e3 62. Rc8+ Kg7 63. fxe3 Qc4 64. Kh2 Qh4+ 65. Kg1 Qc4 66. Kh2
Kh7 67. Rdd8 Qh4+ 68. Kg1 Qe1+ 69. Kh2 Kg6 70. Rd6+ Kg7 71. c6 Qh4+ 72. Kg1
Qe1+ 73. Kh2 Qh4+ 74. Kg1 Qe1+ 75. Kh2 1/2-1/2

IMO it would be nice if the protocol supported a command like "drawclaim <move>", to make it clearer that the player wants to claim a draw by rule after the specified move has been made.

I agree the current protocol has an ambiguity here.

OTOH, suppose your opponent offers you a draw. Why on Earth would you first do your own move, to cause a 3-fold-rep or 50-move condition, to claim one yourself? It seems much easier to not bother with the move, and just accept the draw offer to start with...

There could be a timing issue here, that you did not receive the draw offer in time. I changed WinBoard to not immediately relay draw offers, but send them just before the move. (To prevent 'electronic warfare', where you could bombard your opponent with draw offers to confuse them; some flaky ponder implementations cannot handle it when they get other input during pondering than the usual time/usermove commands.)

So if the opponent wants to offer a draw, and does so after its move, WB will relay the move (as it cannot know a draw offer will follow), but then upholds the draw offer to send it with the next move. But it still counts it as a 'pending offer', so if the opponent happens to spontaneously offer a draw as well, it becomes an 'agreed draw'. This is basically the fault of the opponent, because sending the draw offer after your move is a violation of FIDE protocol, that specified you have to make the offer before your move, and not when the opponent is already thinking. But if the opponent would have done it correctly, he would have sent the 'offer draw' before his own move (where it was not intended as a claim, because even after his move there was no claimable draw yet). Then your engine would have gotten the draw offer, and knowing that its best move was one that caused a repetition, it logically should agree to the draw rather than play a move and claim a draw.

I think Crafty is regularly sending "draw" to offer a draw just before the repetition has occurred. This is permissible but somewhat strange behavior. Other engines may or may not do this.

When I evaluate the draw offer I don't look forward to see what move the engine would play, and whether that would be a draw by rule. That info is available in the future, after the search (unless maybe I have a ponder hit, and even then, that may be based on a shallower than normal search). I just look at the previous search result, and factor in the opponent's rating. So the offer could be declined, even if the best move following would lead to a draw by rule.

Well, I agree that it would be more convenient if the protocol supported a separate 'claim draw' command. But changing the protocol is in general quite difficult, because of backward-compatibility requirements, and GUI and engine authors waiting for each other to support the changes. For a case like this it doesn't seem worth it. The engine cannot safely claim a draw, but only agree to one if an opponent offer is pending. So what? It would be an illogical thing to do anyway, and the GUI 'corrects' engines that for technical reasons would not behave entirely logical. It doesn't seem worth it to change protocol merely to make it possible for engines to better exhibit illogical behavior...

I can imagine that engine authors would be interested in collecting statistics of how the draw was reached (50-move or 3-fold rep). But in that case having the engine accept a draw would sort of defeat the purpose, as engines that can accept draw offers would be likely to accept them because the score is suppressed to the draw level by an unavoidable stalemate, 3-fold rep or 50-move deeper in the tree (and it does not have to be the same reason in every branch...). So if you really want to collect those statistics, the best method would be to never let your engine claim a draw (either through an advance claim through 'offer draw' or after its move through 1/2-1/2), and just rely on the GUI to adjudicate the draw when the 50-move or 3-fold-rep condition occur. Then you would always have the correct reason in the result comment.

I don't disagree, but this could be easily supported via a feature. Just let the engine say if it supports feature "drawclaim". If it does then
the "drawclaim" command by itself would claim a draw by rule based on the current position, and "drawclaim <move>" would claim it after the specified move is made, while the engine contracts to use "offer draw" only if actually offering or accepting a draw initiated by the other engine. However I think this is a "would be nice" rather than "have to have" feature.