Hello H.G.Muller : upgrading the protocol

[bob]

No, but it shows an incredibly poor design. One doesn't use "time" to try to synchronize two parallel events. It never works.

Please, clarify.
The events of one engine don't even know that a second engine exists.
What has that got to do with synchronizing ?
What is the better design for Windows ?

The problem is the draw claim. If it is made _before_ a move is made, it should appear _before_ the move is sent. If it is made for the position _after_ the move is made, it should appear _after_ the move is sent. But that leaves the two-message race condition I have repeatedly shown. You get the move, you send it to the opponent, and you get a move back from him before you even see my draw claim. My process could be pre-empted. You might check for input on both descriptors and check my opponent's first as it is a lower number. Any number of events can cause you to read from two different descriptors and get data that is not in the order it was written with respect to time.

The better design is to combine the offer/move, claim, or claim after move so that there is one command that does both, if one wants to do both. Not two commands that are separated in time that can stretch out further than one would expect.

Then "it shows an incredibly poor design" is simply wrong for ChessGUI that terminates games without allowing any races.

Say that if it permits playing beyond "first occurence" without better sync.

Matthias.

I like your idea of simply ending a game after you verify that the 50 move rule, or three-fold-repetition draw has actually happened. But turning the draw claim into a loss is not so hot...

In my referee, I ignore the results because more than one program gets that wrong anyway. But I don't want to penalize them for that because I care about the real game result for my testing, not the fact that someone screws up sending a wrong result. I also ignore draw stuff completely as well, since so many can't do that properly and I didn't want to write code to handle all the broken cases I have seen. I just let the games play out unless a real drawing condition on the board is recognized.

[bob]

I find it pointless to have the GUI know whether or not the game is a draw or not, and then even bother with the result from a program. If the GUI knows, why does it need the program to tell it something?

If the GUI doesn't know, then it must wait only for both engines to agree on a draw, right ?
In that case, the protocol would have to stop mentioning "on the board" in relation with pending draws.

Matthias.

In this day and time, a GUI ought to know. What kind of a tournament would it be if the TD didn't understand the game and had to depend on the two players to agree on who won and then tell him? That'd be an event to watch...

If the GUI should know and you ask "why does it need the program to tell it something? ", then 3-fold-rep/50-move games would be terminated on first occurence (as ChessGUI does). But what about FIDE ? Aren't the games expected (by FIDE) to continue ?

Matthias.

Now we come full circle. The current drawing mechanism (offer draw, move) violates FIDE rules anyway. So it seems to be moot. My intent in Crafty is to follow FIDE rules with respect to offering draws and such. The "result" stuff is only used in xboard mode and is never seen when I play in a human event.

For comp vs comp games, ending the game when a drawing condition is satisfied seems to be OK so far as I am concerned. If you talk about playing in human events, then things are different. I'd hoped we might be able to correct the shortcomings of the xboard protocol and make things match up better, but it seems that is not going to happen.

[hgm]

To make things clear, I was referring to "old winboard behavior" as GUIs not treating offer draw atomically, not what it does with 1/2-1/2 {comment}. Apparently, some GUIs decide to punish wrong claims (which could be a race condition) with a forfeit. I do not believe that is entirely incorrect for an older GUI. Is it?. That won't be a problem if they adapted the atomic offer behavior.

I am not aware of any GUIs that punished false draw claims before WinBoard started doing that. I only started doing that after I fixed WinBoard such that I could do it reliably (i.e. keeping track of e.p and castling rights). But on some of the earlier 4.3 versions (4.3.12 and earlier?) it might not have been entirely reliable, because of the race condition. I had not realized the existence of this race condition untill Bob pointed it out to me; I then took immediate action to fix it through the offer draw pre-claiming mechanism.

In other words, can you say that an older GUI was non-compliant at the time it was released if it forfeited an engine for a wrong claim?

I would not go so far to say it was non-compliant, as long as it always did it correctly. Without recognizing the offer draw as a claim, the race condition can still be handled with a guarantee for no unjust rulings by accepting claims of the stm based on the previous position, as well as the current.

As a protocol, this is inferior, because it is exploitable.

Look at ChessGUI, If I undestand correctly, it is ignoring draw offers (and their associated claims, tell me if I am wrong MG), and then forfeit wrong "1/2-1/2". Any engine can lose a game doing everything as you suggest if a race conditions happens. Can this be clarified?

