Strange problem with Crafty 23.0

[bob]

Sorry I missed half the sentence out!

When BLACK is winning and it is BLACK'S turn to move Crafty shows the score as winning for white.

All other evals ok.

There should be a box to check to fix this. If black is winning, it will show negative scores, which a gui will translate to good for white, which is wrong.

[Graham Banks]

I'm impressed with Crafty 23.0. It's doing well in my testing so far (still early days though).

One thing I've noticed is that instead of accepting a draw by repetition, it resigns. This is under ChessGUI running it as a Winboard engine.
Matthias - I guess I need to check the box that says draws accepted/refused?

Cheers, Graham.

Crafty is resigning rather than going for a repetition? Can you send me a log file from when that happens? I've not seen that ever. Might be some sort of missed communication between Crafty and the GUI and the GUI is doing the resignation for unknown reasons...

Hi Bob,

I can send you a copy of the ChessGUI debug file that I sent Matthias if you wish, but I think that Matthias has explained what happened. Unfortunately I have Crafty log switched off.

Cheers, Graham.

[bob]

I'm impressed with Crafty 23.0. It's doing well in my testing so far (still early days though).

One thing I've noticed is that instead of accepting a draw by repetition, it resigns. This is under ChessGUI running it as a Winboard engine.
Matthias - I guess I need to check the box that says draws accepted/refused?

Cheers, Graham.

Crafty is resigning rather than going for a repetition? Can you send me a log file from when that happens? I've not seen that ever. Might be some sort of missed communication between Crafty and the GUI and the GUI is doing the resignation for unknown reasons...

Hi Bob,

I can send you a copy of the ChessGUI debug file that I sent Matthias if you wish, but I think that Matthias has explained what happened. Unfortunately I have Crafty log switched off.

Cheers, Graham.

I followed the discussion and see the problem. This was discussed about 10 years ago and Darooha (Sleator) on ICC got the problem fixed. Here's the issue:

I currently have to send a move, and claim a draw by sending "draw" to ICC. The problem is, in what order?

If I send the move first, and then the draw claim, the server gets the move, sends it to my opponent, which may well respond with a move before my draw claim makes it across the network. Once my opponent moves, I can no longer claim a draw if he does something to break the 50 move counter or repetition.

The solution is to send the draw claim first. The server sees it as a "draw offer" which can be made at any time. Then I send the move. Now the server notices that this is a draw by either repetition or 50 move rule and since I have a draw offer pending, the server converts this into a draw claim and instantly ends the game.

This is also according to the FIDE rules of chess. You have to first claim the draw, and then show the move you believe causes the draw. The gui being used has a timing hole that matches the above race condition. Rejecting the draw claim is wrong, but is understandable. The best solution would be a way to send a move and draw claim together, such as "move Rh7 draw". or "I claim a draw after move Rh7" or something similar.

I think it silly for a gui to claim the game is lost when a draw claim is sent, but that's apparently what it does. Particularly when the rules of chess say the claim has to be made _prior_ to the move being made...

Most programs do it wrong. In my cluster testing, my referee just ignores draw claims and handles draws itself, recognizing repetitions and 50 move draws without program help.

[Matthias Gemuh]

I followed the discussion and see the problem. This was discussed about 10 years ago and Darooha (Sleator) on ICC got the problem fixed. Here's the issue:

I currently have to send a move, and claim a draw by sending "draw" to ICC. The problem is, in what order?

If I send the move first, and then the draw claim, the server gets the move, sends it to my opponent, which may well respond with a move before my draw claim makes it across the network. Once my opponent moves, I can no longer claim a draw if he does something to break the 50 move counter or repetition.

The solution is to send the draw claim first. The server sees it as a "draw offer" which can be made at any time. Then I send the move. Now the server notices that this is a draw by either repetition or 50 move rule and since I have a draw offer pending, the server converts this into a draw claim and instantly ends the game.

This is also according to the FIDE rules of chess. You have to first claim the draw, and then show the move you believe causes the draw. The gui being used has a timing hole that matches the above race condition. Rejecting the draw claim is wrong, but is understandable. The best solution would be a way to send a move and draw claim together, such as "move Rh7 draw". or "I claim a draw after move Rh7" or something similar.

I think it silly for a gui to claim the game is lost when a draw claim is sent, but that's apparently what it does. Particularly when the rules of chess say the claim has to be made _prior_ to the move being made...

Most programs do it wrong. In my cluster testing, my referee just ignores draw claims and handles draws itself, recognizing repetitions and 50 move draws without program help.

I think the solution is easy.
Crafty is aware whether it is playing online or not.
When online, it should send claim before move.
When offline, it should send move before claim.

As I said, in my offline tournaments involving almost all WB engines, hardly an engine sends a claim without having sent the move.
My wild guess is that they swap the order when online.

Matthias.

[Matthias Gemuh]

I think it silly for a gui to claim the game is lost when a draw claim is sent, but that's apparently what it does. Particularly when the rules of chess say the claim has to be made _prior_ to the move being made...

Most programs do it wrong. In my cluster testing, my referee just ignores draw claims and handles draws itself, recognizing repetitions and 50 move draws without program help.

It is common to ignore "the rules of chess say the claim has to be made _prior_ to the move being made" in computer chess because that rule screws things up in computer chess.
There is a rule that a human can claim a 3-fold-rep by telling the referee his move, without playing it. Only then is the claim valid. In computer chess, that translates to "send the move to GUI before claiming."

Code: Select all

In my cluster testing, my referee just ignores draw claims and handles draws itself ...

I thought of ignoring also in ChessGUI and will probably start doing so soon. I cannot remember why I refrained. However, engines should preferably still send move before claim when offline.

Matthias.

[Matthias Gemuh]

