Hello H.G.Muller : upgrading the protocol

[Matthias Gemuh]

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.

OK, now I understand.

Bob, are you comfortable with this solution ? It at least eliminates race issues and has no time kludges and is compatible with those existing 300 WB engines out there (if GUI terminates games automatically).
Terminating automatically is necessary for those existing engines that have no "offer draw" in the offer-move-claim sequence.

I am comfortable with it. In almost all cases, while claim of A is on its way in, the opponent B will not be fast enough to send a move too early, so the GUI will rarely have to discard that last move.

Matthias.

[Matthias Gemuh]

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

I totally agree with you there.
Trying to force an engine to mimmick every single rule that was created for humans is a big mistake and that will never work.

Matthias.

[Spock]

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

I totally agree with you there.
Trying to force an engine to mimmick every single rule that was created for humans is a big mistake and that will never work.

Matthias.

Agree also

[hgm]

This is why I think implementing things like time penalties for false claims is the wrong way to go. Humans can be tired after a long game of intensive thinking, and make stupid mistake. They deserve to be forgiven. But engines are merciless machines that never tire, so it is only fair if they are treated without mercy as well.

Bob is really alone in pressing for Human-type of handling of false engine claims. And then, if he would get his way, he would present us with a engine that never makes any false claims, so it was all in vain!

[Matthias Gemuh]

This is why I think implementing things like time penalties for false claims is the wrong way to go. Humans can be tired after a long game of intensive thinking, and make stupid mistake. They deserve to be forgiven. But engines are merciless machines that never tire, so it is only fair if they are treated without mercy as well.

Bob is really alone in pressing for Human-type of handling of false engine claims. And then, if he would get his way, he would present us with a engine that never makes any false claims, so it was all in vain!

As you say that the offer-move-claim sequence (that eliminates races) is fully compatible with ICC/FICS, I see no reason to reject it.

Because engines are not guaranteed to be able to continue a game after a false claim, ChessGUI will continue to penalize with immediate losses instead of waiting one hour for engine to lose on time. ChessGUI 0.151a is therefore a "mistake".

Matthias.

[hgm]

