xboard protocol - a compromise that would work

[bob]

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.

This is not your problem, but that of the GUI author. Stick to the protocol, and trust that the GUI will make _sure_ that you are _never_ wronged.

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.

Well, this is what I m saying, so I don't understand your "no". But this is an entirely unrelated problem. It has nothing to do with race conditions, and you cannot avoid it by abstaining from using 1/2-1/2. Because it is the opponent that will continue to make those mistakes, and stupid old GUIs that continue to fall for it.

My version of xboard will accept results from Crafty, but not from any opponent.

Well, nice for you, but not usable for a GUI. It mght be inconceivable for you, but some people want to play games where Crafty is _not_ one of the players.

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.

Yes, indeed. And at 1300 Elo that is 100 times worse. This is why I added the options -checkMates, -testClaims, and -materialDraws to XBoard, so that you don't have to depend on any claim, if you don't want to.

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.

There is no known GUI that has this behavior.

So you are saying that _no_ GUI will reject a 1/2-1/2, even if it thinks it is incorrect?

No
I understand that
H.G.M is saying that no existing gui is going to reject a draw claim after making a move that leads to draw by repetition or the fifty move rule.

It doesn't matter what he _says_. What matters is what actually happens.

If

(1) A GUI has an option, whether on by default or settable, to validate these "result strings" to prevent a program from cheating and claiming a win when it is losing;

and

(2) it doesn't understand the potential race condition where I send a move, and a draw claim, but the opponent sends an instant reply after my move, and before the GUI sees my draw claim;

and

(3) the GUI doesn't understand that if the race occurs, the draw claim will come at a point where it appears to be invalid since my opponent has already made a move that invalidates the draw claim;

and

(4) The GUI does not then back up the internal game state by unmaking the opponent's move, and then see if the draw claim is valid (which it will be);

then

There is going to be a problem. Even winboard has a result verification option according to HGM. So if one turns that on, and encounters the race condition, will the result be properly declared or rejected. I have not looiked at his code, but old xboards did not try to back up the game and there was no code for that, however it would accept the result whether correct or not.

So whether or not any other GUI has a problem or not is not something I believe any single person can say with absolute certainty. It is not my imagination. And it is not going to go away unless the protocol explains the problem and what the GUI needs to do to avoid it.

If a GUI is only proactive and ends the game when a possible draw condition arises, then this won't be an issue. But I would hope that there are _some_ GUIs out there that play by FIDE rules, so that a human can continue to play on rather than claiming a draw if he so chooses. And if the GUI does not end the game at the first drawing condition, the race can occur. And if it validates the claim, the race can cause a loss when it is not a correct result.

The only funny exception(mentioned originally by H.G.Muller) that is not what you meant may be if the move mates the opponent and also leads to 100 plies with no conversion and unlike human play this is a case to care about because computers may claim a draw by the 50 move rule because of a bug even when they mate the opponent and it is not clear if the gui should give a draw or a win for the engine.

I understood that in computer games the only case of rejecting 1/2-1/2 because the opponent made a move is in ICS and
I see no problem even with ICS if you simply add offer a draw before making the move when you simply claim a draw after it.

Uri

I do not believe the FIDE rules require that I know that I mated my opponent. In fact, I have played quite a few moves over the years that turned out to be mate because of a piece across the board attacking what I thought was an escape square for my opponent. It is my understanding that if you mate your opponent, the game ends immediately. I will try to look this up tomorrow to see if the FIDE rules address the case where I write down a move that unknowingly gives mate, and then stop the clock and ask the arbiter to come over and verify my draw claim, what will happen when he notices that it is a mate. I believe he will use that result.

[bob]

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.

The part that says v2? That said "backward compatibility"?

OK, so all GUIs will be non-compliant, after you wave your magic wand. So now what are you going to do against that? One driver going opposit the trafic in the wrong lane? You will see thousands!

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.

It has been working like that for ages. Wake up.

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.

Instead of nagging like a child, name me a single GUI were you were forfeited for using 1/2-1/2 _after_ the drawing move. You seem totally out of touch with reality.

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.

You have identified a problem that only exists in your mind, as it was removed from the protocol long ago.

If they are not willing to fix it, then I would not care if they survive or not.

Why would they fix something that is not broken, except in your nightmares?

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,

It is only there because they are very slow to adapt the "new semantics", which isn't even really new. But there is nothing we can do about that. There are things we can do to encourage them to be slow, though. And _you_ are doing them...

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.

Indeed. As it is most likely not true. I will make it really easy for you. Show us one such game.

