xboard protocol - a compromise that would work

[hgm]

Of course not. But what I have in mind is an evolution of the WB protocol where a more logical phrasing _can_ be used, perhaps thru protover 3. It took years before most everyone moved to protover 2. But even without protover 3, recognizing "draw" will not break existing programs, since they won't be using it. It can be added to protover 2 safely since it won't hurt anyone.

No! You still don't see the problem. Of course it is easy for a GUI to say protover 2 and still recognize a new command. But which engine would dare to use that command? Chances are that the GUI does not know the command at all, as there are many protocol v2 GUIs that don't. (In fact: all currently existing GUIs.) So it would be suicidal to rely on that command.

For this to work you would have to build in some mechanism through which the engine can figure out if it can use this new command. And if it figures out that he is talking to a GUI that doesn't, it still has to implement an alternative.

[Uri Blass]

"checkmate on the board trumps all other rules."

True, but my point was that the checkmate would not be on the board. Only on the score sheet. So the rule that the game immediately ends on checkmate cannot be invoked.

Of course a prson that can checkmate in one is not likely to claim a 50-move draw in stead, but it does seem an inconsistency in the rules.

I know that in my days as an active player, there were aways big rows when the flag fell after the checkmate but before the one performing the mate could press the clock. How is that resolved, nowadays? Practical consideration of course say that it should be counted as a loss, i.e. it should only be considered a checkmate after the clock was pressed. Ther is no way to prove the flag falling before or after any other event (e.g. releasing the piece, or grabbing it).

I had one case when I won a game when my flag fell after the mate(I am not sure if it was after the mate but nobody noticed that the flag fell before the mate).
The rules say simply that you do not need to press the clock after mating your opponent.

The only case when you can get a loss is if there is a proof that the flag fell before the mate.

I remember reading that in one case it happened when the opponent did not notice that the flag fell before the mate and the main referee did not notice but the referee that helped him noticed it.

The referee that helped the main referee was afraid to say something when it happened but told the main referee that the flag fell before the mate so it practically cause the main referee to change the result.

Note that these rules are practically only for long time control games.
There are different rules for active chess and for blitz.

In active chess it is the responsibility of the player to tell the referee that the flag fell and ask for a win.

In case that the player does not do it then even if the referee see that the flag fell the referee can do nothing about it.

Uri

[Uri Blass]

what I would _like_ to do is do the claim in the order I would use in a human event. examples:

(1) I want to claim a draw and do not need to make a move to do so. I would like to send "draw" and have the game end.

(2) I want to claim a draw after I play a move, because only after I play this move will the draw condition be valid. I would like to send "move xxx" and then "draw".

(3) I want to offer a draw to my opponent. I would like to send "move xxx" and then "offer draw".

(4) My opponent offers me a draw. I would like to send "draw" and not send a move.

(2) is not valid in a human event in the case of 3-fold repetition and the 50 move rule. The proper procedure is to write the drawing move down on your score sheet and present it along with your draw claim. If you actually play the move instead, then make the draw claim, then the claim is invalid. You cannot make a draw claim after you make your move. The last player to make a move on the board must always be your opponent for a draw claim to be valid.

Computers might be treated differently in this regard, but you asserted (2) as valid in a human event and this is not correct.

BTW, if you are ambiguous about whether you are making a draw offer or claiming a draw I would expect it would be interpreted as a draw offer, which can be refused of course.

You are right.
even if you make a move and stop the clocks and claim that the position repeated 3 times the draw claim is not valid based on the fide rule.

I practically did it correctly by first writing my move in a tournament game some years ago but for some reason did not think about it when the subject was about computers when writing your move is equivalent to making a move.

I also do not see the logic behind this fide rule and I think that it is more logical to change it and allow humans to claim a draw even after they complete the move as long as they did not press the clock.

Uri

It is very consistent with other FIDE rules and it makes a lot of sense. You have to claim things at your move, when your clock is running.

A bit unrelated, but to show the spirit of the rules, the correct etiquette to offer a draw is to move, offer a draw verbally, and then hit the clock. If you hit the clock and then offer, you are bothering your opponent in their time.

Miguel

