xboard protocol - a compromise that would work

[bob]

9.4:If the player makes a move without having claimed the draw he loses the right to claim

This applies to cases where the position before the move was already a draw, not?

No. If you want to claim a draw, where the position is a draw before you move, you just claim the draw and call the arbiter, without making a move. You do stop the clock. If you want to claim a draw where the position is a draw after your move, you write it down, stop the clock and call the arbiter to make the claim.

The procedure is a bit whacky. But it is very precisely defined so that there can be no question of how it is to be carried out. Of all lthe things I have dealt with in tournaments I have run (I used to run a weekly chessclub event, plus a couple of weekenders several years back) this has been the greatest source of confusion and controversy.. Probably part of it comes from the problem that just stopping the clock is not a sure thing. You can press your button half-way, and stop things, but if you go too far and start your opponent's clock, and then try to stop his clock, that would be a problem. The FIDE approach eliminates that bit of contention.

[bob]

6.8 During the game each player, having made his move on the chessboard, shall stop his own clock and start his opponent`s clock. A player must always be allowed to stop his clock. His move is not considered to have been completed until he has done so, unless the move that was made ends the game. (See Articles 5.1, and 5.2)
The time between making the move on the chessboard and stopping his own clock and starting his opponent`s clock is regarded as part of the time allotted to the player.

This rule actually casts doubt on that: If you claim between moving on the board and pressing your clock, formally you claim during your move. I would say that means you have not made a move yet, and thus that the claim is still valid.

I noticed one thing funny, though:

According to these rules, when I am about to checkmate my opponent with my 50th reversible move, write the move down, tell the referee I intend to make it, and claim a draw, the game will be a draw!

I don't think so. FIDE has always had the rule that the game ends by checkmate before any other consideration. I remember this exact type of case coming up once, when I was playing (it was not in my game) where one side had played 50 reversible moves, the other had played 49, and played the 50th move which checkmated the opponent. It was a rush (low time) and he did not notice the checkmate. His opponent studied for a second, and then called the arbiter to claim a 50 move draw. The game was ruled a win by the side that checkmated, and a specific FIDE rulebook was used to verify that "checkmate on the board trumps all other rules."

[bob]

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.

Of course not. But what I have in mind is an evolution of the WB protocol where a more logical phrasing _can_ be used, perhaps thru protover 3. It took years before most everyone moved to protover 2. But even without protover 3, recognizing "draw" will not break existing programs, since they won't be using it. It can be added to protover 2 safely since it won't hurt anyone.

Probably this discussion is moot for 99% of computers anyway, how many really play in human events (not via ICC or whatever) where this is important?