Makes no sense to ignore that.

It would seem to me that you said that _NO_ gui has this problem. It should be your proof to back that up. I don't have enough knowledge to speak for all the other GUIs. And something tells me that neither do you.

You are saying _no_ GUI validates a 1/2-1/2 draw claim before accepting it? That _ALL_ just blindly take the result and use it as is, right or wrong? I though even your new xboard had an option to validate results? So if any subset of GUIs do validate the claim, you are convinced that none of them have the draw problem? When even you didn't understand it until I explained it last year?

Convinces me...

Nobody can have this problem...

Don't know why I bothered to bring it up. Oh yes, xboard had the problem before I pointed it out and you changed the way "offer draw" works, correct?

[bob]

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.

The problem is that some old GUIs won't/can't upgrade.

Matthias.

So the internet will _never_ move to IPV6???

hang around for a couple more years and see how that pans out...

[bob]

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.

Unfortunately, the software using protover 2 is written by dozens or even hundreds of different people. Some of them will have abandoned maintenance of their engines and GUIs and will be unwilling to change them. Even for the ones that were updated, old versions would still exist and would be in users hands. This is what hgm was getting at, and so I apologize for belaboring the point here.

The very definition of "backward compatibility" is that new stuff continues to work with old stuff. If we change the protocol and start making new engines and GUIs that work with it, they still need to be able to talk to many of the old GUIs and engines that are out there. Using the "feature" command, the engine and the GUI can negotiate about what behaviour to use. But old GUIs will not recognize a new "feature", so even new engines will need to be able to work with the OLD behaviour of the GUIs. Even if you want to write a new engine that refuses to run with old GUIs, you need something (such as a "rejected" feedback about the new feature) to help you identify the old GUIs.

All of this is saying, that we can't unconditionally add "draw" to the protocol without breaking backward compatibility. We could however add "draw" to the protocol along with a "feature draw" which the old GUIs would reject, the new GUIs would accept, the new engines would only send if the GUI accepted the feature, and the new GUIs would only require if the engine requested the feature. The new GUIs would still have to support the old behaviour (e.g. detecting draws in positions before AND after the move, and allowing the claim for either one) for old engines, although they could switch that behaviour off if the engine was a new engine that somehow promised not to rely on it (such as by sending "feature draw"). But new engines would still need to be able to send the old "offer draw", "move ...", "1/2-1/2 {...}" sequence if their feature was not accepted---in other words, when talking to an old GUI.

Perhaps one day you will get the point. If I can not safely send 1/2-1/2 _AFTER_ I make a move, to say "the game is over after my move" then I would be an idiot to send it ever. Crafty doesn't make illegal moves. So that is not an issue. 1/2-1/2 is not illegal or invalid after I make a move that satisifies a drawn game definition. But it is unreliable due to the race condition.

I think sending 1/2-1/2 (yes, after your drawing move) is the only way to tell "dumb" GUIs, such as the really old xboard, that the game is definitely over now. So you should include that after your drawing move, in addition to sending "offer draw" before that move. If you claim that the game has ended, "dumb" GUIs will believe you. If you don't send that result string, then they might simply relay "offer draw" to your opponent, who might also be unable or unwilling to accept.

[Edit: actually... if "dumb" GUIs believe you unconditionally, then you should not have a problem with the race condition there. I guess the race condition is only a problem with GUIs that try to validate a draw claim in some fashion.]

But as far as ICS or modern "smart" GUIs are concerned, they should already have ended the game by then because of "offer draw" followed by your move which produced the position in which the draw could be claimed. Since Crafty doesn't make incorrect draw claims, and there is no race condition with the smart GUIs if the "offer draw" was sent before the move... it should be impossible for Crafty to be penalized for sending 1/2-1/2 unless there is a bad bug in the GUI.

Here's the problem. In Crafty, the two actions "offer draw" and "claim draw" are handled by different pieces of code.

Crafty "claims" a draw when a drawing condition has been satisfied, such as 3-fold repetition at the root, 50 move rule, or stalemate. Crafty "offers" a draw when the evaluation shows "draw score" for N consecutive moves in the game. N varies and is lowest against GM-level players and higher against lower rated players to give them more time to make a mistake and let the score creep up past "drawscore".

So I don't output "offer draw" when I see a physical draw on the board, any more than I would "offer a draw" to my opponent after making a 3-fold repetition move...

[hgm]

Read back to last year where you said "I am not changing the way the result command is handled..."

Apparently you silently decided to do just that.

