hgm wrote:bob wrote: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.