bob wrote:what I would _like_ to do is do the claim in the order I would use in a human event. examples:
(1) I want to claim a draw and do not need to make a move to do so. I would like to send "draw" and have the game end.
But
draw might not end the game at all. Because the GUI might not recognize it as a WB command. No currently existing GUI would. And no matter how you or I redefine the protocol, these GUIs will continue to be around in large numbers. And they won't give you an error message back. Always sending (only)
draw will break your engine on every existing GUI. I cannot imagin that this is what you have in mind.
(2) I want to claim a draw after I play a move, because only after I play this move will the draw condition be valid. I would like to send "move xxx" and then "draw".
Yes, that would be nice. But how would you make it work on an ICS, which can only solve the draw condition if you send it an extra command before the move.
(3) I want to offer a draw to my opponent. I would like to send "move xxx" and then "offer draw".
No problem there.
(4) My opponent offers me a draw. I would like to send "draw" and not send a move.
Same problem as with (1) and (2). There also is a race condition here in ICS play. (According to the old protocol specs; I never thought about why exactly.) The offer might no longer be valid. So now how would you want
draw to be processed in that case? The best you can do is make a counter offer. So you have to give a move, or you might forfeit on time. It is also very counter-intuitive that after being offered a draw, and accepting it, you still might have to play on (or forfeit on time). But this just can't be helped.
I do not see any race conditions, I do not think about any race conditions. I just do things in an order that a chess player would feel comfortable doing. The race condition is there, and the GUI has to handle it. When it sees "draw" from me, there are two possibilities. (a) the position before my move is a draw and the game should end. (b) if it sees draw and the current position is not a draw, it needs to back up to the position immediately following my last move and see if the claim would be valid there. That covers the race conditoin and doesn't even require a discussion of the race condition. At present, using the current offer draw, which could be fixed to work as I explained above, one still has to explain _why_ do I need to offer a draw before I make a move, when I want to claim a draw after making the move? Just let the draw (or offer draw if you insist) be given before _or_ after a move. And then see if it fits either of the two above circumstances. If so, end the game, if not, send the offer to the opponent. One can _still_ send offer draw before the move. Or one could send it after, and it would work exactly the same for those sending it before the move, and would also work correctly for those doing the more natural thing and offering after the move.
All the GUI has to do to handle a "draw/offer-draw" command is the following. Since it can not determine whether the draw claim should be applied after the last move by this player, or before the current move by this player, due to the already explained race condition, the GUI just asks itself two questions.
hgm wrote:[quote="bob""](1) If I back up to right after the last move played by the side claiming a draw, is this a drawn position, by rule? If so, end the game. If I wait until we reach the point where it is this player's move again, meaning after the opponent's move, is this a drawn position, by rule? If so, end the game. If neither is true, send a draw offer to the opponent and forget about it. This works in every possible case. It lets me claim a draw before I make a move, or even without making a move, and it lets me claim a draw _after_ I make a move that meets rule requirements.
Well, so far this is exactly how the
1/2-1/2 command is implemented. And I don't see a good reason to offer an alias for the
1/2-1/2 command. (Or in fact for any command.)
We are on different pages. In the last example that started this discussion, Crafty sent 1/2-1/2 _before_ making the move that repeated for the 3rd time. It was penalized with a loss. And you said this is _exactly_ what xboard does also.
[/quote]
OK, I have to apologize there, because I see now that I edited in this remark in a different place than for which it was intended. The "so far" was meant to refer to the "if so, it ends the game".
At the time I wrote "_exactly_" what XBoard does, it was not clear what exactly the problem was. My statement referred to penalizing it as a false claim, (as opposed to treating it s an offer, and try to wait if the engine wants to play on after it). I was under the impression that Crafty was sending
1/2-1/2 before the move after which it could claim. You were under the impression that Crafty was being forfeited for sending
offer draw. Only later it became apparent to me that the problem here was that ChessGUI had not properly resolved the race condition, nor implemented
offer draw as an advance claim. Had I realized that at the time, my answer would have been different.
So let us reset completely to remove all previous misunderstandings, and let me re-iterate here:
1) A
1/2-1/2 sent 'before your own move', without any draw condition present since the last move of the opponent, will be classified as "false claim", even if the following move draws.
2) A
1/2-1/2 sent 'after your own move' will be judged in the context of both the position immediately after that move, as well as the one before your next move (= after the opponent's move that follows). If either of those is a claimable draw or draw by rule, a draw is granted. If neither of them is a draw, it will be classified a "false claim".
Now the user decides if a false claim will be accepted anyway (old XBoard behavior), or if it will be corrected to a loss (forfeit) for the false claimer. In any case the game is terminated, as I consider this the primary function of a RESULT command, and the fact that it also gives the GUI a hint about the outcome only secondary.
Now to come back to your proposal:
So the difference between your proposed
draw command and the existing
1/2-1/2 is how it is treated in case of a false claim. It does not have the meaning of a game-termination, so the engine can be required to play on after it, and it makes sense to translate it to a draw offer to be relayed to the opponent, in that case.
So in a sense this new command serves no other purpose than to make it easier for engines to make false claims, without being caught. Well, I don't like that at all. Engines making buggy claims should be found out as quickly as possible, so they can be repaired. This is to the benefit of all involved parties. Hiding their bugs just makes life more difficult.
Further, you have repeatedly claimed that 1/2-1/2 says that a program is effectively refusing to continue. If you read my description above, this is not true at all. If I can claim a draw, I want to do so, otherwise turn it into an offer to my opponent. Where/when did you modify 1/2-1/2 to behave like that?
Another problem is that it does not work in ICS play. The ICS would not compare my "draw" command to the previous position when the opponent won the race. So in ICS play the GUI would have to send the "draw" to the ICS before the move. It cannot do that if you claim it after the move.
Sure it would. If one uses offer draw _before_ making the move, which is what is needed now for ICC, this would continue to work just fine.
Well, correct me if I am wrong, but it does not seem that this is contained in the description you gave of this proposed
draw command. You are only talking there about the position after the last move or before the next move of the claimer. Now you suddenly want to compare it to the position after the next move as well?
The draw offer after the move is problematic for ICC at the moment, and as I have already explained, draw/offer draw before the move would be a workable solution. I've already given up on 1/2-1/2 since we know that is not going to work.
OK, so the need to send some claim command before the move continues to exist. And the need to terminate the game by a
1/2-1/2 message will continue to exist, to not break the engine for running under old GUIs. Unless you provide some additional handshaking that would allow the engine to figure out if the GUI it is now running under supports
draw. How do yu propose to do that?
That I don't follow so I am not sure what you mean. You still have to send draw first to ICC, and then the move, separated by a \n character.
It refers to timing. The GUI sends a draw offer to an opponent engine just before it sends it your (remaining time+)move. Sending the move would have to make the opponent interrupt pondering anyway, so at this moment the draw offer cannot do any harm. In ICS or Human play, the GUI passes the offer to the ICS or Human immediately.