First, this is probably just the umptieth false claim you make in this discussion, so I won't even bothe to read back unless you quote or give us the link.

But the important point is that I can do silently whatever I want to the handling of any command, as long as the behavior of this command continues to conform to the existing specs. (Or does so better than before.) This is implementation, and is no business of the user (engine programmer). They just have to follow specs, and only have the right to complain if I make changes that do violate protocol specs.

Specs say, and always have been saying, that the engine _must_ send a RESULT command when it detects that the games is _definitely_ over. When you stick to that, it is my job to make sure that engines that stick to that acheive the intended effect, and I can do whatever it takes to make that happen, without informing you.

Effects of violating the protocol are not strictly defined in the specs. (It would be stupid to do that, as it would make extension of the protocol in a backward compatible way impossible.) This means you cannot rely on protocol-violating behavior having the same effect in future implementations. But if my new implementation chances the behavior of protocol violations that I discover to be in common use, I have the courtesy to warn people aganst it.

Which suits me just fine. When I have time I will try the just modified version of Crafty and play a million almost instant games to see if there is any remaining issue...

Great. Don't forget to safe the GUI debug files for games where you encounter a GUI bug, so it can be sent to the respective GUI author, and they can fix it. Just coming with the statement "it did not work" after a million games is not helpful.

Rest assured: GUIs do contain bugs, and wil probably always contain bugs. Even the other day one was reported in the WinBoard forum, where a forfeit on time was incorrectly "corrected' to a draw, because the forfeiting side was facing a bare King (while in fact it was facing KRP). This was likely caused by setting up the board for the new position, and incrementing the move number in the wrong order, so that the GameEnd() routine invoked by the clock interrupt was testing an incomplete board. An extremely rare occurrence, but in a million game you might pobably see a few.

Oh yeah? And which version was that? From before you wrote Cray Blitz?

The version I am currently using, before modification.

They have numbers, you know. Look in the "Help -> About" menu. "I am currently using" and "before modifiction" are totally meaningless descriptions. Of course you are using the version that you are currently using. And it is being modified ever since version 0.0.0...

1/2-1/2 after a move was problematic because of the race condition. That's why I brought this up the _last_ time this discussion was held.

Currently in ChessGUI, it appears that 1/2-1/2 is irrelevant. As is 1-0 and 0-1, because ChessGUI declares the game over without the program's knowledge, which is fine for normal testing, but not so fine for tuning before playing in a human event.

So apparently, some where in xboard/winboard, when you get the 1/2-1/2, you notice that my opponent has made a move that invalidated the claim, and you then quickly back up to the position prior to his move to see if the 1/2-1/2 is valid? And if so, you end the game.

Exactly. Like I have written about five times before in the two current discussions. Let's hope it sinks in this time.

If not, what?