I did not suggest not to claim a draw when my clock is running.

The point is that based on the fide rules if I make a move(and not only write it) and do not hit the clock and claim a draw based on the fact that my move caused second repetition I do not get the draw.

The relevant parts of the fide rules:

http://www.fide.com/fide/handbook?id=124&view=article

9.4:If the player makes a move without having claimed the draw he loses the right to claim

No need to hit the clock in order to complete making a move based on 4.6:

"The move is considered to have been made when all the relevant requirements of Article 3 have been fulfilled.

in the case of a capture, when the captured piece has been removed from the chessboard and the player, having placed his own piece on its new square, has released this capturing piece from his hand;

in the case of castling, when the player`s hand has released the rook on the square previously crossed by the king. When the player has released the king from his hand, the move is not yet made, but the player no longer has the right to make any move other than castling on that side, if this is legal;"

Uri

Your suggestion will have no advantage and could be the cause of many problems.

Miguel

I see no problem with my suggestion.

I do not suggest to allow players to claim a draw at the time of the opponent.

I suggest only to allow players to claim a draw based on the move that they intend to play after they make a move but before they hit the clock.

All the procedure of writing a move without making it on the board seems to be silly to me espacially when the rules today say that normally people need first to make a move and only later to write it(it is something new that is only in the last years).

Uri

[bob]

Of course not. But what I have in mind is an evolution of the WB protocol where a more logical phrasing _can_ be used, perhaps thru protover 3. It took years before most everyone moved to protover 2. But even without protover 3, recognizing "draw" will not break existing programs, since they won't be using it. It can be added to protover 2 safely since it won't hurt anyone.

No! You still don't see the problem. Of course it is easy for a GUI to say protover 2 and still recognize a new command. But which engine would dare to use that command? Chances are that the GUI does not know the command at all, as there are many protocol v2 GUIs that don't. (In fact: all currently existing GUIs.) So it would be suicidal to rely on that command.

For this to work you would have to build in some mechanism through which the engine can figure out if it can use this new command. And if it figures out that he is talking to a GUI that doesn't, it still has to implement an alternative.

If all we do is add a new command, and don't change _anything_ else, then this change can not _possibly_ hurt any engine that doesn't know about the new command, because they would never use it in the first place.

In that light, I do not see the problem. They can use the new command and solve an existing problem. They can use the old commands and continue to live with this existing race condition that they are probably unaware of anyway.

But no way a new command hurts anyone since they would not be using it unless they chose to do so after reading the description. If this is added to the protocol, the command is not optional for a WB_compatible GUI to implement. It becomes mandatory.

[bob]

in case 1 the worst case is that the game never ends. No guarantee you are playing against someone who can accept draws.

Indeed. And this is why the protool continues to require the 1/2-1/2 termination mesage, after the move, for the engine to sign off. The old specs stipulated that this was obligatory ("must send"), and I have not changed the specs of the RESULT command. I just changed XBoard's implementation to not unconditionally believing the reported result, but correcting it. The specs don't define what the effect of this commands (or any engine->GUI) command should be if it is used illegally (i.e. in violaation of the protocol).

But what idiot would send 1/2-1/2 _AFTER_ the move, when there is a reasonable chance that is equivalent to "resign"? Because of the race condition.

That has been the problem all along.

[bob]

How long does a 3-fold-rep or 50-move-rule pend, if not claimed ?
Till end of game ?

Matthias.

3-fold can only be claimed at the instant it happens. Or if missed, one can claim a 3-fold repetition after 4, 5, 6, ..., N repetitions just as correctly. A 50 move draw can be claimed at any time after the 50 reversible moves by both sides, and for as long as no reversible move has been played. Once that happens, the draw can not be claimed until another 50 reversible moves have been played by both sides.

As far as the draw "claim" it should be tried before the move, and after the move, and if it doesn't fit either, it should disappear. In the case of the 1/2-1/2 Crafty sends, if it doesn't fit before or after the move, you could record it as a loss because this will never happen unless I introduce a bug.

The only issue is the case of a draw after my move, and the resulting race condition that almost makes it necessary to make the claim before the move.

If everyone will fix their implementation, so that I can safely send 1/2-1/2 without a move if the position before my move is a draw, or I can send 1/2-1/2 after my move if the position after my move is a draw, and they eliminate the race condition by trying to apply the 1/2-1/2 claim immediately after my command, assuming my opponent has already played a response, I'd be happy. I can now do what I do in real chess games, and the problem is solved.

Right now, 1/2-1/2 is completely unusable because it can easily turn into a resign due to the race condition.

[hgm]

If all we do is add a new command, and don't change _anything_ else, then this change can not _possibly_ hurt any engine that doesn't know about the new command, because they would never use it in the first place.

In that light, I do not see the problem. They can use the new command and solve an existing problem. They can use the old commands and continue to live with this existing race condition that they are probably unaware of anyway.

No! They can never use the new command, because they do not know if the GUI will understand that command. They only know that there are some GUIs that do understand it, and many that do not.

So the new command cannot _possibly_ benefit them.

But no way a new command hurts anyone since they would not be using it unless they chose to do so after reading the description. If this is added to the protocol, the command is not optional for a WB_compatible GUI to implement. It becomes mandatory.

Yes, and then, by magic, all old GUIs disappear from the surface of the Earth. Get real!

What will happen in practice is that almost every GUI writer will say:
"We don't plan to make a new release soon."
"For now we only support protocol v2."
"We limit ourselves to the commands in the original specs."
""

[hgm]

But what idiot would send 1/2-1/2 _AFTER_ the move, when there is a reasonable chance that is equivalent to "resign"? Because of the race condition.

There is no reasonable chance.

There is no known GUI that would make it equivalent to "resign" if you use it when you use it according to the specs.

Hardly any GUI would equate false claims to forfeits anyway, and those that do make sure they account for te race condition.

You worry for nothing. That is paranoia.

The problem with ChessGUI only originates because you resort to illegal use of the 1/2-1/2 command. Do not use it for advance claims or false claims, and you will safe.

BTW, current XBoard will also forfeit you for illegal moves. Does that mean you must be an idiot to make a move, if there is a reasonable chance that it will be taken as equivalent to "resign"? Or do you have confidence that your engine will be abe to pick legal moves?

[bob]

In looking at the code, Crafty uses "offer draw" when it wants to offer a draw. I do this when I have seen the draw score at the root for N consecutive moves (N varies depending on opponent rating, since weaker players might not see the position is drawish and make a mistake). I do not use "offer draw" to claim a draw at present, since it is counter-intuitive. In the game in question, Crafty probably assumed that the opponent did not want the draw and could avoid it by playing a different move that would still leave it positionally ahead. But once the repetition is actually found at the root (3-fold, not 2) it will instantly claim it. The 1/2-1/2 was sent dirst to avoid the race condition.

Yes, and this is the problem. This is illegal use of the 1/2-1/2 command. The game is not over yet before you announce your move. You only got away with it because XBoard accepted any RESULT claim in any situation. (Much to your, or anybody's chagrin.) It is this situation I was referring to when I id that current XBoard would do exactly the same as what ChessGUI did.

Which means the 1/2-1/2 is unusable, it would seem, because of the well-known race condition between the draw claim (1/2-1/2) and the opponent's move, either of which xboard could receive and process first.

I patched my version of xboard years ago to deal with this. If I send the 1/2-1/2 after my move, it is effectively pointless since the race condition can cause the claim to be invalid there. The bottom line is that 1/2-1/2 simply does not work with 100% reliability in any current GUI.

You mean in ICS play. In loca play it always worked in XBoard. In old versions because any claim, no matter how silly, would be accepted, and in current XBoard because it is aware of the race condition, and checks your claim against both the position before and after the opponent's move.

No. I have used xboard for several years to test against other engines. I had found the "invalid result" problem many years ago where programs would screw up the 1-0 vs 0-1 when playing black. My version of xboard will accept results from Crafty, but not from any opponent. My original referee did this and all worked perfectly. Until someone wanted to see me play a big round-robin which would mean Crafty would not participate in every game played. I then had to modify my referee to keep the game state and end the game on 50-move rule draws or repetitions, regardless of what the players did or did not claim. It's amazing to me how many existing programs are unaware of the 50 move rule, as one example.

If I have to send my move first, my opponent can reply and break the draw condition before my draw claim (1/2-1/2) is even seen, and when it comes in, and is rejected, I lose. If I send it before my move, and the GUI doesn't know to try to apply it after my move, I lose.

I think anyone can see the problem. 1/2-1/2 is just another way to "resign".

If sending either before or after the move does not help, do both. Before the move you send offer draw, because it is harmless on any old or new GUI, and has the effect that the ICS requires, namely that "draw" is sent to the ICS. Then send move, and then 1/2-1/2. The ICS will by that time have granted you a draw. And in local play, ay GUI that respecys the protocol should now grant you a draw, if it hasn't already done so. Othrwise it will be the fault of the GUI, as in lcal play it canot hide behind the ICS, and is the final authority, responsible for all its actions.

My program is perfectly capable of continuing to play after the 1/2-1/2 command, if it is rejected. But since you were adamant that this "ends the game" I proposed a "draw" command that is "softer". I can make the claim before making a move to claim a drawn position before I make a move, I can make the claim after the move to claim a drawn position after making the move that produces the drawing condition. And the obvious race can either be handled by the gui or not, without Crafty losing the game if the GUI disagrees because it doesn't handle the race.

After some thought, the draw after the move is probably not a good idea because it is an issue with ICC. I think, therefore, that that would be a bad idea. However, I still don't like "offer draw". The alternative is to fix 1/2-1/2 so that it works reasonably. I claim 1/2-1/2. If it is valid, the game ends. Otherwise, you try it _after_ my move. If it is valid, the game is a draw. At this point, you can then give me a loss if the claim is wrong (it never will be). And we have eliminated the race condition

[bob]

If all we do is add a new command, and don't change _anything_ else, then this change can not _possibly_ hurt any engine that doesn't know about the new command, because they would never use it in the first place.

In that light, I do not see the problem. They can use the new command and solve an existing problem. They can use the old commands and continue to live with this existing race condition that they are probably unaware of anyway.

No! They can never use the new command, because they do not know if the GUI will understand that command. They only know that there are some GUIs that do understand it, and many that do not.

What part of the concept "protocol" don't you understand? No part is optional to the GUI. We do allow programs to select bits and pieces of the protocol via the "feature" commands. But the GUI must handle them all or it is non-compliant.

If we fix a way to claim a draw that works logically and reliably, I will be happy. The last time we had this same discussion I suggested fixing 1/2-1/2. So that it could be properly interpreted without worrying/caring about the potential race condition with my opponent's next move. That went nowhere. Your statement was that the result will end the game. Let's go with that. But make it work correctly so that 1/2-1/2 will never turn into 1-0/0-1 just because my opponent's move beat my draw claim to the GUI. If you can make that work, and everyone else does as well because the protocol definition is modified to make this perfectly clear as to how the 1/2-1/2 is treated, all will be well.

So the new command cannot _possibly_ benefit them.

But no way a new command hurts anyone since they would not be using it unless they chose to do so after reading the description. If this is added to the protocol, the command is not optional for a WB_compatible GUI to implement. It becomes mandatory.

Yes, and then, by magic, all old GUIs disappear from the surface of the Earth. Get real!

Or they simply fix their GUI to match the protocol. This is not uncommon. Protocols evolve. And everything doesn't break.

What will happen in practice is that almost every GUI writer will say:
"We don't plan to make a new release soon."
"For now we only support protocol v2."
"We limit ourselves to the commands in the original specs."
""

Anyone can bury their head in the sand. I have identified a significant problem in the protocol, and have explained it as clearly as I know how. If they are not willing to fix it, then I would not care if they survive or not. We don't keep an old protocol with a bug, rather than fixing the bug, simply because some are not willing to support it. We have a bug _either_ way. At least as GUIs adopt the new command or new semantics, whichever is changed, the race condition slowly goes away. Right now it is there, and I'd bet a bunch that most have no idea it is there prior to this discussion. And games have been lost when they should have been drawn as a result. And nobody knows.

Makes no sense to ignore that.