(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.

No argument there. Sleator fixed this in a straightforward way after lengthy discussions 15 years ago or so. Had I thought of it at the time, I would have suggested my current idea to resolve the unusual requirement. However there are at least ways to word this better on a server, in that I can send "tellics draw" when I want rather than "tellics offer draw". My goal was to get rid of the "tellics" completely and let the gui relay my offer to my opponent no matter whether it is a human using the GUI to play, another engine, or a player on ICC>

(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.

About all you can do is what we currently do. If I am offered a draw, I send draw to accept. It might be that the offer is no longer valid. In which case my "acceptance" will be treated as a draw offer itself. In 1 0 bullet games, we see this kind of silliness from time to time, Race conditions are much more exposed on internet play due to the longer transmission time.

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.

[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.

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.[/quote]

[Matthias Gemuh]

How long does a 3-fold-rep or 50-move-rule pend, if not claimed ?
Till end of game ?

Matthias.

[bob]

OK, so that would e reevant for Bob to know, because he claimed that Crafty did send offer draw. So there still is confusion about what exactly happened.

If Crafty sent 1/2-1/2 before a draw condition had ever appeared (i.e. neither after his last move, or before its next move), then also XBoard would forfeit it. It would not take into account thet there is a claimable draw after the next move.

The old protocol specs clearly state this as illegal use of the 1/2-1/2 command. That in practice you would get away with it on old XBoard was only because of a bug in its handling of RESULT commands (namely believeng the engine unconditionlly).

In looking at the code, Crafty uses "offer draw" when it wants to offer a draw. I do this when I have seen the draw score at the root for N consecutive moves (N varies depending on opponent rating, since weaker players might not see the position is drawish and make a mistake). I do not use "offer draw" to claim a draw at present, since it is counter-intuitive. In the game in question, Crafty probably assumed that the opponent did not want the draw and could avoid it by playing a different move that would still leave it positionally ahead. But once the repetition is actually found at the root (3-fold, not 2) it will instantly claim it. The 1/2-1/2 was sent dirst to avoid the race condition. I patched my version of xboard years ago to deal with this. If I send the 1/2-1/2 after my move, it is effectively pointless since the race condition can cause the claim to be invalid there. The bottom line is that 1/2-1/2 simply does not work with 100% reliability in any current GUI. If I have to send my move first, my opponent can reply and break the draw condition before my draw claim (1/2-1/2) is even seen, and when it comes in, and is rejected, I lose. If I send it before my move, and the GUI doesn't know to try to apply it after my move, I lose.

I think anyone can see the problem. 1/2-1/2 is just another way to "resign".

My program is perfectly capable of continuing to play after the 1/2-1/2 command, if it is rejected. But since you were adamant that this "ends the game" I proposed a "draw" command that is "softer". I can make the claim before making a move to claim a drawn position before I make a move, I can make the claim after the move to claim a drawn position after making the move that produces the drawing condition. And the obvious race can either be handled by the gui or not, without Crafty losing the game if the GUI disagrees because it doesn't handle the race.

After some thought, the draw after the move is probably not a good idea because it is an issue with ICC. I think, therefore, that that would be a bad idea. However, I still don't like "offer draw". The alternative is to fix 1/2-1/2 so that it works reasonably. I claim 1/2-1/2. If it is valid, the game ends. Otherwise, you try it _after_ my move. If it is valid, the game is a draw. At this point, you can then give me a loss if the claim is wrong (it never will be). And we have eliminated the race condition

[bob]

How long does a 3-fold-rep or 50-move-rule pend, if not claimed ?
Till end of game ?

Matthias.

3-fold can only be claimed at the instant it happens. Or if missed, one can claim a 3-fold repetition after 4, 5, 6, ..., N repetitions just as correctly. A 50 move draw can be claimed at any time after the 50 reversible moves by both sides, and for as long as no reversible move has been played. Once that happens, the draw can not be claimed until another 50 reversible moves have been played by both sides.

As far as the draw "claim" it should be tried before the move, and after the move, and if it doesn't fit either, it should disappear. In the case of the 1/2-1/2 Crafty sends, if it doesn't fit before or after the move, you could record it as a loss because this will never happen unless I introduce a bug.

The only issue is the case of a draw after my move, and the resulting race condition that almost makes it necessary to make the claim before the move.

[wgarvin]

[...] what I have in mind is an evolution of the WB protocol where a more logical phrasing _can_ be used, perhaps thru protover 3. It took years before most everyone moved to protover 2. But even without protover 3, recognizing "draw" will not break existing programs, since they won't be using it. It can be added to protover 2 safely since it won't hurt anyone.

That is only true if you also add a "feature" flag and require that engines check the feature for acceptance before using it. Which seems almost as clunky as just bumping it to protover 3. Adding features to the protocol is only safe if BOTH the engine and the GUI are aware of, and can correctly handle, the new feature.

[bob]

[...] what I have in mind is an evolution of the WB protocol where a more logical phrasing _can_ be used, perhaps thru protover 3. It took years before most everyone moved to protover 2. But even without protover 3, recognizing "draw" will not break existing programs, since they won't be using it. It can be added to protover 2 safely since it won't hurt anyone.

That is only true if you also add a "feature" flag and require that engines check the feature for acceptance before using it. Which seems almost as clunky as just bumping it to protover 3. Adding features to the protocol is only safe if BOTH the engine and the GUI are aware of, and can correctly handle, the new feature.

Note that if you add a _new_ feature, and don't tell anyone, there is no way it can affect their program. Or if you add a new feature that is not mandatory, then it can coexist with the old features since it has no effect on them at all. In this case a "draw" command would be new. Anyone not using it would continue to use the old commands and have to deal with the potential race condition as they do now.

So this is a suggestion that really doesn't change the behavior of a GUI for existing programs, except that they can migrate to the new draw claim mechanism and solve the program of the race that currently exists in most GUIs.

[hgm]

"checkmate on the board trumps all other rules."

True, but my point was that the checkmate would not be on the board. Only on the score sheet. So the rule that the game immediately ends on checkmate cannot be invoked.

Of course a prson that can checkmate in one is not likely to claim a 50-move draw in stead, but it does seem an inconsistency in the rules.

I know that in my days as an active player, there were aways big rows when the flag fell after the checkmate but before the one performing the mate could press the clock. How is that resolved, nowadays? Practical consideration of course say that it should be counted as a loss, i.e. it should only be considered a checkmate after the clock was pressed. Ther is no way to prove the flag falling before or after any other event (e.g. releasing the piece, or grabbing it).

[hgm]

In looking at the code, Crafty uses "offer draw" when it wants to offer a draw. I do this when I have seen the draw score at the root for N consecutive moves (N varies depending on opponent rating, since weaker players might not see the position is drawish and make a mistake). I do not use "offer draw" to claim a draw at present, since it is counter-intuitive. In the game in question, Crafty probably assumed that the opponent did not want the draw and could avoid it by playing a different move that would still leave it positionally ahead. But once the repetition is actually found at the root (3-fold, not 2) it will instantly claim it. The 1/2-1/2 was sent dirst to avoid the race condition.

Yes, and this is the problem. This is illegal use of the 1/2-1/2 command. The game is not over yet before you announce your move. You only got away with it because XBoard accepted any RESULT claim in any situation. (Much to your, or anybody's chagrin.) It is this situation I was referring to when I id that current XBoard would do exactly the same as what ChessGUI did.

I patched my version of xboard years ago to deal with this. If I send the 1/2-1/2 after my move, it is effectively pointless since the race condition can cause the claim to be invalid there. The bottom line is that 1/2-1/2 simply does not work with 100% reliability in any current GUI.

You mean in ICS play. In loca play it always worked in XBoard. In old versions because any claim, no matter how silly, would be accepted, and in current XBoard because it is aware of the race condition, and checks your claim against both the position before and after the opponent's move.

If I have to send my move first, my opponent can reply and break the draw condition before my draw claim (1/2-1/2) is even seen, and when it comes in, and is rejected, I lose. If I send it before my move, and the GUI doesn't know to try to apply it after my move, I lose.

I think anyone can see the problem. 1/2-1/2 is just another way to "resign".

If sending either before or after the move does not help, do both. Before the move you send offer draw, because it is harmless on any old or new GUI, and has the effect that the ICS requires, namely that "draw" is sent to the ICS. Then send move, and then 1/2-1/2. The ICS will by that time have granted you a draw. And in local play, ay GUI that respecys the protocol should now grant you a draw, if it hasn't already done so. Othrwise it will be the fault of the GUI, as in lcal play it canot hide behind the ICS, and is the final authority, responsible for all its actions.

My program is perfectly capable of continuing to play after the 1/2-1/2 command, if it is rejected. But since you were adamant that this "ends the game" I proposed a "draw" command that is "softer". I can make the claim before making a move to claim a drawn position before I make a move, I can make the claim after the move to claim a drawn position after making the move that produces the drawing condition. And the obvious race can either be handled by the gui or not, without Crafty losing the game if the GUI disagrees because it doesn't handle the race.

After some thought, the draw after the move is probably not a good idea because it is an issue with ICC. I think, therefore, that that would be a bad idea. However, I still don't like "offer draw". The alternative is to fix 1/2-1/2 so that it works reasonably. I claim 1/2-1/2. If it is valid, the game ends. Otherwise, you try it _after_ my move. If it is valid, the game is a draw. At this point, you can then give me a loss if the claim is wrong (it never will be). And we have eliminated the race condition