In this particular case, ChessGUI is waiting for a move from Crafty.
Crafty then suddenly claims a draw by repetition, without having sent the drawing move. ChessGUI rejects the claim because it cannot prove that Crafty found the drawing move.
I think a human can draw by 3-fold-rep in a human game without playing the move, but he has to tell the TD which move it is.
In computer chess, the drawing move should be played before any claims.
BTW, I will change "resign" to something else.
OK, let's make sure we agree what problem is described here. I understand from this description that Crafty sends
1/2-1/2 ('claims a draw'). If it would have sent
offer draw there would
never be a reason for any GUI to forfeit it, because it is legal to send draw offers in any position. In the previous discussion there seemed to be some confusion about this. Perhaps the relevant part of the debug file can be posted here, to avoid any unnecessary misunderstandings?
bob wrote:
Two important points.
1. One can claim a draw without playing a move. The FIDE rules say that the side on move can claim a draw by repetition, if the same position has occurred three times in a row, with the same side on move. This means that if I reach a position with me to move, and the position has already occurred three time (including this one) I do not have to make a move. I can just claim the draw and the game ends when the TD/arbiter verifies this.
Agreed. I would say that any GUI that would ignore any
1/2-1/2 here sent by the engine and require the engine to go on (or forfeit it on time when it doesn't) is broken. Any GUI that would forfeit the engine immediately is even more broken. If the position occurred indeed for the 3rd time, that is. If it didn't... Well let me leave that for later.
2. One can claim a draw after playing a move. Crafty does this with the "1/2-1/2 {Draw by 3-fold repetition}" string it sends to xboard. It always sends this prior to making a move. Because we do not have a "end of my move" sentinel like a real game, where pressing the clock signifies you have done everything you intend to do. You have made a move. You have (or have not) offered a draw. Etc. In xboard games, you can't safely claim the draw _after_ the move, because of the previously mentioned race condition. So the claim of a draw for any reason has to go _before_ the move, unless the GUIs are all changed to realize that a claim _after_ the move might apply to the position after the mover, or it might apply to the position before the next move, and the GUI has to decide which.
Agreed. There is need for a command that allows you to claim a draw in advance, to solve the race condition. That command should translate to the correspondig ICS command in ICS mode. (I.e. it should trigger the sending of 'draw' to ICC.)
After the last lengthy discussion, I tried the "offer draw" trick that works on ICC, and had a couple of testers try this. They uniformly reported that it did not work for several GUIs making it problematic. I personally don't even like the wording "offer draw" because I am not offering a draw, I am trying to claim a draw.
Well, I don't like that wording either, but on the other hand, there is absolutely nothing to be gained by adding a new command
claim draw, to distinguish it from
offer draw. It would only create possibilities for errors, making it possible to claim in situations where it is only allowed to offer, and making it possible to offer in situations where it is silly to offer. One only offers a draw if one wants one, and if one wants one, and can claim it, one should claim it. So the protocol really needs a single command from the engine, saying "I want a draw". The GUI cn then grant it when it is claimable, and if not, the opponent can grant it. Well, this command now happens to be badly worded, as
offer draw. Well, it is just protocol, and who cares if it is "offer draw", "want draw", or "%&123=A"? It is certainly not the only command in the protocol that has obscure wording ("easy", "hard", ...).
Not that the FIDE rules stipulate that a draw claim is automaticly also a draw offer. So even if a separate command
claim draw existed, and it would be used by an engine in a position where claiming was not legal, the GUI would still have to treat is like it was
offer draw.
HGM is going to say that Crafty is doing it wrong. I claim that currently _most_ GUIs are doing it wrong. That was why I thought it useful to clear up the ambiguity that "offer draw" has. In a normal game, if I offer you a draw, you can just ignore it and keep playing. If I claim a draw, you can not continue until the TD/arbiter has ruled that this is not a drawn position. If it is a drawn position, the game ends with my claim.
As you already spoke for me,
what seems most important is to know exactly what most GUIs are doing wrong, then. In ICS play, it can only go wrong when the GUI does not relay the
offer draw to the ICS as a "draw" command. The ICS should have taken this as a draw claim, as the ICS protocol also does not have separate commands for claiming and offering a draw. (But, admittedly, uses better wording for it. As, unike WB protocol, the ICS protocol is meant for Human use, this is just as well.)
In local mode, I can imagine that som GUIs simply relay
offer draw immediately as a draw offer, and that the opponent refuses it (or that the Gui ignores the offer on behalf of the engine). Then you play the move. On a state-of-the-art GUI (like on an ICS) this should terminate the game. But, just to make sure, you could now send
1/2-1/2 to claim the draw. No GUI that did not interpret
offer draw as a claim should forfeit you on a false claim when you send a
1/2-1/2 command that was pe-empted. Old XBoards would grant you the draw no matter what, even if you had a bare King against 3 Queens. It seems to me tha GUIs that now still would not terminate the game as a draw are very badly broken.
Miguel suggested "offer draw" is fine for offering draws. And that "claim draw" would be more to the point of claiming a draw. And by using the syntax "claim draw <move>" you are saying "I play <move" and claim the resulting position is a draw (doesn't specify 3-fold, stalemate, 50-move, insufficient material, or anything else, just a draw that the GUI needs to figure out). It might be worthwhile to specify the "why" as well to further resolve ambiguities, such as "claim draw 3-fold <move>" or "claim draw 50-move <move>" or whatever.
I can only repeat myself: "What problem is the introduction of this command supposed to solve?". All the broken GUIs that are giving you trouble with the existing
offer draw will most certainly give you even more troule if you send them a command that we introduce, as it will not be implemented in them. If their programmers would be prepared to implement it, they might as well start implementing the
offer draw. One can never solve refusal to comply with existing protocol by adding even more protocol to not comply with...
Adding new command to the protocol will not solve the problem of the non-compliant GUIs; at best they will ignore it. This is why I initially proposed to use a backward ompatible way for an atomic draw-after-moe claim, as
1/2-1/2 {3-fold repetition after Rh7+ }
Old XBoard versions that would accept any claim would understand this, and newer GUIs that verify claims could scan the (REASON} for an "after" and parse the following move to see if it should treat the game as a draw or a false claim. But for better analogy with the ICS I finally opted for the
offer draw overloading.
The problem, stated again, is that we do not have an "end-of-move" indicator, so the draw claim / offer and move need to be combined into one message, so that the ambiguity of what goes with what becomes perfectly clear. At the moment, the "offer draw" may need to appear "out of sequence" where you want to use this to claim a draw _after_ your move causes a draw condition to become valid. This has come up enough times, it is apparent (at least to me) that this is problematic and confusing. It took some explaining in talking with Darooha 13-14 years ago before he understood the problem caused by the reaction time of computers.
It makes little sense to "offer a draw" when I am really claiming a draw. It makes little sense to offer a draw before a move, when I am really claiming a draw after a move (and I might really want to claim a draw and not make a move at all, which is perfectly legal according to FIDE/ICC rules.).
According to FIDE rules, you still have to make the move nown through whic you wantto draw, by writing it on your score heet. Keeping the score sheet is one of the tasks we deligated to the GUI in computer Chess. So you still have to send the move to the GUI, before it could accept your claim.
The ambiguity needs to go. So that this can be the last time this long-winded and pointless discussion happens.
BTW, to HGM: You are certainly correct that I am a long way from an expert on the xboard protocol. But you clearly don't understand why. The "why?" is answered by "Crafty played its first game on ICC in December of 1994. That is 15+ years ago. And it has been working just fine for that length of time. So I do not continually look at the protocol, because I do not continually modify the code to offer/claim draws, mates and losses. It just works. I made one significant change a few years ago, to offer a draw _before_ displaying a move, to match the FIDE rules for offering draws. Ditto for claiming draws.
There is nothing wrong with not being a protocol expert. Before I started workig on WinBoard I wasn't one either. But then,
please, do have a peek in the protocol specs before side-tracking the discussion with nonsense claims like "the
ics HOST command does not exit" or "there should be a
result before
1/2-1/2".
If no one sees the need to fix this, fine by me. But problems are going to _continue_ to pop up as new programs come along. Wrong results are going to get recorded when GUIs do something insane and call a draw claim that they don't understand, a loss. FIDE rules address invalid draw claims, and there is no mention of a forfeit. But even worse, the timing problem demands a logical solution. And it seems that demand is not going to be met.
The problem is that no single person controls all GUIs that are in existence. XBoard and ChessGUI do now propely address this point. They do it in a backward-compatible way, which does not interfere with the compatibility of the output an engine has to give with existing protocol. That is the best we can do. Non-compliance in other GUIs will have to be addressed by the authors of hose other GUIs.
I don't think it is a viable policy to exploit GUI bugs to devise work-arounds for other GUI bugs. If a GUI does not implement the
offer draw command, and refuses to relay it to the ICS, let it be a problem of the GUI. Do not resort to illegal use of
1/2-1/2 just because the offending GUI happens to send that as a draw offer to the ICS.
Preceeding your move by a draw offer should work on any GUI that relays the draw offer to an ICS, when playing an ICS, and it completely solves the race condition. And if they do not relay draw offers, let them fix it. There are plenty of other reasons than this race condition why the should relay draw offers. And if it does not solve the race condition in local mode, don't worry. Users of that GUI will be used to it, as other engines will suffer the effects of the race condition just as Crafty does, and the GUI users will correct the false results. Do not try to fix the GUI problems by quirky engine behavior.
I suppose I could verify proper operation of each GUI and if Crafty can detect that it is running on a non-rational GUI, just refuse to play. That at least will stop these occasional "strange behavior" issues when a GUI author makes an assumption that might seem logical at the time, but which is nonsensical when carefully analyzed. Draw claims do not end the game unless the TD says they end the game. But electronically we can't seem to get that idea across...
Well, it would definitely be a good idea to report details of GUIs where Crafty encountered problems using the method the protocol describes. Then the authors of those GUIs could address the problem and fix their GUI bugs, to the benefit of all. That would do a whole lot more than complaining to the authors of GUIs where thing do work according to protocol that it does not work on all GUIs...
