xboard protocol - a compromise that would work

[bob]

Here is an idea.

1. "offer draw" is kept, and we add a new command "draw" that will be treated exactly the same as offer draw. I think this is still needed because using "offer draw" to _claim_ a draw seems wrong and unintuitive. So we have both. A program can use either, or both, and xboard will behave the same no matter which is used.

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.

What this does is eliminate the race condition we have been discussing, and it also adds some intuitiveness to the protocol. I can now claim a draw _before_ I make a move and not even have to make one if my claim is correct. I can claim a draw after my move and have it accepted even if my opponent slips in a quick reply.

This really addresses the intuitiveness of the process so that a chess player would be able to figure this out by doing just what he does in a real game. You can claim a draw before you move anything, you can claim a draw after you make your move before stopping your clock. You can offer a draw before you send a move, which is legal but unusual, or you can offer a draw after you make a move which is more common.

Now there is no ambiguity or race condition. And if one wants to be precise, you can use "draw" to claim a draw and "offer draw" to offer a draw (although they are treated the same way) to match FIDE rules in human play.

All that is really new is the alias of "draw" to the current "offer draw". And the idea that when a draw/offer-draw comes in, you have to test the board condition immediately after that player's last move, and the board state immediately prior to that players next move, since the timing about when you see the draw/offer-draw is not predictable.

Any significant problem with two different commands that do the same thing, but which at least provide something that looks intuitive to a chess player?

[Matthias Gemuh]

Here is an idea.

1. "offer draw" is kept, and we add a new command "draw" that will be treated exactly the same as offer draw. I think this is still needed because using "offer draw" to _claim_ a draw seems wrong and unintuitive. So we have both. A program can use either, or both, and xboard will behave the same no matter which is used.

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.

What this does is eliminate the race condition we have been discussing, and it also adds some intuitiveness to the protocol. I can now claim a draw _before_ I make a move and not even have to make one if my claim is correct. I can claim a draw after my move and have it accepted even if my opponent slips in a quick reply.

This really addresses the intuitiveness of the process so that a chess player would be able to figure this out by doing just what he does in a real game. You can claim a draw before you move anything, you can claim a draw after you make your move before stopping your clock. You can offer a draw before you send a move, which is legal but unusual, or you can offer a draw after you make a move which is more common.

Now there is no ambiguity or race condition. And if one wants to be precise, you can use "draw" to claim a draw and "offer draw" to offer a draw (although they are treated the same way) to match FIDE rules in human play.

All that is really new is the alias of "draw" to the current "offer draw". And the idea that when a draw/offer-draw comes in, you have to test the board condition immediately after that player's last move, and the board state immediately prior to that players next move, since the timing about when you see the draw/offer-draw is not predictable.

Any significant problem with two different commands that do the same thing, but which at least provide something that looks intuitive to a chess player?

Maybe some will think I accept anything, but your proposal sounds OK for me. You have carefully got rid of "result {draw}" , right ?

Matthias.

[bob]

Here is an idea.

1. "offer draw" is kept, and we add a new command "draw" that will be treated exactly the same as offer draw. I think this is still needed because using "offer draw" to _claim_ a draw seems wrong and unintuitive. So we have both. A program can use either, or both, and xboard will behave the same no matter which is used.

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.

What this does is eliminate the race condition we have been discussing, and it also adds some intuitiveness to the protocol. I can now claim a draw _before_ I make a move and not even have to make one if my claim is correct. I can claim a draw after my move and have it accepted even if my opponent slips in a quick reply.

This really addresses the intuitiveness of the process so that a chess player would be able to figure this out by doing just what he does in a real game. You can claim a draw before you move anything, you can claim a draw after you make your move before stopping your clock. You can offer a draw before you send a move, which is legal but unusual, or you can offer a draw after you make a move which is more common.

Now there is no ambiguity or race condition. And if one wants to be precise, you can use "draw" to claim a draw and "offer draw" to offer a draw (although they are treated the same way) to match FIDE rules in human play.

All that is really new is the alias of "draw" to the current "offer draw". And the idea that when a draw/offer-draw comes in, you have to test the board condition immediately after that player's last move, and the board state immediately prior to that players next move, since the timing about when you see the draw/offer-draw is not predictable.

Any significant problem with two different commands that do the same thing, but which at least provide something that looks intuitive to a chess player?

Maybe some will think I accept anything, but your proposal sounds OK for me. You have carefully got rid of "result {draw}" , right ?

Matthias.

The _only_ reason Crafty has used the result feature is that in times past, someone had to tell old versions of xboard "the game is over". I'd prefer that the result stuff be completely eliminated. I do not believe that an engine should be able to end the game other than by resigning, otherwise the GUI should be the final authority and terminate the game when appropriate. If an engine can make a bad claim and end the game improperly, that is bad. If the GUI can determine that the result is wrong, then why even bother with it. Just ignore it and end the game when the FIDE rules say it should be ended and not before.

