Hello H.G.Muller : upgrading the protocol

[Matthias Gemuh]

Just to highlight redundantly what all this talk is about:


When your engine detects that the game has ended by rule, your engine must output a line of the form "RESULT {comment}",
(without the quotes), where RESULT is a PGN result code (1-0, 0-1, or 1/2-1/2), and comment is the reason.
Here "by rule" means that the game is definitely over because of what happened on the board

Therefore no move is to be expected after "1-0" {...}", or "0-1 {...}", or "1/2-1/2 {...}".

Matthias.

[bob]

Sorry, but that is false. If I send "result 1/2-1/2" then I am claiming, to the gui, that the game is over. Crafty sends no such string. If I send 1/2-1/2 then you are obligated to ignore it as it is not a part of the xboard protocol.

I now see where you misunderstand the protocol.

Code: Select all

RESULT {COMMENT}
    When your engine detects that the game has ended by rule, your engine must output a line of the form "RESULT {comment}" (without the quotes), where RESULT is a PGN result code (1-0, 0-1, or 1/2-1/2), and comment is the reason. Here "by rule" means that the game is definitely over because of what happened on the board. In normal chess, this includes checkmate, stalemate, triple repetition, the 50 move rule, or insufficient material; it does not include loss on time or the like. Examples:

      0-1 {Black mates}
      1-0 {White mates}
      1/2-1/2 {Draw by repetition}
      1/2-1/2 {Stalemate}

"RESULT" is used there as a general term for "0-1", or "1-0", or "1/2-1/2", as the examples show and all 3 terminate the game.

Matthias.

OK, this is my mistake. I originally implemented the "result" command in xboard. And I still use that original version. I had not noticed that the "result" prefix I had added was not in the code released by Tim. In this regard, ending a game when an engine says 1/2-1/2 is a wrong decision. I had this discussion with HGM a while back and I believe that this "result" parsing should be removed. Should I really be able to end a game on the spot? Or should that be the GUI's response since it sits between the two engines that are playing? I can't send 1/2-1/2 after the move I play, because by the time you see it, you may well have received the move from my opponent first, and now the draw claim is no longer valid.

There is a race condition here. There has always been a race condition here. "offer draw" and then "move xyz" solves it. Here's a key question: Exactly _how_ can the engine safely send 1/2-1/2 and tell you to end the game, without running the risk of losing? I gave the classic example I used to discuss this with Darooha on ICC 15 years ago when this was fixed. Your king is at h8, we both have a king and queen. We have shuffled pieces for 49.5 moves. Your 50th move was any move you want. My 50th move is Qh7+. The queen is en prise. But I get to claim the game is a draw by 50 move rule because for the past 50 moves by either side, no pawn has been pushed, no piece has been captured. So Qh7+ is a draw just like any other queen or king move (except for one that captures of course). send you "move Qh7+" and before you receive my "1/2-1/2" my opponent plays KxQ since it is forced as the only legal move. Now I lose a game that is correctly drawn according to the rules of chess. But the GUI screwed it up by not applying the "result" immediately after my move, even if it received it after my opponent's move.

This is simply not acceptable and is going to screw up game after game. Using your "result" methodology, it is impossible to make a valid claim 100% of the time. That is NFG with respect to the game of chess and it can be done correctly if the GUI wants. You _could_ say "OK, got a move, send it to opponent. Got a move from opponent, send it to player. Got a "result" from player. Obviously this result either applies to the current position (I can claim a draw after my opponent moves and before I move, without even having to make a move if the position meets the rules of chess). If the result doesn't match the current position, I should then look at the position after the player's last move to see if it matched then. It does. The game is a draw. If you (and HGM) want to adapt to that approach, it will work. Otherwise, we are left with claiming the draw before we make our move, even though we are talking about the game being drawn _after_ the move, to miss that race condition.

Either way this is a problem. But nowhere in the rules of chess published by FIDE will you find the statement "a false or incorrect draw claim results in a loss by the player making the claim." Yet that is _exactly_ what you are doing here. And it is simply wrong.

If I tell a TD/arbiter that this game is a draw, he can agree or say "play on". I can either continue playing, or I can leave the table and eventually lose on time. He won't end the game however. And his case is easier because we have the "clock button" issue. My opponent can't move until I press the button to start his clock. In the xboard protocol, this is not true and leads to an interesting ambiguity / race condition.