If not, the game is terminated for reasons of a "false claim", if the user has ticked this option and it is a comp-comp game. Otherwise (of the user prefers it or the opponent is a Human) the old behavior of accepting the claim anyway occurs (and I don't even bother to backup the move and check). This stil terminates the game, but with a draw result for whatever (false) reason the engine gave. If the opponent is an ICS, the old behavior of relaying the 1/2-1/2 as an ICS "draw" command to the ICS occurs.

So you are saying that _no_ GUI will reject a 1/2-1/2, even if it thinks it is incorrect? All I can do here is offer my congratulations for knowing what every gui out there does.

You miss the nuance. _Known_ GUI. Known to me...

We at least know that ChessGUI will turn an incorrect draw claim into a loss. It only avoids this problem by ending the game itself before the race condition shows up. But do you _really_ know that the other many GUIs out there, of which there are a bunch, do not check the correctness of a claim to end the game before doing so? I know of one that does. I use it every day on my cluster. I just don't turn bogus claims into losses, I ignore them. But if anybody checks the correctness, and is not aware of the race condition (which it appears most have no idea that such a problem exists) then they are going to have this problem. And the current protocol description does not explicitly tell them what to do to solve the problem, as it doesn't even mention the problem.

The protocol specs are not intended as a "one-page course to GUI programming". But I am not against attaching a small warning for GUI programmers to the description of the RESULT command. How about this:

Note to GUI programmers: RESULT commands that the engine sends immediately after its move might be detected by the GUI only after the opponent has moved, because of communication and scheduling delays, no matter how fast the engine sent it. Any judgement of the validity of RESULT claims based on te "current" board position will have to account for this uncertainty.

[hgm]

It doesn't matter what he _says_. What matters is what actually happens.

If

(1) A GUI has an option, whether on by default or settable, to validate these "result strings" to prevent a program from cheating and claiming a win when it is losing;

and

(2) it doesn't understand the potential race condition where I send a move, and a draw claim, but the opponent sends an instant reply after my move, and before the GUI sees my draw claim;

and

(3) the GUI doesn't understand that if the race occurs, the draw claim will come at a point where it appears to be invalid since my opponent has already made a move that invalidates the draw claim;

and

(4) The GUI does not then back up the internal game state by unmaking the opponent's move, and then see if the draw claim is valid (which it will be);

then

There is going to be a problem.

The point is that there is hardly any GUI that does (1). And this is a necessary condition for the race-condition problem to occur. (Of course it is then replaced by the problem of result contamination by granting false claims, but the users of such GUIs employ separate software to validate PGN results.)

Even winboard has a result verification option according to HGM.

What do you mean, _even_ WinBoard??? You are talking about the most advanced GUI in the World! To my knowledge, WinBoard was the first GUI to implement claim verification in engine-engine games. Most commercial GUIs only care about Human-engine games anyway.

So if one turns that on, and encounters the race condition, will the result be properly declared or rejected. I have not looiked at his code, but old xboards did not try to back up the game and there was no code for that, however it would accept the result whether correct or not.

Indeed. If you accept any claim, ther is no race condition. If you automatically declare any claimable draw a draw, there is no race condition. Only when you want to pay attention to the engine caims, and test their validity based on a position, you might have to deal with the race condition.

So whether or not any other GUI has a problem or not is not something I believe any single person can say with absolute certainty. It is not my imagination. And it is not going to go away unless the protocol explains the problem and what the GUI needs to do to avoid it.

The point is that this is not your problem, as an engine programmer. Even if there are GUIs that handle this wrong, it is the GUIs that should be fixed, and not the engine author that should try to devise silly work-arounds to make his engine work wit the buggy GUI.

If a GUI is only proactive and ends the game when a possible draw condition arises, then this won't be an issue. But I would hope that there are _some_ GUIs out there that play by FIDE rules, so that a human can continue to play on rather than claiming a draw if he so chooses. And if the GUI does not end the game at the first drawing condition, the race can occur. And if it validates the claim, the race can cause a loss when it is not a correct result.

Note that XBoard also has such a proactive mode, which the user can switch on in engine-engine games. (But not against Humans or ICS.) In automated testing it is very important to have that, or you will come back the next morning and you will only see a few dozen games, the last one still running with 100,000 moves, in stead of a nicely finished gauntlet of a few thousand games. If both engines do not claim 3-fold reps or 50-move, there is no limit to the duration of a game, at classicl TC.

This point was pressed upon me again when I was testing my Xiangqi engine: XBoard considers Pawn moves irreversible, and I had forgotton to make an exception for sideway Pawn moves. So the engine was simply pushing his Pawn back and forth over the back rank, keeping the 50-move counter at zero, and shuffling all its other pieces to avoid a repeat (which you can keep up for many thousands of moves, even with a few pieces.) I fixed that now, of course.

I do not believe the FIDE rules require that I know that I mated my opponent. In fact, I have played quite a few moves over the years that turned out to be mate because of a piece across the board attacking what I thought was an escape square for my opponent. It is my understanding that if you mate your opponent, the game ends immediately.

This is off topic, really, but the point is that you have not mated the opponent by merely writing down the move. You must make it on the board.

I will try to look this up tomorrow to see if the FIDE rules address the case where I write down a move that unknowingly gives mate, and then stop the clock and ask the arbiter to come over and verify my draw claim, what will happen when he notices that it is a mate. I believe he will use that result.

[hgm]

It would seem to me that you said that _NO_ gui has this problem. It should be your proof to back that up.

Wrong again. Ever heard of the "assumed innocent until proven guilty" principle? You accuse other GUIs of a crime, namely violating the protocol specs. (Which state that you should use 1/2-1/2 to end the game in a drawn position.) That is a heavy accusation, and you should back it up (or risk libel charges. ).

I don't have enough knowledge to speak for all the other GUIs. And something tells me that neither do you.

You are saying _no_ GUI validates a 1/2-1/2 draw claim before accepting it? That _ALL_ just blindly take the result and use it as is, right or wrong?

To my knowledge, yes. Because this is what XBoard used to do. Most GUIs don't care much about XBoard protocol anyway, they only consider it a pain in the neck. But the truth is that I don't really care much what they do. And neither should you. But apparently you do, which means that you now have to make a case. Such is the fate of plaintiffs, if their cases do not have any substance whatsoever, they will be thrown out of court.

I though even your new xboard had an option to validate results? So if any subset of GUIs do validate the claim, you are convinced that none of them have the draw problem? When even you didn't understand it until I explained it last year?

Like I said, I am not aware of any GUIs that validate draw claims, other than my XBoard and ChessGUI. And these are both OK. So it is not really important if the programmers of these other GUIs were aware of the race condition or not.

Convinces me...

Nobody can have this problem...

Don't know why I bothered to bring it up. Oh yes, xboard had the problem before I pointed it out and you changed the way "offer draw" works, correct?

To be exact, no problems with the race condtion were actually reported. What I reported was that some engines (notably Crafty) did violate protocol by claiming draws that had not materialized yet, in the absence of any race condition.

You then explained the race condition, and that the non-compliant Crafty behavior was a work-around for this race condition on the ICS. I payed proper attention to this: I solved the potential problems with the race condition in local play in the GUI, and indicated an alternative work-around for the ICS problem, which was compliant with existing protocol specs. And I added a paragraph to the protocol specs to point out this work-around.

But, unlike what you seem intent on suggesting here, the problem was _not_ that Crafty fell victim to the race condition. Not then, and not now, in the case with ChessGUI. In both cases it was caught at non-compliant behavior. (Sending 1/2-1/2 before the move that caused a claimable draw). I immediately pointed that out (which you called 'rambling'), but you denied everything, claiming that Crafty never sent 1/2-1/2, and only offer draw (which later turned out to be all falsehood, when people posted the debug file).

I said it before, and discussion since then has only stressed these points
1) Your knowledge of WB protocol is extremely flakey, but you write nonsense aout it with an attitude like you are expert in it.
2) You don't seem to be aware what Crafty actually prints, until people show you irrefutable proof of it.