Indeed. To not run the risk of making an unjust false-claim ruling in the face of the race condition, it is essential that the GUI judges the claim in the context of both the current and the previos opponent-to-move position.

This solves the problem in local mode, and thus for the GUI in any mode, as in ICS mode the GUI shoud nevr make any calls, and leave them to the ICS. But it does not solve the problem for engines in ICS mode: they will still have to make an advance draw claim to pre-empt the race condition on the ICS. To this end they have to send offer draw before their move. If they do that, the ICS wll terminate the game even before the engine gets a chance to send a 1/2-1/2 draw claim. To have identical behavior in ICS and local mode, I made the GUI behave the same way in local mode.

[hgm]

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 have seen that happen so often that it was a problem. Do you think I programmed XBoard to catch false claims just beause I had nothing better to do? Try running engines in the rating range 1300-1600, and they will do this all the time, to the point where you cannot even do a single Nunn match without getting stick if you don't play with autoCallFlag. And there can be very valid reasos to not want to play with autoCallFlag.

Your view of compute Chess seems to be limited to a handful of engines from the stratosphere. But that is really a very limited view, and you have completely lost touch with he problem most of us are facing.

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.

Well, you can say it just as often as Miguel can propose protocol changes. But it is not going to happen. If I would play Arasan 9, it would not win any of these claims. They would all be flagged as false claims, and result in Arasan forfeiting.

So just like the race condition, this problem is already solved in a way that I consider satisfactory. I strongly prefer to have false claims clearly flagged as forfeits in the {REASON} message that will appear in the PGN, rather than as time losses. Otherwise the engine author would have a very hard time figuring out what the exact problem was, without looking at the debug file. And debug files are not always availabe.

By catching falls claims, engine authors will be made aware of bugs in their engine, and fix them.

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.

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.

But new protocol will solve nothing for anybody. As no one is using that new protocol now. So all problems that exist now, will continue to exists after you define protocol v3. Problems cannot be fixed by defining protocols. Programs will have to bechanged to fix the problems. And if the programs are changed, they might as well be changed to solve the problems using protocol v2.

... 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".

If you want a protocol that is intuitive, half of WB protocol should be thrown out. "hard" is not exactly intuitive speak for "ponder on", and "post" is not exactly intuitive speak for "show PV info". I am not going to supply synonyms for every WB command just because the existing commands happen to be not very intuitive.

There is nothing that may or may not work, other than the obvously unavoidable issue that anything specified in a protocol might not work if it is not properly implemented. If people stick to the current protocol definition, which is very explicit and clear on this subject, everything will work.

There are no issues with the protocol. The only issues are with implementations. Complain to the implementors, and have them fix it.

[hgm]

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 think this does not solve the problem, as Bob's example with the QUEEN shows.
You offer a draw, loosely hang your claim behind your move, play your Queen move (and before your claim shows up), opponent hurriedly rejects the draw offer and captures the Queen, then the claim shows up (although you loosely glued it to the Queen move).
It don't quite understand how you prevent those opponent activities.

Matthias.

In this case the claim comes in while the move already went back to the claimer. The GUI will see that the current position is not a 50-move draw (as a Q was just captured). But it will now also look to the position before the capture, (because the last move was an opponent move), and it will see that the 50-move counter was at 100 there. So it assumes that the race condition allowed the last opponent move to pre-empt the claim, and that teh claim really pertained to the previous position. So it grants the draw.

I don't see any problems here.

I guess I should strip the last move off the game in such a case, so it won't appear in the PGN. I don't do that yet. I will make sure the next XBoard release fixes that.

More tricky is how to handle the opponent: the logical way would be to undo its last move before sending it the result 1/2-1/2 {draw by 50-move rule} command. But many engines do not implement undo, so this really would be asking for trouble. It would only be important for engines that do learning, and are not satisfied by only knowing the result and reason, but would analyze the moves as well. They might frown upon discovering a 50-move game-end immediately after a capture. Well, I don't know if there are such engines. But even if there are, I consider putting the burden on them to realize that their last move must have in fact post-dated the opponent's game-terminating claim the least of all evils. Let them undo that move themselves, if they feel there is a need for it.

[Matthias Gemuh]