I just tested Crafty again, and I do not see how a "false draw claim" can be made. I set up a position where black wants to draw because white is winning. Crafty was black and perpetually checked me. On the third repetition, it sent "move Rb2+" and then "1/2-1/2 {draw by 3-fold repeitition} which is correct by any interpretation of the rules of chess that I can understand. I then set up a much longer 3-fold repetition. Crafty played exactly according to the rules, and after 10 moves showing a drawscore, it first offered me a draw and then played its move. Again, exactly according to the rules of chess...

I do not see how _any_ of this can lead to a loss according to the GUI. It's not like this is a new program. And all of this has been working just fine for 15 years. It has been tweaked to offer the draw before making the move to meet FIDE requirements since Crafty has played in a couple of events (Pan American event for one) where the FIDE rules are used.

It is not possible for Crafty to send 1/2-1/2 if the game is not truly drawn according to FIDE rules. But there is the issue of the timing hole between the GUI receiving the move and receiving the result, where the opponent can move and make the result invalid because of a GUI bug. If you can find a case where crafty sends 1/2-1/2 that is invalid, I'd certainly be interested in seeing it. I have gone thru about 1,000 log files from ICC games that ended in a draw, and in each case the result Crafty recorded matched exactly with the "result 1-0 {xxxxxx}" sent by xboard back to Crafty. ICC certainly will not let Crafty end a game in some artificial way, and xboard can not tell ICC to end a game, except by resigning or accepting a draw offer.

It would seem to me that if I can play about 100,000 games and not make any false draw claims through xboard, that something is working correctly.

Chess is not a "stateless" game. The GUI has to keep up with the game, and realize that there is a "window" around each move during which additional information might come in. Offer/claim a draw _before_ a move is played. A result comes in _after_ the move is played, which might appear to be before the next move is played (wrong assumption possibly).

It is complex. And what is currently happening in ChessGUI is wrong.

[bob]

RESULT {COMMENT}
When your engine detects that the game has ended by rule, your engine must output a line of the form "RESULT {comment}" (without the quotes), where RESULT is a PGN result code (1-0, 0-1, or 1/2-1/2), and comment is the reason. Here "by rule" means that the game is definitely over because of what happened on the board. In normal chess, this includes checkmate, stalemate, triple repetition, the 50 move rule, or insufficient material; it does not include loss on time or the like. Examples:
0-1 {Black mates}
1-0 {White mates}
1/2-1/2 {Draw by repetition}
1/2-1/2 {Stalemate}

xboard relays the result to the user, the ICS, the other engine in Two Machines mode, and the PGN save file as required. Note that "definitey over" above means that sending this command will be taken by WinBoard as an unconditional refusal of the engine to play on, which might cause you to forfeit if the game was in fact not over. This command should thus not be used to offer draws, accept draws, or make draw-by-rule claims that might not be valid (because it is not your move, and the opponent already moved without you knowing it yet). For offering and claiming draws, "offer draw" should be used.

(Note the green part was added by me, as explanation.)

Bob, you mix up the command that XBoard sends to the engines, to tell them the result (for learning), and the command that the engine sends to XBoard.

As Matthias says above, ChessGUI did not forfeit Crafty for sending offer draw (why the heck should it ever do that ever, on a draw offer???), but for sending 1/2-1/2). If you send offer draw + move, it is perfectly OK. But it is not what people claim this Crafty version sends.

Crafty _always_ sends the 1/2-1/2 _after_ it makes a move. But I can't force the GUI to read that before it reads an opponent's reply. But it _never_ sends the result first, unless the game is drawn without it needing to make a move.

I can find no case where this is not true. Granted, I have only looked at 1,000 games this morning, comparing the result crafty sends to the result command xboard sends back, to make sure the order that crafty sends the 1/2-1/2 in is correct. That does not seem to be what is happening here.

I am not looking for any fight with you, but I can only conclude from this thread so far:
1) Your knowledge of WB protocol is not as large as your confidence
2) Others seem to know better what Crafty sends than you do...

That I would _seriously_ doubt. I do have the source in front of me, and lots of data to support the statement that it is doing this correctly. The GUIs definitely have a race condition with respect to the 1/2-1/2, because it is a guess as to whether it goes with the move just played, or before the next move played. For 1/2-1/2 it comes out _after_ the move in Crafty. Always. Except for the case where crafty has to play no move and can just outright claim a draw without playing a move. Such as where Crafty has previously played 50 non-capture/non-pawn push moves, and the opponent played his 50th such move and chose to not claim a draw. Crafty can claim a draw instantly and does not have to even play a move according to FIDE rules. And it will. But that's the only time you see 1/2-1/2 without a move preceeding it...