And in the mean time I can add to that:
3) You continue to ask the very same question over and over again, even when it was answered every time before. Why ask these questions in the first place, if you don't want to bother reading the answers???

Now stop bugging everyone, and use the protocol according to specs, which is that the sequence offer+move+claim should always grant you a draw-after-the-move, race condition or now race condition, if the claim was correct, in ICS as well as local play. And only come back here when you have a real case (i.e. when you can show us a real-live example where this did not work).

[bob]

It doesn't matter what he _says_. What matters is what actually happens.

If

(1) A GUI has an option, whether on by default or settable, to validate these "result strings" to prevent a program from cheating and claiming a win when it is losing;

and

(2) it doesn't understand the potential race condition where I send a move, and a draw claim, but the opponent sends an instant reply after my move, and before the GUI sees my draw claim;

and

(3) the GUI doesn't understand that if the race occurs, the draw claim will come at a point where it appears to be invalid since my opponent has already made a move that invalidates the draw claim;

and

(4) The GUI does not then back up the internal game state by unmaking the opponent's move, and then see if the draw claim is valid (which it will be);

then

There is going to be a problem.

The point is that there is hardly any GUI that does (1). And this is a necessary condition for the race-condition problem to occur. (Of course it is then replaced by the problem of result contamination by granting false claims, but the users of such GUIs employ separate software to validate PGN results.)

First, I thought the same. And I lost a game when ChessGUI said "this claim is invalid, you lose." Supposedly Arena is doing the same thing according to (I believe) Graham who said the same problem occurred there.

Even winboard has a result verification option according to HGM.

What do you mean, _even_ WinBoard??? You are talking about the most advanced GUI in the World! To my knowledge, WinBoard was the first GUI to implement claim verification in engine-engine games. Most commercial GUIs only care about Human-engine games anyway.

I've been using winboard/xboard since long before you could even spell it. I've always been perfectly happy with it. And some of the features you have added have been quite useful and well-done. But there is an ambiguity in the protocol that requires a god-awful kludge from the programmer to make it work correctly. So much of a kludge that most authors are unaware of the problem, much less the solution. I've made the necessary change to how crafty "claims" a draw, in version 23.1. I'll just "wait and see" to determine how well it works in the general case.

So if one turns that on, and encounters the race condition, will the result be properly declared or rejected. I have not looiked at his code, but old xboards did not try to back up the game and there was no code for that, however it would accept the result whether correct or not.

Indeed. If you accept any claim, ther is no race condition. If you automatically declare any claimable draw a draw, there is no race condition. Only when you want to pay attention to the engine caims, and test their validity based on a position, you might have to deal with the race condition.

So whether or not any other GUI has a problem or not is not something I believe any single person can say with absolute certainty. It is not my imagination. And it is not going to go away unless the protocol explains the problem and what the GUI needs to do to avoid it.

