Strange problem with Crafty 23.0

[bob]

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 do not follow. 3-fold repetition is not a _forced_ draw. Nor is a 50-move rule draw. If I repeat a position where the same side is on move and the same OTB position has occurred 3 times after my move, I can claim the draw, or I can choose to play on and see if my opponent wants to play on. You are implying that a 3-fold repetition is an instant draw, which it is not. Ditto for 50 move rule draws. The only instant draws are positions with KN vs K, K vs K and such. (insufficient material to mate your opponent).

[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 do not follow. 3-fold repetition is not a _forced_ draw. Nor is a 50-move rule draw. If I repeat a position where the same side is on move and the same OTB position has occurred 3 times after my move, I can claim the draw, or I can choose to play on and see if my opponent wants to play on. You are implying that a 3-fold repetition is an instant draw, which it is not. Ditto for 50 move rule draws. The only instant draws are positions with KN vs K, K vs K and such. (insufficient material to mate your opponent).

There is a point I have been taking for granted, though FIDE has a different view. I have been taking for granted that a 3-fold-rep or the 50-move rule end the game.
ChessGUI will continue to consider these the end of the game.
That is a blessing for all those engine testers out there.
I don't care much about FIDE in these 2 cases. FIDE made their rules for human events, totally ignoring computer chess.

I admit that ChessGUI may have to readjust when it shall be able to offer online play or when it shall have the option to strictly obey weird FIDE rules.

When the time comes for ChessGUI to let engines play beyond 3-fold-rep and 50-move rule, then I will consult H.G.Muller to agree on something about race conditions and backward compatibility with the hundreds of WB engines out there.

Matthias.

[michiguel]

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 do not follow. 3-fold repetition is not a _forced_ draw. Nor is a 50-move rule draw. If I repeat a position where the same side is on move and the same OTB position has occurred 3 times after my move, I can claim the draw, or I can choose to play on and see if my opponent wants to play on. You are implying that a 3-fold repetition is an instant draw, which it is not. Ditto for 50 move rule draws. The only instant draws are positions with KN vs K, K vs K and such. (insufficient material to mate your opponent).

There is a point I have been taking for granted, though FIDE has a different view. I have been taking for granted that a 3-fold-rep or the 50-move rule end the game.
ChessGUI will continue to consider these the end of the game.
That is a blessing for all those engine testers out there.
I don't care much about FIDE in these 2 cases. FIDE made their rules for human events, totally ignoring computer chess.

FIDE made the rules for chess (period). If computers do not follow FIDE rules, it will be "computer some game" rather than "computer chess".

This is a very common temptation among programmers. Rather than adapting to the world, they may choose to follow what they think is more convenient. The public ends up struggling to adapt to the "new system". We see that everyday in our life with many "automated systems" and I think it is wrong. If we allow the programmers get away with everything, we will end up with a chess version without the 50-move rule, castling, and en passant

Miguel

I admit that ChessGUI may have to readjust when it shall be able to offer online play or when it shall have the option to strictly obey weird FIDE rules.

When the time comes for ChessGUI to let engines play beyond 3-fold-rep and 50-move rule, then I will consult H.G.Muller to agree on something about race conditions and backward compatibility with the hundreds of WB engines out there.

Matthias.

[michiguel]

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.

This is also true for draw offers. The correct way to offer a draw is to offer it with your clock running, and immediately move.

Miguel

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]

If we allow the programmers get away with everything, we will end up with a chess version without the 50-move rule, castling, and en passant

Miguel

Those are the the next things I was about to throw out.

Matthias.

[Matthias Gemuh]

There is a point I have been taking for granted, though FIDE has a different view. I have been taking for granted that a 3-fold-rep or the 50-move rule end the game.
ChessGUI will continue to consider these the end of the game.
That is a blessing for all those engine testers out there.
I don't care much about FIDE in these 2 cases. FIDE made their rules for human events, totally ignoring computer chess.

FIDE made the rules for chess (period). If computers do not follow FIDE rules, it will be "computer some game" rather than "computer chess".

FIDE made the rules for chess (period) ?

Code: Select all

9.2 	

The game is drawn, upon a correct claim by the player having the move, when the same position, for at least the third time (not necessarily by a repetition of moves)

   1.  is about to appear, if he first writes his move on his scoresheet and declares to the arbiter his intention to make this move

The chess engine should first write his move on his scoresheet and declare to the arbiter his intention to make this move, period ?

Matthias.

[bob]

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.

Here's another case that your approach really breaks.

Let's take a position like this

[d]7k/8/8/1q6/6Q1/8/8/K7 w - - 0 1

Black has played his 50th move with no capture or pawn push. It is white's move and no matter what move he plays, the game can be claimed as a draw since he can't capture black's queen and can't checkmate black on the move which would not be a draw at all. So white plays the first move its move generator produces, which might well be Qg7+. Then he claims the draw. But before the GUI gets the draw claim, it gets the move Qg7+ and the opponent moves instantly since his only legal move is Kxg7. And now the position is not a draw at all and white loses.

Never happen, you say? This is not uncommon at all to see the last move in the 50 move case be a move no human would even consider, because in this position, any move draws, period. If the GUI understands how that works. After Qg7+ black could also legitimately claim a 50 move draw, but why would he since he can make a capture, reset the 50 move rule, and now easily win.

