xboard protocol - a compromise that would work

[Matthias Gemuh]

As we have reached a dead-end, my decision is to solve the race issue with HGM's proposal, to stay in sync with Winboard/Xboard.

So the sequence in ChessGUI will be
- offer draw
- move
- draw claim

In all cases where a move definitely ends the game OTB, ChessGUI will (as it now does) ignore whatever claim the engines say.

Matthias.

[Uri Blass]

WB protocol is not meant to be read by Humans. So IMO it carries zero weight that it is counter-intuitive. (As it is almost everywhere.) I think it is a really bad idea to provide synonyms for WB commands just because someone does not like the wording of them in the curent protocol. Before you know it we would have a French version of the protocol, a German, and Italian...

What you propose serves no purpose and is in fact very damaging: new authors that would be so unaccustomed to the protocol that they apply it by intuition rather than by following specs would tend to use the new, intuitive command. Which would break their engine for working on other GUIs, or on older versions of the same GUI. Expert users would have to engage in hand-shaking to make sure their engine works on any GUI, send something like feature drawsynonym=1, abd test if they receive rejected drawsynonym back, and if they do, send offer draw anyway in stead of draw. Now does that sound intuitive to you?

A protocol should only be changed in cases of extreme need, if something does not work. That some commands are worded in a counter-intuitive way, does not count as such.

That refutes Bob's point (1).
What about point (2) ?

Matthias.

How does that refute _anything_? Only a non-chessplayer would agree that "offer draw" is a reasonable way to either offer your opponent a draw, or claim the current position either before or after my move is a draw.

I agree and I never used the offer draw to claim a draw with movei.

If I want to claim a draw based on repetition after my move then I make the move and immediately after making my move claim a draw(and immediately means in less than 0.01 seconds).

If you want to be consistent with human play then you can simply have a rule that there is a delay of 0.02 seconds between making the move and giving it to the opponent(this is always the case with humans in OTB games because nobody can press the clock faster than 0.02 seconds)
so if you get a draw claim in the relevant 0.02 seconds you do not need to give the move to the opponent.

This can be a problem in testing at very fast time control like 1 seconds per game but you can remove the delay for testing if you do not like it and want your test to be finished faster.

Edit:

thinking about it again there may be even a better solution.

The delay of 0.02 seconds does not need to be for every move.
The gui can calculate if there is a reason to claim a draw by repetition or by the fifty move rule in less than 0.001 seconds and only in case that the gui finds that there is a valid reason to claim the gui can decide about a delay of 0.02 seconds to allow the engine to claim a draw after the move if the engine likes to do it.

Uri

[Matthias Gemuh]

The delay of 0.02 seconds does not need to be for every move.
The gui can calculate if there is a reason to claim a draw by repetition or by the fifty move rule in less than 0.001 seconds and only in case that the gui finds that there is a valid reason to claim the gui can decide about a delay of 0.02 seconds to allow the engine to claim a draw after the move if the engine likes to do it.

Uri

Bob did not like that "time kludge".

Matthias.

[bob]

WB protocol is not meant to be read by Humans. So IMO it carries zero weight that it is counter-intuitive. (As it is almost everywhere.) I think it is a really bad idea to provide synonyms for WB commands just because someone does not like the wording of them in the curent protocol. Before you know it we would have a French version of the protocol, a German, and Italian...

What you propose serves no purpose and is in fact very damaging: new authors that would be so unaccustomed to the protocol that they apply it by intuition rather than by following specs would tend to use the new, intuitive command. Which would break their engine for working on other GUIs, or on older versions of the same GUI. Expert users would have to engage in hand-shaking to make sure their engine works on any GUI, send something like feature drawsynonym=1, abd test if they receive rejected drawsynonym back, and if they do, send offer draw anyway in stead of draw. Now does that sound intuitive to you?

A protocol should only be changed in cases of extreme need, if something does not work. That some commands are worded in a counter-intuitive way, does not count as such.

That refutes Bob's point (1).
What about point (2) ?

Matthias.