The point is that this is not your problem, as an engine programmer. Even if there are GUIs that handle this wrong, it is the GUIs that should be fixed, and not the engine author that should try to devise silly work-arounds to make his engine work wit the buggy GUI.

Anytime I lose a game that is should be drawn, it is definitely "my problem". I'm the one losing 1/2 point. Whether it is in an important event or not doesn't matter that much.

If a GUI is only proactive and ends the game when a possible draw condition arises, then this won't be an issue. But I would hope that there are _some_ GUIs out there that play by FIDE rules, so that a human can continue to play on rather than claiming a draw if he so chooses. And if the GUI does not end the game at the first drawing condition, the race can occur. And if it validates the claim, the race can cause a loss when it is not a correct result.

Note that XBoard also has such a proactive mode, which the user can switch on in engine-engine games. (But not against Humans or ICS.) In automated testing it is very important to have that, or you will come back the next morning and you will only see a few dozen games, the last one still running with 100,000 moves, in stead of a nicely finished gauntlet of a few thousand games. If both engines do not claim 3-fold reps or 50-move, there is no limit to the duration of a game, at classicl TC.

This point was pressed upon me again when I was testing my Xiangqi engine: XBoard considers Pawn moves irreversible, and I had forgotton to make an exception for sideway Pawn moves. So the engine was simply pushing his Pawn back and forth over the back rank, keeping the 50-move counter at zero, and shuffling all its other pieces to avoid a repeat (which you can keep up for many thousands of moves, even with a few pieces.) I fixed that now, of course.

I do not believe the FIDE rules require that I know that I mated my opponent. In fact, I have played quite a few moves over the years that turned out to be mate because of a piece across the board attacking what I thought was an escape square for my opponent. It is my understanding that if you mate your opponent, the game ends immediately.

This is off topic, really, but the point is that you have not mated the opponent by merely writing down the move. You must make it on the board.

Not quite true. When I write down the move and call the arbiter over, I now am _forced_ to play that move, unless it is illegal. The arbiter should come over to verify the claim, and when he examines the position after the move I write down, looking for a 3-fold rep, he should notice that that move checkmated my opponent and ended the game.

Nothing to do with the protocol discussion, but someone brought it up.

I will try to look this up tomorrow to see if the FIDE rules address the case where I write down a move that unknowingly gives mate, and then stop the clock and ask the arbiter to come over and verify my draw claim, what will happen when he notices that it is a mate. I believe he will use that result.

[bob]

It would seem to me that you said that _NO_ gui has this problem. It should be your proof to back that up.

Wrong again. Ever heard of the "assumed innocent until proven guilty" principle? You accuse other GUIs of a crime, namely violating the protocol specs. (Which state that you should use 1/2-1/2 to end the game in a drawn position.) That is a heavy accusation, and you should back it up (or risk libel charges. ).

Ever heard of the old general rule that any statement with the word "never" or "always" is generally false? I'm unable to prove or disprove whether there is any GUI that has this problem or not. I have no idea how many GUIs there are out there. I have two that have never been released except to a very few people, as an example. I can't possibly test every GUI, and your making a claim that covers _all_ of them is simply silly.

I don't have enough knowledge to speak for all the other GUIs. And something tells me that neither do you.

You are saying _no_ GUI validates a 1/2-1/2 draw claim before accepting it? That _ALL_ just blindly take the result and use it as is, right or wrong?

To my knowledge, yes. Because this is what XBoard used to do. Most GUIs don't care much about XBoard protocol anyway, they only consider it a pain in the neck. But the truth is that I don't really care much what they do. And neither should you. But apparently you do, which means that you now have to make a case. Such is the fate of plaintiffs, if their cases do not have any substance whatsoever, they will be thrown out of court.

We certainly know there is at least _one_ exception to that. I sent 1/2-1/2 to ChessGUI and lost the game.

I though even your new xboard had an option to validate results? So if any subset of GUIs do validate the claim, you are convinced that none of them have the draw problem? When even you didn't understand it until I explained it last year?

Like I said, I am not aware of any GUIs that validate draw claims, other than my XBoard and ChessGUI. And these are both OK. So it is not really important if the programmers of these other GUIs were aware of the race condition or not.

Convinces me...

Nobody can have this problem...

Don't know why I bothered to bring it up. Oh yes, xboard had the problem before I pointed it out and you changed the way "offer draw" works, correct?

To be exact, no problems with the race condtion were actually reported. What I reported was that some engines (notably Crafty) did violate protocol by claiming draws that had not materialized yet, in the absence of any race condition.

