hgm wrote:I considered the method Bob proposes unacceptable, because it requires you to wait for a move after a (false) claim, which might not be coming. And this is totally unnecessary: you could reverse the order, always make the claim after the move, and then test the validity of the claim both in the current position and the previous one, if the last move was the opponent's.Matthias Gemuh wrote:OK, I admit that your proposal works for future engines.bob wrote:
It doesn't really leave them hanging. They are _already_ hanging if they send the claim after the move. I gave a simple example. If they are given a simple guideline "Any claims you want to make during your turn to move, must be sent prior to sending your move. Once you send your move, it will be relayed to the opponent, and any claim made after that may well not be dealt with until after your opponent moves. As a result, the standard behavior for handling your claims for a draw, etc will be as follows: When your claim is received, it will be immediately checked against the current game state. If the claim is valid, the game will end with the appropriate result. If the claim is not valid with the current state, it will be held until you send a move. After the move is made, before it is relayed to your opponent, your claim will again be evaluated to see if it is applicable after your move. If so, the game will immediately end, as it did for the previous case. If the claim is not valid either before or after your move, the claim will be ignored and the game will continue."
That will work. I don't think it is optimal, but it works with no loopholes. What this is doing is to treat the claim / move as if it were either claim - move, or move-claim, depending on which works. I'd rather the protocol be more explicit, but there seems to be little interest in fixing something that is definitely broken. Fixing this would also let a program comply with the official FIDE rules of chess and offer/claim things at the correct time and in a way that an arbiter would be satisfied that the rules have been met. At present, the interface is not doing that.
It works for the existing engines only if GUI terminates 3-fold-rep/50-move games on first occurence (as ChessGUI does).
To fix the future and stay compatible with the past, the "claim before move" sequence would have to be activated by a "feature".
When activated for both engines, 3-fold-rep/50-move games can run till a claim come in.
When activated for only one or no engine, GUI should terminate 3-fold-rep/50-move games on first occurence.
For humans, the feature would be activated.
Matthias.
Note that I don't want to drop the RESULT command from the protocol, is just for the reason Wylie states: the protocol is also intended to work for variants that the GUI does not fully understands (3checks, bughouse, ...).
A second reason is that I want to have a protocol with a command that allows the engine to say: "I now walk out on this game". Unlike what Bob says, it is in perfect agreement with FIDE rules to forfeit a player that leaves the tournament premises. It is not just a matter of ving him lose on time, eventually: even if he returs before that, he still has forfeited.
When have you ever seen that happen? I've played in dozens of human tournaments over the years. Players come and go all through a game. Even in the DB Kasparov match, Kasparov had a private area away from the board where he could go when he wanted. If you don't show at the start of a round, some events have a rule that will end the game after some period of time that is far shorter than the first time control. But you can walk away and you don't lose until your flag falls in any event I have ever played in or watched.
I'll say it one more time. The "result" command should not end the game. To see why, play Arasan 9 some matches and make sure the opponent does not get to send any results. Then check the games. Arasan gets confused when playing black and when it decides to resign, it will send 0-1. Which claims it won. Took me several thousand games to notice this when I first used it in cluster testing. If the GUI knows when the game is drawn, or recognizes checkmate/stalemate, it ought to be the entity that decides the proper outcome. You can always accept resign, as there is no ambiguity there and there is no way to produce the wrong game result either. But a good gui ought to be able to deal with the rest of this stuff itself. I know mine does on the cluster. No engine can end a game by itself unless it resigns or runs out of time.
In summary:
1) engines should use 1/2-1/2 to claim draws in positions where you have the move
2) engines should use offer draw before your move to claim draws that only materialize after your move
3) A GUI should, on detecting a draw condition in the current position, certainly terminate the game as draw if there are any pending draw offers.
4) Without pending offers, it should obey the user adjudication instructions, which might be to declare draw, or play on until an engine claims, or play on somwhat longer (e.g. to a 4th repetirion or a 51st move).
5) To prevent the race condition in local play with engines that do not use the safe claiming mechanism, judge RESULT claims of the stm both in the current position and in the one before it.
I'd like to see something that works for everybody. Such as a protocol version 3 that addresses the particular issues with offering/claiming draws. Rather than having everyone trying to design kludges that may or may not work, and which are certainly neither intuitive nor logical. Certainly "offer draw before making a move" is not an intuitive equivalent to "I claim a draw after move xxx".
