Engine authors, beware of false-draw-claim forfeits!

[hgm]

It seems that several strong engines do violate FIDE rules and WinBoard protocol by claiming repetition or 50-move draws without announcing or the move they think to salvage this draw with.

This is a violation of the FIDE rules, which specify you have to write down the move and stop the clock before making the draw claim. As a result, when the GUI is running with claim verification on, such claims will be judged as false claims, and result in forfeiting the game.

It is therefore recommended that you send the move to the GUI in the normal way, so it can witrite it on the game sheet (=PGN file), before sending the draw claim.

For people that want to be 'more roman-catholic than the pope', and think this case must be handled differently because in OTB play the FIDE rules specify you should not make the move before making the claim: you have no case, as sending the move to the GUI is not making it. The GUI makes the moves for you. Nevertheless, if you insist on being difficult, you might not forfeit the game if you specify the intended move in the reason (the field between braces that follows the 1/2-1/2 command, like 1/2-1/2 { 3-fold repetition after Kg8 }.

[bob]

It seems that several strong engines do violate FIDE rules and WinBoard protocol by claiming repetition or 50-move draws without announcing or the move they think to salvage this draw with.

This is a violation of the FIDE rules, which specify you have to write down the move and stop the clock before making the draw claim. As a result, when the GUI is running with claim verification on, such claims will be judged as false claims, and result in forfeiting the game.

It is therefore recommended that you send the move to the GUI in the normal way, so it can witrite it on the game sheet (=PGN file), before sending the draw claim.

For people that want to be 'more roman-catholic than the pope', and think this case must be handled differently because in OTB play the FIDE rules specify you should not make the move before making the claim: you have no case, as sending the move to the GUI is not making it. The GUI makes the moves for you. Nevertheless, if you insist on being difficult, you might not forfeit the game if you specify the intended move in the reason (the field between braces that follows the 1/2-1/2 command, like 1/2-1/2 { 3-fold repetition after Kg8 }.

that violates too many rules to count. Once you send the move, your opponent should consider that to be the move you wanted to play, and it is now his move and you can not offer a draw while you are not on move. This has been discussed many times. The point you are making just highlights the differences in playing online or through a referee program and playing live chess. There is no way to "write the move down, claim the draw, and call the arbiter over. ICC has a mechanism to both provide the move and offer a draw in the same "atomic" operation. But sending the move first is _not_ going to work as it violates too many protocols...

[pedrox]

You have to write (send) the move when it is going to produce the third repetition or when it will produce 50 moves without capture or without move of pawn, then you can claim a draw.

But when one of the 2 above situations has already occurred, then there is no need to write (send) move and you can claim the draw directly into your turn.

[Tony]

It seems that several strong engines do violate FIDE rules and WinBoard protocol by claiming repetition or 50-move draws without announcing or the move they think to salvage this draw with.

This is a violation of the FIDE rules, which specify you have to write down the move and stop the clock before making the draw claim. As a result, when the GUI is running with claim verification on, such claims will be judged as false claims, and result in forfeiting the game.

It is therefore recommended that you send the move to the GUI in the normal way, so it can witrite it on the game sheet (=PGN file), before sending the draw claim.

For people that want to be 'more roman-catholic than the pope', and think this case must be handled differently because in OTB play the FIDE rules specify you should not make the move before making the claim: you have no case, as sending the move to the GUI is not making it. The GUI makes the moves for you. Nevertheless, if you insist on being difficult, you might not forfeit the game if you specify the intended move in the reason (the field between braces that follows the 1/2-1/2 command, like 1/2-1/2 { 3-fold repetition after Kg8 }.

I think Bob Hyatt already had some problems with this.

He had to send the move and the drawclaime in one line, because (in fast games) else you run the risk that the opponent moved in the time between them.

Tony

[hgm]

There is no way to "write the move down, claim the draw, and call the arbiter over.

Not true.

WB protocol does define the result command as the atomic

RESULT { reason }

so you can give the move and

But sending the move first is _not_ going to work as it violates too many protocols...

Well, a quick count showed that this is what the vast majority of WinBoard engines does. I am NOT going to make life difficult for those engines, by from now on forfeiting every draw claim they make. If an engine makes a draw claim while the drawn position is on the board, WinBoard will accept it. If they are too late, and the opponent already moved into a non-drawn position, they will forfeit. This is the risk they take by not using the mechanism I give above.

But it can and will not be tolerated that an engine claims a draw without telling how. Just as it is not be tolerated that an engine claims mate without doing the mateing move, or claims mate-in-10 and exits.

[Uri Blass]

It seems that several strong engines do violate FIDE rules and WinBoard protocol by claiming repetition or 50-move draws without announcing or the move they think to salvage this draw with.

This is a violation of the FIDE rules, which specify you have to write down the move and stop the clock before making the draw claim. As a result, when the GUI is running with claim verification on, such claims will be judged as false claims, and result in forfeiting the game.

It is therefore recommended that you send the move to the GUI in the normal way, so it can witrite it on the game sheet (=PGN file), before sending the draw claim.

For people that want to be 'more roman-catholic than the pope', and think this case must be handled differently because in OTB play the FIDE rules specify you should not make the move before making the claim: you have no case, as sending the move to the GUI is not making it. The GUI makes the moves for you. Nevertheless, if you insist on being difficult, you might not forfeit the game if you specify the intended move in the reason (the field between braces that follows the 1/2-1/2 command, like 1/2-1/2 { 3-fold repetition after Kg8 }.

I think Bob Hyatt already had some problems with this.

He had to send the move and the drawclaime in one line, because (in fast games) else you run the risk that the opponent moved in the time between them.

Tony

How fast can the opponent move?
I assume that the opponent is not going to move faster than the time that it takes me to calculate the result and write another line.

Calculating the result takes less than 1/100000 second.
I do not believe that the opponent can print a response faster than it
and I believe that the time that it takes the opponent to get the move from the interface is longer than 1/100000 second.

Uri

[hgm]

I guess this is why most people don't worry. It is conceivable, though, that on a machine with a single core the OS might decide to end the time slice of the engine as soon as it writes the first message to the pipe, because the GUI was waiting for a read from this pipe, and is running at a higher priority. Then the GUI input thread would have the CPU, process the move and send it to the opponent, before going to sleap on the read of the pipe again. (Since the engine did not get any CPU time for writing the draw claim). It is up to the scheduler to decide which engine then gets the next CPU time slice, and if it was the opponent, and he moves immediately, (i.e. within that same time slice), you would be in deep shit.

[Uri Blass]

I guess this is why most people don't worry. It is conceivable, though, that on a machine with a single core the OS might decide to end the time slice of the engine as soon as it writes the first message to the pipe, because the GUI was waiting for a read from this pipe, and is running at a higher priority. Then the GUI input thread would have the CPU, process the move and send it to the opponent, before going to sleap on the read of the pipe again. (Since the engine did not get any CPU time for writing the draw claim). It is up to the scheduler to decide which engine then gets the next CPU time slice, and if it was the opponent, and he moves immediately, (i.e. within that same time slice), you would be in deep shit.

Fortunately it is no problem with most engines because most engines simply do not make a move but claim a draw if there is a draw by repetition or by the 50 move rule.

Uri

[hgm]

This is exactly what is going to change in the future, and why I am bringing this up now:

Previous versions of WinBoard accept just any claim, whenever it is made. If an engine plays Rybka with black, and Rybka plays 1. d4, they can simply send '0-1 { black mates }' and they will go into the tournament result and PGN file as having beaten Rybka.

But, starting with WinBoard_F, future GUIs will verify such claims, and forfeit the game for an engine that makes false claims. The engines acting in the way you will describe will thus likely forfeit games, where their false claims were uncritically accepted before.

To prevent that, be sure to claim your draws in a proper way, e.g.

1/2-1/2 { 3-fold repetition after Kg8 }

The 'after MOVE' part occurring somewhere in the COMMENT field (i.e. between the braces {} ) will from now on be essential for not forfeiting the game (if the current position is not already a 3-fold repeat), where MOVE will have to use the same syntax as would be allowed in the 'move MOVE' command.

[Tony]

It seems that several strong engines do violate FIDE rules and WinBoard protocol by claiming repetition or 50-move draws without announcing or the move they think to salvage this draw with.

This is a violation of the FIDE rules, which specify you have to write down the move and stop the clock before making the draw claim. As a result, when the GUI is running with claim verification on, such claims will be judged as false claims, and result in forfeiting the game.

It is therefore recommended that you send the move to the GUI in the normal way, so it can witrite it on the game sheet (=PGN file), before sending the draw claim.

For people that want to be 'more roman-catholic than the pope', and think this case must be handled differently because in OTB play the FIDE rules specify you should not make the move before making the claim: you have no case, as sending the move to the GUI is not making it. The GUI makes the moves for you. Nevertheless, if you insist on being difficult, you might not forfeit the game if you specify the intended move in the reason (the field between braces that follows the 1/2-1/2 command, like 1/2-1/2 { 3-fold repetition after Kg8 }.

I think Bob Hyatt already had some problems with this.

He had to send the move and the drawclaime in one line, because (in fast games) else you run the risk that the opponent moved in the time between them.

Tony

How fast can the opponent move?
I assume that the opponent is not going to move faster than the time that it takes me to calculate the result and write another line.

Calculating the result takes less than 1/100000 second.
I do not believe that the opponent can print a response faster than it
and I believe that the time that it takes the opponent to get the move from the interface is longer than 1/100000 second.

Uri

Irrelevant.

It's about how fast the interface handles the engines output. Not how fast the engine can give it.

The 2 engines will be on 2 different threads so chances for collisions are a lot bigger than your calculation.

Tony