You then explained the race condition, and that the non-compliant Crafty behavior was a work-around for this race condition on the ICS. I payed proper attention to this: I solved the potential problems with the race condition in local play in the GUI, and indicated an alternative work-around for the ICS problem, which was compliant with existing protocol specs. And I added a paragraph to the protocol specs to point out this work-around.

But, unlike what you seem intent on suggesting here, the problem was _not_ that Crafty fell victim to the race condition. Not then, and not now, in the case with ChessGUI. In both cases it was caught at non-compliant behavior. (Sending 1/2-1/2 before the move that caused a claimable draw). I immediately pointed that out (which you called 'rambling'), but you denied everything, claiming that Crafty never sent 1/2-1/2, and only offer draw (which later turned out to be all falsehood, when people posted the debug file).

And after checking, I rectified my error. This was done 15 years ago in Crafty, and has been working flawlessly ever since. There are several such things that I did so long ago that memory fades to precise details until I dig up the old code. Another famous one was recursive null move in Cray Blitz. Turns out we used it in the version that is now public. I did not remember that as initially it was implemented as one null-move in any path, no more. But details from 20 years ago, after so many versions of CB and now Crafty, tend to fade away until a "refresher course" (reading the source) is done for whatever reason.

With the current xboard I am using, version 4.2.6, my "result" solved the race for all cases. It bit me in self-testing on my cluster before I wrote my own interface. It bit me before we had a cluster here. And I discovered that once I was sure a draw was the correct result, sending the 1/2-1/2 before the move bypassed the race condition. And I had a race condition because I had modified xboard to verify claims since too many engines were ending the match improperly due to bugs. And this has been working for as long as I can remember.

I said it before, and discussion since then has only stressed these points
1) Your knowledge of WB protocol is extremely flakey, but you write nonsense aout it with an attitude like you are expert in it.
2) You don't seem to be aware what Crafty actually prints, until people show you irrefutable proof of it.

And in the mean time I can add to that:
3) You continue to ask the very same question over and over again, even when it was answered every time before. Why ask these questions in the first place, if you don't want to bother reading the answers???

Do you understand the concept "rhetorical question?"

Now stop bugging everyone, and use the protocol according to specs, which is that the sequence offer+move+claim should always grant you a draw-after-the-move, race condition or now race condition, if the claim was correct, in ICS as well as local play. And only come back here when you have a real case (i.e. when you can show us a real-live example where this did not work).

In that vein, why not stop asking a program to do something insane. How is a _human_ going to try to claim a draw by doing that? What human will first click "actions, then offer draw, then make move, then "claim draw" in a game they play. I simply wanted to see the protocol match the way real games are played, according to FIDE rules. This is possible. But the offer/move/claim is certainly not a solution that meets this criterion, and it seemed (and still seems) reasonable to repair it. And as I have said many times, "offer draw" / "move" will work if the GUI understands the problem and kludges it, but it is unnatural to a chessplayer. That has been the point of this discussion. It is unnatural to a chessplayer. It "feels" odd to a chessplayer. And it is not something he would even think about, should he decide to write an engine. He would be looking to answer two questions... (1) what command do I issue to offer a draw, and (2) what command do I issue to claim a draw?

To be well-designed, "it works" is not the only criterion needed. "logical". "natural". "easy" are other things that come to mind.

[bob]

Read back to last year where you said "I am not changing the way the result command is handled..."

Apparently you silently decided to do just that.

First, this is probably just the umptieth false claim you make in this discussion, so I won't even bothe to read back unless you quote or give us the link. [

But the important point is that I can do silently whatever I want to the handling of any command, as long as the behavior of this command continues to conform to the existing specs. (Or does so better than before.) This is implementation, and is no business of the user (engine programmer). They just have to follow specs, and only have the right to complain if I make changes that do violate protocol specs.

OK, I have the last version of the engine.intf document Tim released. Please tell me where in that protocol it explains that I need to send the following:

offer draw
move xyz
1/2-1/2