There are only two solutions to this.

(1) modify the protocol, so that one can claim the draw _and_ send the move at the same time, to avoid a race condition that is not there in human chess.

(2) have the gui behave as ICS does, and realize that the draw command by itself does two things... it offers a draw to the opponent if the OTB position is not a draw by the various normal reasons like 50-move, 3-fold repetition, or insufficient material or stalemate. It is still the program's move so the opponent can't do a thing other than to send back an accept of the draw offer which will instantly end the game. Now the program sends the move, and the GUI notes that there is a draw offer/claim pending, and after the move the OTB position meets the FIDE rules for a draw by 50-move rule, repetition, etc. and ends the game on the spot regardless of what the opponent might say.

Any other option leaves an ugly timing hole that will cause incorrect game results no matter which way the GUI tries to interpret the commands. This is a classic race condition. In parallel programming we would call this a critical section, and acquire a lock before sending the move and draw, where the order is now immaterial, then release the lock which would let the opponent then do whatever it wanted. But we need an "atomic" operation to claim a draw and send a move in one indivisible operation. Which means either the protocol must be modified to finally fix this once and for all, or else the GUIs have to have an "atomic interpretation" of two non-atomic operations.

Anything else is broken. And just because Crafty is only one of a couple of programs that current do this correctly, doesn't mean Crafty is doing something bad. It is doing it in the only way that it can work given the current protocol.

[bob]

There is a point I have been taking for granted, though FIDE has a different view. I have been taking for granted that a 3-fold-rep or the 50-move rule end the game.
ChessGUI will continue to consider these the end of the game.
That is a blessing for all those engine testers out there.
I don't care much about FIDE in these 2 cases. FIDE made their rules for human events, totally ignoring computer chess.

FIDE made the rules for chess (period). If computers do not follow FIDE rules, it will be "computer some game" rather than "computer chess".

FIDE made the rules for chess (period) ?

Code: Select all

9.2 	

The game is drawn, upon a correct claim by the player having the move, when the same position, for at least the third time (not necessarily by a repetition of moves)

   1.  is about to appear, if he first writes his move on his scoresheet and declares to the arbiter his intention to make this move

The chess engine should first write his move on his scoresheet and declare to the arbiter his intention to make this move, period ?

Matthias.

Correct. In a human event, if the rule is followed formally, I write my move down, tell my opponent I intend to claim a draw by whatever rule, and ask the arbiter to come over and check the claim. He can say "OK, this is a valid draw claim and the game is over" or he can say "this is not a draw, play your move and the game continues." The latter can happen when someone wrongly interprets the 3-fold repetition rule which some take to mean moving the same piece to the same square 3 times, which iis wrong. It can happen when my scoresheet has missing moves so that the 50-move counter can't be verified, or the 3 repeated positions can't be verified, etc.

So, I tell the arbiter I want to claim a draw and show him my move. Isn't that _exactly_ what Crafty does with the GUI? Says "I claim a draw" and "here is my move that causes the draw". The GUI can end the game if it agrees, otherwise we play on (although this can't really happen without a program bug, obviously). But certainly I do not _lose_ the game, which is a ridiculous interpretation of the draw claim rule.

[krazyken]

The critical difference between OTB chess and chess with a GUI, is that in OTB hitting the clock is an action separate from making the move. So OTB rules allow for things to happen between moving and hitting the clock. Xboard and UCI protocol (as well as ICS) do not have a hit the clock function, they consider the clock hit as soon as the move is submitted.
What is the penalty under FIDE for an invalid draw claim anyways?

If a player claims a draw as in Article 9.2 or 9.3, he shall immediately stop both clocks. He is not allowed to withdraw his claim.
If the claim is found to be correct the game is immediately drawn.
If the claim is found to be incorrect, the arbiter shall add three minutes to the opponent`s remaining time. Additionally, if the claimant has more than two minutes on his clock the arbiter shall deduct half of the claimant`s remaining time up to a maximum of three minutes. If the claimant has more than one minute, but less than two minutes, his remaining time shall be one minute. If the claimant has less than one minute, the arbiter shall make no adjustment to the claimant`s clock. Then the game shall continue and the intended move must be made.

[Matthias Gemuh]

There are only two solutions to this.

(1) modify the protocol, so that one can claim the draw _and_ send the move at the same time, to avoid a race condition that is not there in human chess.

(2) have the gui behave as ICS does, and realize that the draw command by itself does two things... it offers a draw to the opponent if the OTB position is not a draw by the various normal reasons like 50-move, 3-fold repetition, or insufficient material or stalemate. It is still the program's move so the opponent can't do a thing other than to send back an accept of the draw offer which will instantly end the game. Now the program sends the move, and the GUI notes that there is a draw offer/claim pending, and after the move the OTB position meets the FIDE rules for a draw by 50-move rule, repetition, etc. and ends the game on the spot regardless of what the opponent might say.

Now that (1) has not yet been agreed on, and (2) is almost same as what I am already doing, I will go for (2) and make the necessary adjustment.

Matthias.



Matthias.