Here is my final decision:

ChessGUI will ignore all draw claims from engines and wait for their moves only. In the worst case, the user will just have to wait till engine loses on time, if it claimed but never sent a move.

With this change, Crafty should work fine (at least under ChessGUI) unchanged.

Matthias.

[Matthias Gemuh]

Here is my final decision:

ChessGUI will ignore all draw claims from engines and wait for their moves only. In the worst case, the user will just have to wait till engine loses on time, if it claimed but never sent a move.

With this change, Crafty should work fine (at least under ChessGUI) unchanged.

Matthias.

I know that someone may pop up from somewhere and shout that ignoring draw claims breaks the WB protocol, but logic commands: "break it !".

Here is the new ChessGUI that ignores draw claims.

http://www.hugedrive.com/published/WG/s ... =-d5c6b403

(available for about one day)

Matthias.

[Matthias Gemuh]

I know that someone may pop up from somewhere and shout that ignoring draw claims breaks the WB protocol, but logic commands: "break it !".

Here is the new ChessGUI that ignores draw claims.

http://www.hugedrive.com/published/WG/s ... =-d5c6b403

(available for about one day)

Matthias.

I change my mind and made a full ChessGUI update
- draw claims are now ignored
- collecting of GM moves refined

Matthias.

[bob]

I followed the discussion and see the problem. This was discussed about 10 years ago and Darooha (Sleator) on ICC got the problem fixed. Here's the issue:

I currently have to send a move, and claim a draw by sending "draw" to ICC. The problem is, in what order?

If I send the move first, and then the draw claim, the server gets the move, sends it to my opponent, which may well respond with a move before my draw claim makes it across the network. Once my opponent moves, I can no longer claim a draw if he does something to break the 50 move counter or repetition.

The solution is to send the draw claim first. The server sees it as a "draw offer" which can be made at any time. Then I send the move. Now the server notices that this is a draw by either repetition or 50 move rule and since I have a draw offer pending, the server converts this into a draw claim and instantly ends the game.

This is also according to the FIDE rules of chess. You have to first claim the draw, and then show the move you believe causes the draw. The gui being used has a timing hole that matches the above race condition. Rejecting the draw claim is wrong, but is understandable. The best solution would be a way to send a move and draw claim together, such as "move Rh7 draw". or "I claim a draw after move Rh7" or something similar.

I think it silly for a gui to claim the game is lost when a draw claim is sent, but that's apparently what it does. Particularly when the rules of chess say the claim has to be made _prior_ to the move being made...

Most programs do it wrong. In my cluster testing, my referee just ignores draw claims and handles draws itself, recognizing repetitions and 50 move draws without program help.

I think the solution is easy.
Crafty is aware whether it is playing online or not.
When online, it should send claim before move.
When offline, it should send move before claim.

As I said, in my offline tournaments involving almost all WB engines, hardly an engine sends a claim without having sent the move.
My wild guess is that they swap the order when online.

Matthias.

You are missing the _point_

If I send the move first, and then the claim, you will receive the move first, and you can easily send it to my opponent, and it can respond with a move before you see my draw claim, which is now invalid since my opponent has moved.

Additionally I do not know whether I am online or not. Xboard doesn't tell me that, it just starts a game and starts sending information.

But that is all moot. There is a race condition that can't be solved, and the ICC solution is something that works, where sending the move first will not. The proper solution is that when you see the "draw" claim/offer, prior to the move, and you verify that the current position is not a repetition/50-move draw, you send it to the opponent as an offer. Then when you get the move, you notice it is now a real draw, and with a draw offer pending, you call the game over at that point. There is still a race condition, but this one is harmless, because if you send the draw offer to the opponent he can accept the draw before I send the move. But the game still ends as a draw.

Given the choice of making an invalid decision or not, the latter is the correct way to handle this. And since it agrees with the FIDE rules, it works as inteended. How do you handle this when a human is playing, where the race condition will become impossible to deal with since the human will have a lignificant gap between making the move and claiming the draw, not to mention the fact that he will be doing so contrary to the normal tournament rules.

[bob]

I think it silly for a gui to claim the game is lost when a draw claim is sent, but that's apparently what it does. Particularly when the rules of chess say the claim has to be made _prior_ to the move being made...

Most programs do it wrong. In my cluster testing, my referee just ignores draw claims and handles draws itself, recognizing repetitions and 50 move draws without program help.

It is common to ignore "the rules of chess say the claim has to be made _prior_ to the move being made" in computer chess because that rule screws things up in computer chess.

It only screws things up when the GUI does it _wrong_.

There is a rule that a human can claim a 3-fold-rep by telling the referee his move, without playing it.

You are not quite interpreting the rule correctly. The human does not keep the move a secret. He tells the arbiter what he will play to cause the draw. Guess who the arbiter is in this case??? But the GUI has to actually act like an arbiter.

Only then is the claim valid. In computer chess, that translates to "send the move to GUI before claiming."

There is little else I can say. If you don't see the obvious race condition you have, then you are not going to try to fix the problem. It is there, it will screw up game results no matter what you do, unless you fix it. An engine is going to make a perfectly valid draw claim that you are going to be forced to ignore because of the race condition, or an engine is going to lose a perfectly drawn position because you haven't seen and fixed the race condition that exists.

ICC does it right. Any referee program can do so if desired. But ignoring the problem and saying the program is doing this wrong is not the way to go here.

Code: Select all

In my cluster testing, my referee just ignores draw claims and handles draws itself ...

I thought of ignoring also in ChessGUI and will probably start doing so soon. I cannot remember why I refrained. However, engines should preferably still send move before claim when offline.

Matthias.

You keep saying that, but there is a hole in that logic that will produce wrong results.