when I intend to _claim_ a draw by repetition after my move. Here is what my engine.intf states:

]quote][bold]
offer draw
If your engine wants to offer a draw by agreement (as opposed to claiming a draw by rule), it can send the command "offer draw". xboard relays the offer to the user, the ICS, the other engine in Two Machines mode, and the PGN save file as required. In Machine White, Machine Black, or Two Machines mode, the offer is considered valid until your engine has made two more moves. [/bold\[/quote]

Now do you claim your "offer draw" kludge meets the winboard specification? I claim it does not. In fact, it explicitly states above "offer a draw as opposed to claiming a draw by rule". This is the problem I was addressing.

Specs say, and always have been saying, that the engine _must_ send a RESULT command when it detects that the games is _definitely_ over. When you stick to that, it is my job to make sure that engines that stick to that acheive the intended effect, and I can do whatever it takes to make that happen, without informing you.

No argument. But the specs have never said that I must send "offer draw" before the move I want to claim a draw after.

Effects of violating the protocol are not strictly defined in the specs. (It would be stupid to do that, as it would make extension of the protocol in a backward compatible way impossible.) This means you cannot rely on protocol-violating behavior having the same effect in future implementations. But if my new implementation chances the behavior of protocol violations that I discover to be in common use, I have the courtesy to warn people aganst it.

Which suits me just fine. When I have time I will try the just modified version of Crafty and play a million almost instant games to see if there is any remaining issue...

Great. Don't forget to safe the GUI debug files for games where you encounter a GUI bug, so it can be sent to the respective GUI author, and they can fix it. Just coming with the statement "it did not work" after a million games is not helpful.

Rest assured: GUIs do contain bugs, and wil probably always contain bugs. Even the other day one was reported in the WinBoard forum, where a forfeit on time was incorrectly "corrected' to a draw, because the forfeiting side was facing a bare King (while in fact it was facing KRP). This was likely caused by setting up the board for the new position, and incrementing the move number in the wrong order, so that the GameEnd() routine invoked by the clock interrupt was testing an incomplete board. An extremely rare occurrence, but in a million game you might pobably see a few.

Oh yeah? And which version was that? From before you wrote Cray Blitz?

The version I am currently using, before modification.

They have numbers, you know. Look in the "Help -> About" menu. "I am currently using" and "before modifiction" are totally meaningless descriptions. Of course you are using the version that you are currently using. And it is being modified ever since version 0.0.0...

as I mentioned, 4.2.6

1/2-1/2 after a move was problematic because of the race condition. That's why I brought this up the _last_ time this discussion was held.

Currently in ChessGUI, it appears that 1/2-1/2 is irrelevant. As is 1-0 and 0-1, because ChessGUI declares the game over without the program's knowledge, which is fine for normal testing, but not so fine for tuning before playing in a human event.

So apparently, some where in xboard/winboard, when you get the 1/2-1/2, you notice that my opponent has made a move that invalidated the claim, and you then quickly back up to the position prior to his move to see if the 1/2-1/2 is valid? And if so, you end the game.

Exactly. Like I have written about five times before in the two current discussions. Let's hope it sinks in this time.

If not, what?

If not, the game is terminated for reasons of a "false claim", if the user has ticked this option and it is a comp-comp game. Otherwise (of the user prefers it or the opponent is a Human) the old behavior of accepting the claim anyway occurs (and I don't even bother to backup the move and check). This stil terminates the game, but with a draw result for whatever (false) reason the engine gave. If the opponent is an ICS, the old behavior of relaying the 1/2-1/2 as an ICS "draw" command to the ICS occurs.

So you are saying that _no_ GUI will reject a 1/2-1/2, even if it thinks it is incorrect? All I can do here is offer my congratulations for knowing what every gui out there does.

You miss the nuance. _Known_ GUI. Known to me...

"known" generally applies to _everyone_ in that kind of statement.

We at least know that ChessGUI will turn an incorrect draw claim into a loss. It only avoids this problem by ending the game itself before the race condition shows up. But do you _really_ know that the other many GUIs out there, of which there are a bunch, do not check the correctness of a claim to end the game before doing so? I know of one that does. I use it every day on my cluster. I just don't turn bogus claims into losses, I ignore them. But if anybody checks the correctness, and is not aware of the race condition (which it appears most have no idea that such a problem exists) then they are going to have this problem. And the current protocol description does not explicitly tell them what to do to solve the problem, as it doesn't even mention the problem.

The protocol specs are not intended as a "one-page course to GUI programming". But I am not against attaching a small warning for GUI programmers to the description of the RESULT command. How about this:

Note to GUI programmers: RESULT commands that the engine sends immediately after its move might be detected by the GUI only after the opponent has moved, because of communication and scheduling delays, no matter how fast the engine sent it. Any judgement of the validity of RESULT claims based on te "current" board position will have to account for this uncertainty.

Actually a protocol _must_ be a "one page course to GUI programming with respect to the protocol usage." Otherwise one could never write a TCP/IP program that worked. Or a POSIX thread application.