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

[Uri Blass]

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.

I see that there was a misunderstanding.
When I said that most engines simply do not make a move I meant to
situations when the opponent forced the repetition.

In your example I meant that if black plays Kg8 and force repetition there is no chance that white is going to reply with a move and not with a draw claim so even if white is faster than black then white still draw the game.

I think that the simplest solution is that no engine try to make a move after draw by repetition or draw by the fifty move rule.

Even if there is a winning move the engine can assume that the opponent is smart enough to claim a draw by itself and having code to care for the case that the opponent is stupid seems to me waste of time(it can only be productive in games against humans or buggy engines and humans lose against engines so I see no reason to care about computer-human games).

Uri

[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

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

If the interface accept the move after repetition of one player inspite of a draw claim by the second player that came immediately after the move then I think that the bug is in the interface.

The interface should check that there is no draw claim before it decides to continue the game in case that a draw claim is legal.

Waiting 0.01 seconds before sending a move to the second engine when draw claim is legal is enough for that purpose and is not going to make games significantly slower even if you play games in 1 second.

Uri

[hgm]

In your example I meant that if black plays Kg8 and force repetition there is no chance that white is going to reply with a move and not with a draw claim so even if white is faster than black then white still draw the game.

I think that the simplest solution is that no engine try to make a move after draw by repetition or draw by the fifty move rule.

Even if there is a winning move the engine can assume that the opponent is smart enough to claim a draw by itself ...

There might be situations where neither engine is happy with a draw (depending on contempt-factor settings), and according to FIDE rules a draw is not mandatory.

Some tounament rules (e.g. WBEC) do make claiming a draw if your own move hits a 3-fold rep or the 50-move barier madatory, though. Engines that do not do that are not even allowed to participate.

But other tournaments might have other rules, and there is nothing against claiming a draw before making the move that leads to it. As long as you mention the move in the comment. I cannot think of any excuse for not mentioning the move there. You can write anything in the comment without violating existing WinBoard protocol. And not mentioning a move in some way is a violation of FIDE rules.

[Aleks Peshkov]

IMHO online chess and advanced chess rules should be a bit different from current FIDE laws. Last edition of rules created before computer epoch and was designed to protect human players from human errors and unsportsmanship psychological pressure.

For example bridge game rules are significantly different in various tournament conditions (open table, tables with shield, online bridge).

[Uri Blass]

There might be situations where neither engine is happy with a draw (depending on contempt-factor settings), and according to FIDE rules a draw is not mandatory.

This is correct and I still think that the simplest solution is not to care about these rare cases and have a practical rule in comp-comp games that the game is drawn if it is possible to claim a draw(otherwise games with increasement may last forever when both sides do not claim a draw in a drawn position).

Practically it is enough if one engine claims a draw when it is legal to get a draw by claiming a draw by the fide rules.
After thinking about it again it may be even better if the interface has an option to claim a draw and stop the game after a draw by the 50 move rule or 3 time repetition.

Uri

[hgm]

After thinking about it again it may be even better if the interface has an option to claim a draw and stop the game after a draw by the 50 move rule or 3 time repetition.

This is exactly what WinBoard_F does. The user can select after how many moves or how many repetitions he wants to adjudicate the games as draw.

But the opposite problem, of engines claiming draws when there is no draw in sight, unfortunately also occurs, and has to be acted against in order to discipline rogue engines. The main problem is that some respectable engines now side with the rogue engines, by solving a legitimate problem in an intollerable way.

[bob]

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.

I do not follow your point about the "result" keyword. It does not have to come before or after a move. And it certainly isn't attached to a move. To properly claim a draw in real chess you write down your move but do not make it, you stop both clocks, and inform the TD. There is no such mechanism for online play or automated play using the winboard match option. Sending the "result" keyword in winboard ends the game instantly, correct or not. I can show you a bunch of games where Arasan 9 had a bug and would send the wrong result when resigning, and winboard was giving it the victory instead of a loss.

ICC has addressed this by allowing you to first offer a draw, then making a move. The server will then notice (say) a 3-fold repetition or 50-move draw and enforce it so long as the move is entered after the draw command.

Personally, the programs ought to be able to handle this correctly, given the limitations of the protocols being used. But there are some timing issues that have shown up. If the server does it correctly (and ICC does) then there is no problem. But then the server could give a squat about the program claiming a win, as the server serves as arbiter and would make that determination without any input from either opponent, as it should. Winboard and the UCI interfaces are a little messier in this detail...\

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

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

Your math is lousy. You send a move. Then you claim a draw. That turns into two network packets. The first packet arrives at the server. I have a much better connection than you do. I get your move, I send a respons, and your draw claim has still not arrived at the server. The move I make therefore bypasses your draw claim because you can't claim a draw after I have moved if the position is not yet another repetition or 50-move draw after my move...

The timing issues are serious. ICC tries to now handle this better. I had some discussions with fishbait and darooha about this a few years back, and they modified how the server handles draw claims. The idea is that if I send a move, and a draw claim, even if you move before my draw claim arrives, if the claim was valid after my move (and before yours was made) then the draw is enforced...

[bob]

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

How can you do that? What if _your_ move causes the third repetition. You _must_ play the move. But the rules of chess say you don't have to claim the draw (although in a zero-sum game, presumably your opponent would then claim the repetition before he makes a move, which is also allowed...

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

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

If you assume ponder=on, so that both programs are computing all the time, the typical time-slice (quantum) is around 400ms. That means each process runs for 400ms, then gets preempted so that the other engine can run. That allows plenty of timing variability to make this a problem. Over a network it is magnified due to network delays...