Strange problem with Crafty 23.0

[michiguel]

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.

Long time ago, the penalty was to charge you with the amount of time that took for the arbiter to figure out if the claim was valid. Later, it was changed to charge you with a flat 5 minute penalty and the game continued. I do not know today, since I haven't played for a handful of years. A wrong claim never loses a game (unless you lose on time as a consequence of the penalty).

Miguel

[michiguel]

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.

Exactly.

Miguel

[bob]

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.

Here's a suggestion:

Let's get HGM into this discussion, and anyone else interested, and let's fix this once and for all. I still like the idea of extending the current:

protocol version 2:
move Rh7+

to

protocol version 3:
move Rh7+ draw

The GUI can interpret that in two ways.

(1) if, after the move Rh7+, the rules of chess allow this game to be terminated as a draw, then the GUI does so instantly and the game ends.

(2) if, after the move Rh7+, the rules of chess do not allow this game to be terminated as a draw due to rule, then the GUI forwards this as a draw offer to the opponent which he can accept or decline as he sees fit.

There is more to it, in that it would be nice to have well-defined rules for offering a draw / claiming a draw, as well as accepting a draw or declining same. I'm not hung up on any particular implementation, as I should be able to deal with anything we all agree to. And finally closing this loophole would certainly be a good thing.

[bob]

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.

the penalty is that (a) the game continues, and (b) the arbiter can penalize the invalid claim by adjusting the clock. Penalizing the invalid claim by removing clock time is not very common, since it doesn't hurt the opponent because both clocks are stopped. If one repeats this behaviour, the arbiter can declare him the loser.

[bob]

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.

Another interesting idea would be to add the "hit clock" to the protocol. Then, until the program sends "hit clock" the opponent is not told anything at all, and now the GUI can see both the draw command and the move that supposedly produces the draw, without any fear of the opponent slipping in a move since he can't move until the other side "hits the clock button".

This extra message is a bit messy for fast games, but it would be most like real chess. The GUI temporarily has both clocks stopped while evaluating the draw claim, then starts the opponent's clock after shipping the move over.

[michiguel]

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.

Here's a suggestion:

Let's get HGM into this discussion, and anyone else interested, and let's fix this once and for all. I still like the idea of extending the current:

protocol version 2:
move Rh7+

to

protocol version 3:
move Rh7+ draw

The GUI can interpret that in two ways.

(1) if, after the move Rh7+, the rules of chess allow this game to be terminated as a draw, then the GUI does so instantly and the game ends.

(2) if, after the move Rh7+, the rules of chess do not allow this game to be terminated as a draw due to rule, then the GUI forwards this as a draw offer to the opponent which he can accept or decline as he sees fit.

There is more to it, in that it would be nice to have well-defined rules for offering a draw / claiming a draw, as well as accepting a draw or declining same. I'm not hung up on any particular implementation, as I should be able to deal with anything we all agree to. And finally closing this loophole would certainly be a good thing.

I agree the protocol should be upgraded in this respect. It is badly needed

I suggest

claimdraw Rh7+
(aftewards, your points 1 and 2 follow in the same way)

to have only one new clean command rather than building on an existing one; but anything on this direction will be fine. HGM is more aware of all the backward compatibility implications and the details.

This can be activated by a feature command, so the engine will know whether the GUI knows about this or not.

Miguel

[bob]

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.

Long time ago, the penalty was to charge you with the amount of time that took for the arbiter to figure out if the claim was valid. Later, it was changed to charge you with a flat 5 minute penalty and the game continued. I do not know today, since I haven't played for a handful of years. A wrong claim never loses a game (unless you lose on time as a consequence of the penalty).

Miguel

I had thought there was even a provision for that. Something to the effect that if the time penalty would cause your flag to fall, the arbiter can instead add time to the opponent's clock.

[Matthias Gemuh]

Here's a suggestion:

Let's get HGM into this discussion, and anyone else interested, and let's fix this once and for all. I still like the idea of extending the current:

protocol version 2:
move Rh7+

to

protocol version 3:
move Rh7+ draw

The GUI can interpret that in two ways.

(1) if, after the move Rh7+, the rules of chess allow this game to be terminated as a draw, then the GUI does so instantly and the game ends.

(2) if, after the move Rh7+, the rules of chess do not allow this game to be terminated as a draw due to rule, then the GUI forwards this as a draw offer to the opponent which he can accept or decline as he sees fit.

There is more to it, in that it would be nice to have well-defined rules for offering a draw / claiming a draw, as well as accepting a draw or declining same. I'm not hung up on any particular implementation, as I should be able to deal with anything we all agree to. And finally closing this loophole would certainly be a good thing.

That all sounds OK for me.

Matthias.

[Matthias Gemuh]

Another interesting idea would be to add the "hit clock" to the protocol. Then, until the program sends "hit clock" the opponent is not told anything at all, and now the GUI can see both the draw command and the move that supposedly produces the draw, without any fear of the opponent slipping in a move since he can't move until the other side "hits the clock button".

This extra message is a bit messy for fast games, but it would be most like real chess. The GUI temporarily has both clocks stopped while evaluating the draw claim, then starts the opponent's clock after shipping the move over.

Good idea, easy to implement.

Matthias.

[hgm]

I agree the protocol should be upgraded in this respect. It is badly needed

This problem was solved long ago. The command specified in the protocol for claiming a draw that only can be claimed after your move is offer draw. This both works in ICS and local mode.

Crafty is simply non-compliant, using a command (1/2-1/2) at a time where the protocol does not allow it and prescribes a different one.

There is no need to extend the protocol; the current protocol handles everything perfectly. Provided engines stick to it, of course. When they violate protocol, anything could happen. This is a general and unavoidable trait of protocols. More explanation in the other thread.