bob wrote:
It doesn't really leave them hanging. They are _already_ hanging if they send the claim after the move. I gave a simple example. If they are given a simple guideline "Any claims you want to make during your turn to move, must be sent prior to sending your move. Once you send your move, it will be relayed to the opponent, and any claim made after that may well not be dealt with until after your opponent moves. As a result, the standard behavior for handling your claims for a draw, etc will be as follows: When your claim is received, it will be immediately checked against the current game state. If the claim is valid, the game will end with the appropriate result. If the claim is not valid with the current state, it will be held until you send a move. After the move is made, before it is relayed to your opponent, your claim will again be evaluated to see if it is applicable after your move. If so, the game will immediately end, as it did for the previous case. If the claim is not valid either before or after your move, the claim will be ignored and the game will continue."
That will work. I don't think it is optimal, but it works with no loopholes. What this is doing is to treat the claim / move as if it were either claim - move, or move-claim, depending on which works. I'd rather the protocol be more explicit, but there seems to be little interest in fixing something that is definitely broken. Fixing this would also let a program comply with the official FIDE rules of chess and offer/claim things at the correct time and in a way that an arbiter would be satisfied that the rules have been met. At present, the interface is not doing that.
OK, I admit that your proposal works for future engines.
It works for the existing engines only if GUI terminates 3-fold-rep/50-move games on first occurence (as ChessGUI does).
To fix the future and stay compatible with the past, the "claim before move" sequence would have to be activated by a "feature".
When activated for both engines, 3-fold-rep/50-move games can run till a claim come in.
When activated for only one or no engine, GUI should terminate 3-fold-rep/50-move games on first occurence.
For humans, the feature would be activated.
Matthias.
I considered the method Bob proposes unacceptable, because it requires you to wait for a move after a (false) claim, which might not be coming. And this is totally unnecessary: you could reverse the order, always make the claim after the move, and then test the validity of the claim both in the current position and the previous one, if the last move was the opponent's.
Note that I don't want to drop the RESULT command from the protocol, is just for the reason Wylie states: the protocol is also intended to work for variants that the GUI does not fully understands (3checks, bughouse, ...).
A second reason is that I want to have a protocol with a command that allows the engine to say: "I now walk out on this game". Unlike what Bob says, it is in perfect agreement with FIDE rules to forfeit a player that leaves the tournament premises. It is not just a matter of ving him lose on time, eventually: even if he returs before that, he still has forfeited.
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.
In summary:
1) engines should use 1/2-1/2 to claim draws in positions where you have the move
2) engines should use offer draw before your move to claim draws that only materialize after your move
3) A GUI should, on detecting a draw condition in the current position, certainly terminate the game as draw if there are any pending draw offers.
4) Without pending offers, it should obey the user adjudication instructions, which might be to declare draw, or play on until an engine claims, or play on somwhat longer (e.g. to a 4th repetirion or a 51st move).
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'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. 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. 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".
michiguel wrote:That could happened with old winboard. First is ignored, second is missed by a race condition. The engine needs to know what type of behavior is being used (new or old winboard), but nobody is reading my suggestion of including a feature so the engine will know (I posted it three times).
Not true: old WinBoard (4.2.7) accepts any claim, so if the race condition causes the claim to come in when there is no longer a draw on the board, it still declares a draw. (Or a win, if the engine happened to claim a win by 3-fold repetition, or a win by resigning, etc...)
The engine does not have to know which behavior to expect.
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.
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?
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?
bob wrote:
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...
hgm wrote:
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.
bob wrote:
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.
bob wrote:
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 ?
bob wrote:
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 Gemuh wrote:
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.
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
Matthias Gemuh wrote:
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.
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
That is convenient in certain circumstances, but it does not have to be the default behavior, IMO. The GUI can control it with an option or switch.
bob wrote:
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...
While I agree with this point with respect to "normal" chess and a few popular variants, I think there will probably be new variants in the future (and obscure variants that are not worth implementing into every GUI and TD and such).
So ideally, there would be two ways of running an Engine<->Mediator<->Engine match (where Mediator is a GUI or an automatic TD or even something like ICS).
In one method, the Mediator is a "Smart Mediator"--in other words, knows all the rules and is authoritative about draw offers and claims and over-the-board checkmates/stalemates. The Mediator decides when the game is over, and ignores (or even penalizes) incorrect claims from the engines. This is the most appropriate way of running "normal" chess matches.
But it is also useful to be able to run Engine<->"Dumb Mediator"<->Engine matches, where the mediator doesn't know how to correctly enforce ALL of the rules about draw claims and other end-of-game conditions. The protocol allows this now (for the most part), and we should strive to ensure that future protocol versions still support this. So I think the protocol must allow engines to claim draws and announce game outcomes, which a "Dumb Mediator" can accept as correct (or it can be configured to always believe one engine's version, e.g. crafty's automated test harness).