How does that refute _anything_? Only a non-chessplayer would agree that "offer draw" is a reasonable way to either offer your opponent a draw, or claim the current position either before or after my move is a draw.

I agree and I never used the offer draw to claim a draw with movei.

If I want to claim a draw based on repetition after my move then I make the move and immediately after making my move claim a draw(and immediately means in less than 0.01 seconds).

Same problem. Same mistake. Just because you _send_ the claim within .01, that does not mean that the GUI reads that command before it gets the response from the opponent which may well invalidate your claim. That is the problem here. The only solution HGM wants to offer is to use "offer draw" _before_ you make the move, to claim a draw that only occurs _after_ the move. I claim that is illogical to someone that plays chess OTB. In fact, that particular idea is illogical to _anyone_. It's a kludge, and there is another way to solve this, and by using a more natural-looking command the illogical look goes away. But we are not going to get that, it would appear.

If you want to be consistent with human play then you can simply have a rule that there is a delay of 0.02 seconds between making the move and giving it to the opponent(this is always the case with humans in OTB games because nobody can press the clock faster than 0.02 seconds)
so if you get a draw claim in the relevant 0.02 seconds you do not need to give the move to the opponent.

I have explained this before. _no_ protocol will work if it depends on a time delay. How can you guarantee that immediately after you make your move, before you make the claim, that your process doesn't get suspended for a hundred milliseconds or two for a system task to run? You can't, and it just won't work. Either the GUI has to get creative, become aware of the timing issue, and deal with it internally, or else has to support some sort of "I am finished" sentinel such as "press clock" to signify that _everything_ has been received from me when you get this command..

This can be a problem in testing at very fast time control like 1 seconds per game but you can remove the delay for testing if you do not like it and want your test to be finished faster.

Edit:

thinking about it again there may be even a better solution.

The delay of 0.02 seconds does not need to be for every move.
The gui can calculate if there is a reason to claim a draw by repetition or by the fifty move rule in less than 0.001 seconds and only in case that the gui finds that there is a valid reason to claim the gui can decide about a delay of 0.02 seconds to allow the engine to claim a draw after the move if the engine likes to do it.

Uri

Or the GUI can just take the command "draw" and make two checks. (1) is the claim valid right after this player made his last move, even if his opponent has already made a move in reply? (2) is the claim valid right before the next move by the same player? This way you can claim a draw before or after your move, as you do in real chess games, and the GUI deals with the race condition internally and makes it work as it should without the program even being aware that there might be a problem with a race, since the GUI has eliminated it.

[bob]

The delay of 0.02 seconds does not need to be for every move.
The gui can calculate if there is a reason to claim a draw by repetition or by the fifty move rule in less than 0.001 seconds and only in case that the gui finds that there is a valid reason to claim the gui can decide about a delay of 0.02 seconds to allow the engine to claim a draw after the move if the engine likes to do it.

Uri

Bob did not like that "time kludge".

Matthias.

Because it will not work. You can't cure race conditions by introducing a time delay. That is what causes the race condition in the first place. Try to write a parallel search with no locks, just delays to prevent two threads from overwriting the same variable, to get a feel for the scope of the problem.

[bob]

I didn't say a word about a new feature, or feature recognition.

Indeed, and that is cause for grave worry.

Don't you realise that defining new engine->GUI commands is pointless if the engine cannot know if the GUI will understand the command or not? There is only one course of action an engine can take, and that is: not use the new command.

(1) I gave a simple way to correctly deal with offering draws, and claiming draws, which suffer from no race condition at all. Ever.

(2) I gave a simple alias to "offer draw" so that a program can use "offer draw" to offer a draw, and "draw" to claim a draw, which is more natural to a chess program. It would be possible to interchange the two commands without having any effect on the GUI since the two commands are identical.

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.

