Hello H.G.Muller : upgrading the protocol

[bob]

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.

Sorry, but that is 100% incorrect. Fide _does_ address every sort of race condition that is possible. It is quite specific as to what must be done prior to pressing the button on the clock, and it is quite specific that once you press the button, you are done until your opponent returns the favor. We have an overloaded operator, "move" that says "my move is this and I press the clock as I play this move." We could add a "press" command and then the race conditions evaporate. But this introduces another bit of delay that would affect fast games.

Computers _can_ play according to FIDE rules. Mine does. I chose to do that because I do play in human events here and there and have to play by the rules being used. We now have a slightly different game than real chess we are playing, because it seems appropriate (to some) to modify the rules a bit rather than fixing the protocol to closely follow the rules for the game we are supposed to be playing.

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.

I can think of one quick example to refute this logic. A TD can alter the 50-move draw rule if he chooses, and announces it prior to a tournament. He can say "If you get into a 5 piece ending that is a mate in N, the 50 move rule will be interpreted as the 2*N move rule instead. FIDE did this for a couple of years, in fact, when tablebase research was new. A dedicated box might well claim a draw for 50 moves, when in the given position it might be 200+ moves as in KNNKP (2*N). There is no bug in the engine. There is no bug in the rules. And the game continues just like it should. There are other examples.

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

Not that stupid. I'd rather have Palin as president than what we have today..

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.

[bob]

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.

Strange, it works perfectly for me and has for years.

[bob]

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!

Unfortunately, I am not just looking at this from my engine's perspective. There are lots of engines that don't get this right, and IMHO it is an inconsequential bug that ought not screw up an automated tournament.

[michiguel]

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.

You say that there is no need for modifications of the protocol, but the fact is that you modified it. "offer draw" and 1/2-1/2 is not what it used to be. Now it is much tighter. That is fine, but what I am requesting is that my engine has the ability to know whether the GUI will have this tighter interpretation, that basically changes the behavior of choice.
It used to be that claims were 1/2-1/2, now it is "offer draw". As an engine, I want to know what I am dealing with. Your proposed solution is that I act as I do not know what type of XB protocol I am facing and send commands to cover any possibility. offer draw for the new behavior, 1/2-1/2 for the old one.

Is that much to ask a simple feature that bounce back with accepted telling me that I am dealing with this new behavior?

Then I could send offer draw if accepted with confidence, without the 1/2-1/2 (which is risky).

In other words, the questions is, what is the problem with sending accepted to a feature atomicoffers=1?

Miguel

It has a direct relationship to what I would do. If I know that I am dealing with this tighter interpretation, I would never send 1/2-1/2 for 3 fold rep. or 50 moves rule. Otherwise, I would be extremelly careful in my claims.

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.

[Matthias Gemuh]

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

There are two things which you seem not to value, but the chess community values a lot: backward compatibility with hundreds of engines and support for 100 weak (buggy) engines.
This limits flexibility of GUI programmers.

I don't think WB protocol 3 would help much.
However, a good new and powerful protocol that picks out only reasonable parts of WB and UCI and has new extensions too, would be great. It wouldn't have to be backward compatible to anything and would have to support not only standard chess.

Matthias.

[Matthias Gemuh]

Computers _can_ play according to FIDE rules. Mine does. I chose to do that because I do play in human events here and there and have to play by the rules being used. We now have a slightly different game than real chess we are playing, because it seems appropriate (to some) to modify the rules a bit rather than fixing the protocol to closely follow the rules for the game we are supposed to be playing.

Only a completely new protocol helps, otherwise backward compatibility becomes a real headache inside the GUI.

Matthias.

[bob]

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

There are two things which you seem not to value, but the chess community values a lot: backward compatibility with hundreds of engines and support for 100 weak (buggy) engines.
This limits flexibility of GUI programmers.

I don't think WB protocol 3 would help much.
However, a good new and powerful protocol that picks out only reasonable parts of WB and UCI and has new extensions too, would be great. It wouldn't have to be backward compatible to anything and would have to support not only standard chess.

Matthias.

I don't value backward compatibility when it is not required. protocol version 2 could remain "as is". Protocol version 3 would add the new things. And engine can always use protocol version 2. Just as they can currently stick with only version 1 if they choose.

I started a new thread with a pretty simple solution that is really not going to change anything, everything will continue to work as it currently does, except the GUI eliminates the race condition as we have previously discussed...

As a closing remark, remaining compatible with something that is already broken is not exactly a useful approach.

[bob]

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.

First, everyone should simply stop using UCI if a program can't offer or accept a draw. That violates a rule we use in automated tournaments all the time, that the _program_ has to make all decisions. Pretty stupid if a program can't claim a draw and plays on until it loses, because of a protocol shortcoming.

The only issue I have at the moment is that we are using counter-intuitive commands. What normal person would think "offer draw" is the way to claim a draw by 3-fold repetition?

[bob]

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.

Let me repeat. I have not yet found an engine that will not continue playing after having sent a result that is ignored. They may well exist. But the ones I am currently using have absolutely no problem with my referee ignoring the result and continuing the game. I once had a bug in my referee that screwed up 3-fold repetition and games went on and on, with no problems until I figured out that something was broken.

I have seen engines offer draws due to a very subtle bug. The last game had several consecutive draw scores. When the next game starts, someone forgets to reset that counter, and we see an early draw offer. I have seen the same with resigning. You can't stop an engine from offering a draw, or resigning. But you can ignore the claims that are wrong.

In my current case, it is not the claim that is wrong, but the timing issue that causes a problem.

[bob]

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.

Strange, in that I have played in many tournaments and directed many tournaments, and have never seen a player forfeited for walking out. In fact, this even leads to the current claims of cheating and such when too many trips to the restroom happen. But I have never seen a player forfeited.

My interpretation of the FIDE rules is _not_ open for debate, because the rules are perfectly clear and explicit in every detail.

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.[/quote]

I have played hundreds of games in tournaments. I have _NEVER_, not a single time, played a move that produced a 3-fold repetition, and then told my opponent "I offer you a draw". That is the point here that you don't seem to grasp. There is a difference between "offering" and "claiming". I made a short proposal in a new thread that would solve this ambiguity without any significant changes, and make this process much clearer.

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.