I only came to this thread (after being invited in the title) to explain why a protocol extension is not needed. If you agree that offer draw + move does the trick, then everyone is happy. But stop talking nonsense about the protocol, and fix Crafty so that it prints what you intend it to print.

It already does.

[Matthias Gemuh]

OK, this is my mistake. I originally implemented the "result" command in xboard. And I still use that original version. I had not noticed that the "result" prefix I had added was not in the code released by Tim. In this regard, ending a game when an engine says 1/2-1/2 is a wrong decision. I had this discussion with HGM a while back and I believe that this "result" parsing should be removed. Should I really be able to end a game on the spot? Or should that be the GUI's response since it sits between the two engines that are playing? I can't send 1/2-1/2 after the move I play, because by the time you see it, you may well have received the move from my opponent first, and now the draw claim is no longer valid.

It is your turn to play, so GUI cannot process any move from opponent till you send your move or say you are quitting.

ChessGUI eliminates the race situation, by _automatically_ checking for ending of game after your move. Any "1-0", etc. coming in from you after your move is obselete and just discarded. ChessGUI does not depend on a result from you to tell opponent that your move ended the game.

The "result" command in the WB protocol should be dropped.
ChessGUI uses it only to penalize engines that use it to claim something wrongly.

If ChessGUI would want to use the command fully and without permitting a race, it would do the following:

- relay your move immediately to opponent, if GUI saw no end of game
- if GUI saw end of game after your move, your clock will continue ticking, while GUI waits just to see whether you will send a result. This would be just to find out whether you know when the game ends, and totally irrelevant for informing your opponent.

Matthias.

[krazyken]

RESULT {COMMENT}
When your engine detects that the game has ended by rule, your engine must output a line of the form "RESULT {comment}" (without the quotes), where RESULT is a PGN result code (1-0, 0-1, or 1/2-1/2), and comment is the reason. Here "by rule" means that the game is definitely over because of what happened on the board. In normal chess, this includes checkmate, stalemate, triple repetition, the 50 move rule, or insufficient material; it does not include loss on time or the like. Examples:
0-1 {Black mates}
1-0 {White mates}
1/2-1/2 {Draw by repetition}
1/2-1/2 {Stalemate}

xboard relays the result to the user, the ICS, the other engine in Two Machines mode, and the PGN save file as required. Note that "definitey over" above means that sending this command will be taken by WinBoard as an unconditional refusal of the engine to play on, which might cause you to forfeit if the game was in fact not over. This command should thus not be used to offer draws, accept draws, or make draw-by-rule claims that might not be valid (because it is not your move, and the opponent already moved without you knowing it yet). For offering and claiming draws, "offer draw" should be used.

(Note the green part was added by me, as explanation.)

Bob, you mix up the command that XBoard sends to the engines, to tell them the result (for learning), and the command that the engine sends to XBoard.

As Matthias says above, ChessGUI did not forfeit Crafty for sending offer draw (why the heck should it ever do that ever, on a draw offer???), but for sending 1/2-1/2). If you send offer draw + move, it is perfectly OK. But it is not what people claim this Crafty version sends.

I am not looking for any fight with you, but I can only conclude from this thread so far:
1) Your knowledge of WB protocol is not as large as your confidence
2) Others seem to know better what Crafty sends than you do...

I only came to this thread (after being invited in the title) to explain why a protocol extension is not needed. If you agree that offer draw + move does the trick, then everyone is happy. But stop talking nonsense about the protocol, and fix Crafty so that it prints what you intend it to print.

This is where the issue is, this part of the protocol is out of date, when it was written the GUI had no idea what the state of the game was and the choice was made to trust the engine in the claim. Now the GUI has changed, it has the ability to act as an arbiter. This is where the protocol needs to be updated, if the GUI is going to act as an arbiter, it needs to at least follow the rules of chess.

[krazyken]

OK, this is my mistake. I originally implemented the "result" command in xboard. And I still use that original version. I had not noticed that the "result" prefix I had added was not in the code released by Tim. In this regard, ending a game when an engine says 1/2-1/2 is a wrong decision. I had this discussion with HGM a while back and I believe that this "result" parsing should be removed. Should I really be able to end a game on the spot? Or should that be the GUI's response since it sits between the two engines that are playing? I can't send 1/2-1/2 after the move I play, because by the time you see it, you may well have received the move from my opponent first, and now the draw claim is no longer valid.

It is your turn to play, so GUI cannot process any move from opponent till you send your move or say you are quitting.

ChessGUI eliminates the race situation, by _automatically_ checking for ending of game after your move. Any "1-0", etc. coming in from you after your move is obselete and just discarded. ChessGUI does not depend on a result from you to tell opponent that your move ended the game.