A player can resign and end the game. His flag can fall, which ends the game. The board can reach a checkmate, stalemate, or insufficient material state to end the game. The players can negotiate a draw to end the game. And for repetition/50-move draws, a player _must_ make a proper claim, at the instant the claim is valid. This can be before or after making a move. My simple suggestion above is primarily to get rid of the "offer draw" to "claim a draw" which is unintuitive to real chess players. The semantics HGM described for offer draw is fine, if we just duplicate that for "draw". It seems more natural to offer a draw when you expect your opponent to either accept or decline. It seems more natural to just say "draw" when you believe the game is drawn to rule...

[Matthias Gemuh]

The _only_ reason Crafty has used the result feature is that in times past, someone had to tell old versions of xboard "the game is over". I'd prefer that the result stuff be completely eliminated. I do not believe that an engine should be able to end the game other than by resigning, otherwise the GUI should be the final authority and terminate the game when appropriate. If an engine can make a bad claim and end the game improperly, that is bad. If the GUI can determine that the result is wrong, then why even bother with it. Just ignore it and end the game when the FIDE rules say it should be ended and not before.

Yes, the protocol can limit the claiming of end-of-game to 3-fold-rep/50-move-rule through "draw". This would not be a problem in ChessGUI because GUI knows the game state of each chess variant it supports.

Matthias.

[hgm]

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.

[Matthias Gemuh]

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.

[hgm]

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?

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

I didn't say a word about a new feature, or feature recognition. As a human, playing real chess, and then deciding to write a chess program, I want to know how to make the program play legal chess, and I have a framework for how that works, since I have been playing by FIDE/USCF rules (or others of course).

While the protocol is not meant to be human-readable, it does need to be human-logical. And using "offer draw" to claim a draw simply does not pass the smell test.

If you are going to take up the WB support, which is great, then you can do what you want. I do not think I need to learn a new "language" in order to interface my new engine to play chess thru a third-party GUI. I think the protocol should be logical, precise, and understandable. Yes, you could use "mayonnaise jar" to offer or claim a draw. And it would be just as counter-intuitive as using offer draw.

A couple of us that both play real chess and work on an engine have explained the problem we see. Claiming a draw before you make a move, that applies after you make a move, is, at the very least, confusing. Ignoring the race condition when doing this properly is a poor design. As a human I am trying to remember how I do this in real tournaments, and then have my engine emulate that, only to discover that this is incorrect with the current protocol. That _is_ confusing. Most didn't even understand the race condition until it was explained in careful detail. Good protocols don't have race conditions in the first place, just as good parallel search algorithms do not. It's easy enough to make a GUI handle draw offers and claims correctly. I've done so. And I found it better to modify the way the xboard protocol deals with draws so that the process is both logical and race-free. We've sort of worked out the "race-free" issue, finally, but not the "logical".

If we can't, then we can't...

I don't even see a problem with allowing multiple aliases to each winboard protocol command. No reason a spanish-speaking person could not use spanish words, IMHO. My major concerns are (a) "offer draw" to claim a draw. and (2) using offer draw _before_ a move, to claim a draw _after_ the move. Why not a more logical "send the draw (or offer draw if you insist) before the move if it makes sense, or after the move. And let the GUI determine what is meant. Before the move means the draw claim either should be valid after the _previous_ move and before any reply by the opponent, or it should be valid in the current position before my next move but after my opponent has moved so that it is my turn again. That solves the race, and means I can send a draw claim before I move, which is perfectly legal. Or I can send it after I move, which is the way normal offers are made anyway and since we don't have a clock to stop, it is the logical way to say "I claim a draw by repetition after my last move."

Anything else is unclear and will always lead to mistakes. Whether we have two commands to offer or claim a draw, which is natural to me since the two operations are _completely_ different anyway, or we have just one offer draw command (with an alias of "draw" preferred so that it looks like we have two commands even if we don't) doesn't make that much difference.

[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. The case of claiming a draw before or after a move is already handled by FIDE rules. And the two cases are different. The case of offering a draw is also defined by FIDE rules. And the two actions are not covered in the same sentence, because they are not the same action.

The justification I am seeing is utter nonsense. "The old protocol is broken, but I won't change it because some programs depend on the broken behavior." Even though this completely ignores the fact that I have intentionally called this protocol version 3. Old programs can _still_ use WB1 or WB2 and obtain the _same_ broken behaviour we have right now.. New programs, or authors wanting to make sure their programs meet FIDE rules for human events by outputting draw offers / claims at the appropriate points in their program, can also use WB3 and send the equivalent commands _at the same point in their program_ so that the code looks like something written by a professional, rather than something thrown together by a rank beginner.

But it appears we are not going to go there. Wish Tim had not changed jobs and dropped xboard/winboard development, because he was willing to listen, think, and try to make things as logical and understandable as possible.

[hgm]

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.