(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. It does let me offer a draw in an inopportune time, but that is OK and the GUI should be able to prevent me from offering millions of draws in succession to interfere with my opponent's search. In a normal OTB game, I make a move, tell my opponent "I offer a draw" and press the clock. The program author follows that same guideline when writing an engine, and it will work every time, without fail. It won't break old engines. It won't break old GUIs any more than they are already broken. It won't cause any problems. And it solves at least one big one, plus a couple of minor understandability issues for those that play tournament chess themselves.

[bob]

2. offer draw / draw says the following. When you receive this command, check the position on the board where it is my turn to move. If this comes in before my move, it is obvious that I mean the position immediately prior to my move, or else the position immediately following my move. So check the position right after my last move to see if it is a valid draw claim. If so, the game ends. If not, check the position just before my _next_ move to see if it is a valid draw claim. If so, the game ends. If neither of the above is true, then send a draw offer to my opponent. In fact, for any draw claim, the GUI _should_ also send a draw offer to the opponent according to the FIDE rules.

I am not sure what is proposed here. First it says that the offer / claim pertans to the position immedately before or after my move (presumably the next move). But then in the detail explanation, it suggest we shoud compare against the position after my last or before my next move, which is before or after the opponent's last/next move.

If you want to make it possible for engines to claim a draw in the current position, it is subject to the race condition, as 'current position' is not a well-defined concept: it can be either the position before or after the opponent's move. So it would have to be compared to two positions: the positions between your own last and next move.

Currently, offer draw is used to claim a draw after your next move.

So it seems to me that in order to allow usage of offer draw for claiming in the current position as well, you would have to compare it to 3 positions.

The new situation in which offer draw could be used to claim a draw is exactly the same situation in which 1/2-1/2 can be used to claim a draw. So in addition to a way of claiming a draw that should always work (according to protocol specs) and which most engines use (as this was old specs), we would now be providing a second way to do this, which would not always work. (Namely in every currently existing GUI.)

So what exactly would be the benefit? How would engines claim rep-draws in the two posible cases (i.e. occurring before or after their next move) in a way that would work on both old and new GUIs?

The issue is, when you recieve a "draw" command, since the command is overloaded to offer and accept and claim draws, you have to determine the following.

1. This could be a claim that was made after my last move. Obviously you have to unmake the opponent's move if he replied very quickly, to get back to that position. Is it a draw by rule? If so, end the game.

2. This could be a claim that is intended to be applied _before_ I make a move. And in fact, I might not plan on making a move here since the position before my move is a draw by rule. So you wait until it is my move and make the check and end the game if appropriate.

3. In the case of 2, it is _possible_ that you see the timing mymove, opponent'smove, my draw command. Obviously I meant for you to see mymove, myclaim. But you can not recognize whether the proper order is mymove, myclaim, opponentmove, or mymove, opponentmove, myclaim. So you have to try it both ways If you get my draw command, and don't yet have a move from my opponent, you can process the command right now and not try again before my next move.

4. Finally, if none of the above end the game, send my opponent a draw offer as that is the only possible remaining meaning of the overloaded command.

I would _prefer_ to use "offer draw" to offer a draw, and "draw or claim draw" to claim a draw and get rid of the overloading, but the above will work. I only suggest adding the "draw" as an alias for "offer draw" so that I don't have to do the ugly "offer draw" to claim a draw.

[michiguel]

The delay of 0.02 seconds does not need to be for every move.
The gui can calculate if there is a reason to claim a draw by repetition or by the fifty move rule in less than 0.001 seconds and only in case that the gui finds that there is a valid reason to claim the gui can decide about a delay of 0.02 seconds to allow the engine to claim a draw after the move if the engine likes to do it.

Uri

Bob did not like that "time kludge".

Matthias.

Of course, it is violent hack to patch a whole.

Miguel

[krazyken]

I didn't say a word about a new feature, or feature recognition.

Indeed, and that is cause for grave worry.

Don't you realise that defining new engine->GUI commands is pointless if the engine cannot know if the GUI will understand the command or not? There is only one course of action an engine can take, and that is: not use the new command.

Isn't this what happened when "offer draw" took on extra functionality? How is an engine to know when offer draw can also be used to make a claim?

[krazyken]

It would seem to me the obvious answer is to alias "1/2-1/2" to "offer draw" in GUIs that are capable of arbitration.