My reasons for terminating 3-fold-rep/50-move-rule games automatically:
In typical ChessGUI tournaments, there are WB and UCI engines. UCI engines cannot offer/claim draws. ChessGUI must automatically terminate UCI-UCI games.
Should ChessGUI depend on engine claims in WB-WB games of same tournament ?
What of WB-UCI games ? Should WB engine be allowed/expected to claim while UCI opponent can't ?
Therefore GUI should automatically terminate all comp-comp games.
Note that polyglot engines cannot offer/claim draws either, so Winboard/Xboard should automatically terminate all comp-comp games.
Human-operated games (WCCC, etc.) are a different story and ChessGUI shall consider them only when race issues are solved.

[Spock]

I agree with your current approach of terminating 3-fold-rep/50-move-rule games automatically for the reasons you have outlined

[hgm]

Well I'm happy in automated computer vs computer engine matches that the GUI terminates the game on first occurrence of 3-fold-rep/50-move rule. Yes that may not be strictly FIDE compliant, but is it actually possible to get engines and GUIs to perfectly emulate human behaviour that occurs face-to-face and in spoken conversation with the opponent and arbiter ? Maybe, I'm not convinced, but in this one instance I'm happy with the compromise. Now I'm going to get shot down in flames... Of course in a manually operated game say in WCCC, the GUI can't intervene like that

I only attach value to FIDE rules when they are useful. Computers have other issues than Humans, and the FIDE rules are designed for Humans. They don't address things like race conditions, but they address Human fallibility in having elaborate rules to handle false claiming.

For computers there is no need to make false claims. If they do their authors should be made aware of it as quickly and expliitly as possible, so they can fix it, and no more false claims wil be made ever. Any other course of action would be counter-productive. That rules for handling Humans optimally are different is understandable and desirable, but applying those rules to computers is plain stupid. (Funny typo: here I accidentally typed "palin stupid" originally. )

Note that WinBoard / XBoard only does adjudications in local engine-engine games: in ICS games the ICS is in control, and in local Human-engine games the user has the ultamate power for deciding if he wants to believe the engine or not. In Engine-engine games WinBoard allows the user to spcify after how many reversible moves or repetitions he wants to adjudicate the game. This can be set to "never", always waiting for an engine claim (invariably leading to automatic testing getting stuck) to first repetition (useful when you know that the engines play reproducibly, so that going through the same move loop a second time is pointless.) By setting the rule moves to 50 and repeats to 3, you would force the engine to claim on the first possibility (WBEC rules). I usually set them to 51 and 4, respectively, to test if the engine proprly claims, but not waste too much time if it doesn't.

[hgm]

But I don't want to penalize them for that because I care about the real game result for my testing, not the fact that someone screws up sending a wrong result.

The point is that having them time out when they stop playing after a false claim is just as much a distortion of the "real game result". Therefore I want to see the false claims flagged explicitly in the PGN, so that I can correct them to this "real result". There might have ben a spurious draw claim by an enin that was heavily winning.

[hgm]

Now we come full circle. The current drawing mechanism (offer draw, move) violates FIDE rules anyway.

This is where we disagree. Your interpretation of the protocol violates your interpretation of the FIDE rules, but that is all. Proposed fix: change your interpretation to a proper one.

RESULT {REASON}
expresses a refusal of the engine to play on. Forfeiting a player that walks out on a game is normal FIDE practice.

move MOVE
represents both writing the MOVE on the score sheet and pressing the clock. To make sure the referee is present to receive your claim between these two events, you have to call him to the board in advance. And the designated command for that is "offer draw".

It is all exactly as in Human play.

So it seems to be moot. My intent in Crafty is to follow FIDE rules with respect to offering draws and such. The "result" stuff is only used in xboard mode and is never seen when I play in a human event.

Well, as mentioned, XBoard does none of the adjudication / claim verification stuff when one of the players is a Human (or an operator). nd it only does it in two-machines mode when the TD requests it, with the parameters the TD specified w.r.t. number of reps, etc. But be prepared that most TDs will request 50 moves and 3 reps. WBEC has been doing this for a long time (even putting the burdon on the engine to do it, disqualifying and kicking out engines that failed to comply).

For comp vs comp games, ending the game when a drawing condition is satisfied seems to be OK so far as I am concerned. If you talk about playing in human events, then things are different. I'd hoped we might be able to correct the shortcomings of the xboard protocol and make things match up better, but it seems that is not going to happen.

It has happened long ago. There are no known shortcommings in WB protocol. The only problems are that not all programs implement the protocol correctly.