I am not aware of any problems on ICC or FICS; in fact this solution was designed around the way Bob told me the race condition was fixed on ICC. (I don't play much on ICS myself.)

XBoard in ICS mode translates both offer draw and 1/2-1/2 to "draw" being sent to the ICS. This command is used both for claiming as well as for offering draws on the ICS. Sending the ICS "draw" command before the drawing move should be interpreted as a claim.

[bob]

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.

I don't see why anyone would want to run without autoflag on. The game has a time constraint. The rules address how a time constraint affects the game. So under what condition would you want to suspend the clock and let the game continue. And if you have such a case, why did you even worry about using a clock during the game?

If a program hangs, it will lose on time. In testing, you can't try to debug every engine you use. If I find one that does poorly (I had discussions with Jon about very fast time controls and older versions of Arasan, for example) I just remove it from the test. My referee will tell me how many games ended on a flag drop. Currently I see zero in a 32,000 game match, with the opponents I use.

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.

You are correct that I am not interested in sub-2000 engines. They have a long way to go to become mature products. But they have so many _other_ bugs that who cares? I have seen mature engines think for an hour in a 40/2hr time control. They can use their time however they want.

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.

And you just broke my testing, completely. My program is not winning those games, my opponent is losing them. In a way that can be safely avoided. I do this every day. You need to study the concept of "redundancy". If you make xboard maintain the state of the game, which it always has in every version I have used, then let it decide when a game ends with the sole exception of resigning/draw offers. Otherwise get rid of the state maintenance code and let the engines do it. I put the state code into my referee because I wanted to see how the two programs competed, not whether one had some strange bug that caused it to report results wrong or something.

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.

I have not tried every engine. But I have yet to find one that won't continue playing after sending a result command, although it would appear that at least 1/2 of the ones I have tried don't even send this.

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.

Hardly. I play about 32,000 games per hour. 750,000 games in a day. Who is going to go thru _that_ PGN after a week of testing and look for such stuff? Why would I want to penalize a program that has a non-chessplaying bug such that when playing black it sends 0-1 when it loses and 1-0 when it wins? I want the real results, regardless of whatever kind of small bug the program might have. In a human game, the result command is completely immaterial anyway. A program can't declare the game won or lost on a whim. The board position determines the final outcome.

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.

I disagree. I originally used the bare protocol xboard had. I sent time lots of additional code for things like obtaining the ratings, names, etc. He later formalized all of this. Then he did protocol version 2. I switched immediately. And as I look around, almost all existing programs have moved to version 2. So why would they not move to versoin 3 if it solves a significant inconsistency dealing with draw claims. And new authors would start at 3.

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

Spoken like a true stone-age software engineer. Don't change what works. Let's use Cobol, Fortran and assembler languages forever. Ever heard of SCTP? And _not_ the chess program misspelled. The network protocol. It addresses significant shortcomings in TCP/IP. No broadcast. It offers new facilities. I can take a UDP-type stream and split off one thread of that into a TCP/IP-like connected stream rather than a UDP-like connectionless link.

There's a ton of room for improvement in xboard protocol. One in particular, the only UCI feature I like in fact, is the ability to give users a way of designing a GUI "knob or button" to influence the engine.

You appear to be one of those "it works, so it doesn't need changing." Law of entropy applies here as well. If it isn't getting better...

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.

<sigh>. If you can't see the flaws, then certainly you won't understand them or see a need to fix 'em... By your logic, we should still be using horses and buggies. They certainly worked. Or we should have stuck with flat-head motors, they certainly worked.

[michiguel]

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.

Is this an undocumented behavior of WB/XB? or is that a suggestion?

I don't see any problems here.

Except that it would be possible to make invalid claims. The engine can claim a draw that happened the previous move. I do not believe it is a good idea.

Miguel

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.

[bob]

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.

There are two types of problems.

(1) can the GUI work around an inconsistency in the specification of the protocol in order to make it work. I have already given an example of where this has happened, and you are quoting it above. No issue there.

(2) Is the protocol logical and easy to understand to someone that plays chess and now wants to write an engine? Here the answer is a resounding no. Humans know how/when to offer draws. And we ought to do it the same way in the protocol, so that it is intuitive to grasp. What human would think "OK, I want to claim a draw after I check my opponent and reach the same position a 3rd time, so I am going to first offer him a draw, and then make the move"???

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.

[/quote]


It would appear that a simple paraphrase of your position is "The engines have to handle all the oddball cases, the GUI will offer no help at all. It might include extra moves. It might not. It might forfeit a program that doesn't claim a draw in the strange way that the protocol work-around requires." The whole discussion was started with the idea of _improving_ the protocol. If you are not interested, fine. I suppsed we might have a 3rd protocol before long, and as always, the users can decide which one they like best. I don't like the idea of proliferation. Neither do I like the idea of the current kludge, just because it works if everyone jumps through the hoops in a counter-intuitive way.

[bob]

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.

OK, now I understand.

Bob, are you comfortable with this solution ? It at least eliminates race issues and has no time kludges and is compatible with those existing 300 WB engines out there (if GUI terminates games automatically).
Terminating automatically is necessary for those existing engines that have no "offer draw" in the offer-move-claim sequence.

I am comfortable with it. In almost all cases, while claim of A is on its way in, the opponent B will not be fast enough to send a move too early, so the GUI will rarely have to discard that last move.

Matthias.

It will work for me. But it is still a kludge that will cause confusion until it is fixed. Most of us that develop engines did, at some point in time, play real chess on a real board, in a real tournament. We ought to follow those rules as closely as possible since they are defined for the game of chess, and we are trying to play this game using a computer program...