The "result" command in the WB protocol should be dropped.
ChessGUI uses it only to penalize engines that use it to claim something wrongly.

If ChessGUI would want to use the command fully and without permitting a race, it would do the following:

- relay your move immediately to opponent, if GUI saw no end of game
- if GUI saw end of game after your move, your clock will continue ticking, while GUI waits just to see whether you will send a result. This would be just to find out whether you know when the game ends, and totally irrelevant for informing your opponent.

Matthias.

How does this apply to the case of a 3-fold repetition? The game is not over until one of the players claims it is over, and the claim is verified by the arbiter.

[Matthias Gemuh]

Crafty _always_ sends the 1/2-1/2 _after_ it makes a move.

No !

The reason Crafty forfeited in the game that started this discussion is that it sent the 1/2-1/2 while GUI was waiting for a move

Code: Select all

Eng1 &#40;Crafty 23.0 32-bit&#41; <- 21      1     437 7781866  72. Kf1
Eng1 &#40;Crafty 23.0 32-bit&#41; <- 21      1     935 16387909  72. Kf1
Eng1 &#40;Crafty 23.0 32-bit&#41; <- 22      1     935 16387910  72. Kf1
Eng1 &#40;Crafty 23.0 32-bit&#41; <- 22      1    2976 50514331  72. Kf1
Eng1 &#40;Crafty 23.0 32-bit&#41; <- 23      1    2976 50514332  72. Kf1
Eng1 &#40;Crafty 23.0 32-bit&#41; <- 1/2-1/2 &#123;Drawn by 3-fold repetition&#125;


Now in WB_EndOfGameClaim&#40;) at Time0000000939539828

Now in EndTheGame&#40;) at Time0000000939539828

0-1 &#123; Game Nr. 1 &#58; Crafty 23.0 32-bit resigns against ProDeo 1.6 
 GameDuration = 02&#58;15&#58;14, Finalposition 8/P7/5pk1/6pp/4P1nP/8/5KN1/6Qq w - - 11 72 &#125;
.

[Matthias Gemuh]

How does this apply to the case of a 3-fold repetition? The game is not over until one of the players claims it is over, and the claim is verified by the arbiter.

According to the WB protocol, a 3-fold-rep ends the game.

Matthias.

[krazyken]

How does this apply to the case of a 3-fold repetition? The game is not over until one of the players claims it is over, and the claim is verified by the arbiter.

According to the WB protocol, a 3-fold-rep ends the game.

Matthias.

Only if the engine claims it.

[michiguel]

Crafty _always_ sends the 1/2-1/2 _after_ it makes a move.

No !

The reason Crafty forfeited in the game that started this discussion is that it sent the 1/2-1/2 while GUI was waiting for a move

I wonder whether the sequence was

Code: Select all

crafty --> offer draw
                          GUI gets "offer draw" from Crafty
crafty --> move Rh8
                          GUI gets "move Rh8" from Crafty
                                 (here GUI should declare a 
                                   draw with the new behavior 
                                   of offer draw)
                          GUI gets "move Kb7" from opponent faster 
                                        than next command from Crafty
crafty --> 1/2-1/2
                          GUI sees that it is not a draw anymore.

Were you processing "offer draw" as the protocol now indicates?
What I just wrote is what could happen with the old behavior of winboard.

Miguel

Code: Select all

Eng1 &#40;Crafty 23.0 32-bit&#41; <- 21      1     437 7781866  72. Kf1
Eng1 &#40;Crafty 23.0 32-bit&#41; <- 21      1     935 16387909  72. Kf1
Eng1 &#40;Crafty 23.0 32-bit&#41; <- 22      1     935 16387910  72. Kf1
Eng1 &#40;Crafty 23.0 32-bit&#41; <- 22      1    2976 50514331  72. Kf1
Eng1 &#40;Crafty 23.0 32-bit&#41; <- 23      1    2976 50514332  72. Kf1
Eng1 &#40;Crafty 23.0 32-bit&#41; <- 1/2-1/2 &#123;Drawn by 3-fold repetition&#125;


Now in WB_EndOfGameClaim&#40;) at Time0000000939539828

Now in EndTheGame&#40;) at Time0000000939539828

0-1 &#123; Game Nr. 1 &#58; Crafty 23.0 32-bit resigns against ProDeo 1.6 
 GameDuration = 02&#58;15&#58;14, Finalposition 8/P7/5pk1/6pp/4P1nP/8/5KN1/6Qq w - - 11 72 &#125;
.