Engine authors, beware of false-draw-claim forfeits!

[bob]

The last time I claimed a draw wrongly in a OTB game I was just IGNORED and I was told to play on. Shouldn't a GUI do the same?

Ideally, yes, but it would probably cause one of the engines to crash?

Then the engine that crashes should lose on time, correct? If it can't play by the official rules, that's the preferred outcome, the one that doesn't follow the rules pays the piper...

Agreed.

But I can hardly imagine that you, as a tester, would prefer having to wait upto 40 minutes before forfeiting the game for the offending engine, when it is abundantly clear that it is not going to make a move anymore...

WinBoard_F immediately ends games with the proper result when one of the engines is no longer alive and the pipes to it are broken (i.e. it forfeits the game for that engine.) It does not wait for the flag.

In practice engines won't crash, though. They would just sit idle, not playing any moves anymore in reaction to moves you feed them. So you would have to engage in a needless wait for the flag, while they already unambiguously let you know they are not going to move anymmore.

You say that, but it isn't necessarily so. Who says that when an engine sends 1/2-1/2 that it won't continue to play if it is sent another move? That's an assumption, not a fact. Certainly in the case of Crafty. Crafty doesn't stop playing until the gui sends it a "new" or a "quit" command...

[bob]

What would be the purpose? Basically you want the engines to be able to redefine the protocol, by means of an even more complicated protocol. If engines have the capability to come up with a legal move after their illegal move is rejected, wouldn't it be simpler to require them to send that legal move in the first place? If they want to play on, in stead of ending the game, wouldn't it be simpler to require them not to send the message that they have ended the game, rather than first have them send something that this message should not be taken seriously?

No, he is proposing that the GUI follow the formal FIDE rules of chess. Ever seen a real game with an illegal move played? The person doing that does _not_ lose. In fact, the rules of chess cover this specifically. If the move played is illegal, it must be retracted but that piece must be moved to another square, unless any move of that piece is illegal. There are rules to follow, not rules to make up. While it is unlikely that a program could recover from the above, there is absolutely nothing that says that _some_ program could not, and making a legal scenario impossible doesn't seem to be particularly reasonable.

Just follow the rule book. no more, no less, and this could work. But stop trying to define your own rules and using justifications like "nobody wants to wait 40 minutes..." When I run my big matches, I don't watch all 20,000 games, I don't care if one takes longer than usual because an engine hangs in the search or plays an illegal move or just quits moving for unexplained reasons. The official rules determine the outcome...

[bob]

The engine claims a draw in order to save time and finish the game earlier but the engine may be ready for the situation that the interface is not smart enough to understand that it is a draw so the engine is ready to continue the game if the draw is not accepted.

But WB protocol already defines a command that means exactly that: "offer draw". What could be more simple than using that? A very smart GUI could then indeed grant the draw immediately. A less smart GUI (most likely every GUI in the World...) would not grant the draw, and pass the draw request (and the move) to the opponent, through the "draw" command. A smart opponent would then grant the draw. A less smart opponent would ignore the draw request, play Kh1, and send a 1/2-1/2 { statlemate } message.

No need to add new commands to redefine the meaning of existing commands...

No it doesn't do "exactly that". Offer draw simply tells the opponent you want to offer him a draw, which he can accept or decline. The example Uri gave is a position where the draw is not offered, it is actually claimed as the resulting position is a draw by the FIDE rule book and the arbiter would stop the game at that point regardless of what the opponent says or does.

"offer" means to offer. This is an outright claim, which is a different animal.

[Graham Banks]

But I can hardly imagine that you, as a tester, would prefer having to wait upto 40 minutes before forfeiting the game for the offending engine, when it is abundantly clear that it is not going to make a move anymore...

Agreed - this would be most annoying. Surely there must be a way around that though?

[hgm]

Won't happen unless you adopt something contrary to FIDE rules. Then I won't care because I am not going to support crappy standards (such as UCI) that differ from the rules I have to use in real tournaments... Current crafty handles draw offers, accepting draws, draw claims, perfectly. I don't see that changing

unless?

But WB protocol already defines a command that means exactly that: "offer draw".

Back to reality. Winboard does _NOT_ support that correctly. An engine can claim any result it wants. If you will simply re-read what I wrote above, you won't be off into never-never land. The "result" is not used by winboard when playing on ICC. But in match mode, it is, and it is a bad idea.

Back to your solipsistic 'reality' indeed, where I seem to have written "WinBoard" in stead of "WinBoard protocol". Is it big enough for you to read it now?

What a particular version of WinBoard does or does not implement correctly has no bearing on what the protocol document defines as meaning of the commands. Only the obsolete version of WinBoard that you seem to prefer, and are trying the utmost of your capabilities to prevent or stop any improvement of, has that bug. WinBoard 4.3.13 does support it correctly, of course.

What you wrote seems to have no sense or relevance no matter how often one reads it...

1. This string is the RESULT command: "1/2-1/2 { 3-fold repetition }" (or whatever the reason: 50-move rule, stalemate).

What part of "that is bad" don't you understand? If you send the 1/2-1/2 string today, the game ends. Even if you are losing

The part that said 'not'. In fact I could not even see it... If you send a 1/2-1/2 string today, the game ends. As you requested. And if you were losing, it of course ends with a big fat zero! Today. If you use WinBoard 4.3.13, and did not forget to tick the 'verify claims' option.

Of course, if you fanatically insist using yesterdays software, things that happen today for others, will not happen for you. They won't even happen for you tomorrow. Or over 100 years. Or for as long as you insist remaining in the stone age...

2. This string is "offer draw". Such an offer can be refused if there is no legal draw condition, but it is never penalized to make it.

Eh? I can offer a draw any time I choose, so long as my clock is running when I make the offer (see FIDE rules of chess for clarification). Such an offer can _never_ be refused, unless it comes _after_ I make a move, because when I make a move, that implicitly stops my clock and starts my opponent's clock.

This seems just babble to me. Draw offers can never be refused? Not even if I make one while I am losing? No wonder you prefer the old WinBoard... Get real!

Better solution would be a "hit the clock" command so that I can send anything I want, a move, a draw offer/claim, etc, and my "move" is not completed (by the FIDE rules of chess) until I press the clock button.

Yes, WB protocol is far from optimal, but there are 500+ engines using it, so we will have to make do with it. So what is "better" is not only a matter of taste, but also quite irrelevant. Changing the protocol in an uncompatible way is not an option.

3. Again, "offer draw" does this, in absence of a legal draw condition. If the GUI cannot grant the draw, because there is no legal basis to claim one, it sends "draw" to the opponent to inform it of the offer.

There is a significant difference between "offering a draw" and "claiming a draw". I see no sense in overloading the "offer draw" to behave as above.

Overloading is an unfortunate necessity to stay within the protocol. Furthermore I see no major objections against it. I see the difference between the two as very insignificant. In both cases you request a draw from the first party along the line authorized to grant you one. Sometimes the arbiter (=GUI or ICS) has the power to grant you one, sometimes the decision rests with the opponent. The GUI will know where it lies. So why use two different keywords. That the keyword is "offer" in stead of "request" is perhaps an unlucky choice, but who cares? It is just a protocol.

4. Same as 3. The engine can send "offer draw" at any time, before its move or after its move. It is a separate command.

It should not be able to send anything while the opponent is on move. We have already had interesting problems with this. I make a move, then while it is not my move I flood my opponent with draw offers to slow him down. In human games, it is against the rules to offer a draw while he is on move.

Is it so hard for you to imagine that the GUI would not pass on the information if the timing is not appropriote and it cannot handle the command itself? Or is it unknown to you that engines only communicate with the GUI, and never directly with each other?

5. Exactly. This is why WinBoard_F makes them forfeit the game when they claim a draw through the WinBoard RESULT command in a position that is not a legal draw. Remember that WinBoard protocol defines the RESULT command as what the engine sends when it is not possible or prepared under any circumstances to continue with the game. So when an engine sends it, the GUI has no option but to terminate the game; refusing the RESULT command and waiting for the engine to reconsider its decision, will just hang the game and the tournament.

So what exactly is your problem????

I want to see it done correctly, according to the rules of chess. I want two options. I want to be able to offer a draw, only when it is my move, otherwise the offer is simply ignored; I want to be able to claim a draw, only when it is my move, and the claim is accepted or rejected, but without causing me to lose the game. That is the way FIDE works. If a program can't handle a rejected draw claim, then let it lose on time since it is not playing legal chess.

Well, the "offer draw" command does exactly all that. So everything is exactly as FIDE works. It seems you are making all this fuss only because you think the required command should be worded differently, "claim draw" in stead of "offer draw". It is not only beyond childish to argue aboutmere wording of a command, but there are very good reasons NOT to introduce a new one: it would make engines that use it _incompatible_ with older versions of WinBoard.

If I would add, especially for your benifit, a _new_ command to WinBoard to claim the draw, so that you would not have to use the string "offer draw" to claim a draw after which you are prepared to play on, but could send some other string, say "iamanidiot" to WinBoard in stead, (although others could still use "offer draw" for that purpose), would that make you happy? I can even make it such that the string is ignored unless you enable it in the "feature" command, by saying "iamanidiot=TRUE".

I prefer one of the following, syntactically:

offer draw Re1+

{I am offering a draw, because I think the position is either eventually drawn or it is dead even at the moment. I am also playing the move Re1 whether he accepts the offer or not.}

Re1+ draw

{I am playing the move Re1+ and I claim it is a draw (it is up to the GUI to figure out if it is a 50 move draw, or a repetition, or insufficient material, or a double-flag, or whatever. Again I have to be prepared to play on if the GUI disagrees for whatever reason}

Re1+ draw stop clock or
draw Re1+ stop clock

{I give my move, a draw claim, and tell the GUI my move is complete by giving the stop clock. The GUI doesn't inform my opponent of the move until I "stop the clock" as in FIDE human games.}

To offer a draw, this would become:

re1+ offer draw stop clock

We also need the special case:

draw stop clock

as it is possible that the position before I even move is a repetition or 50-move rule draw and I don't have to make a move to make the claim (again by the FIDE rules).

Yes, very nice. I can see why you are so reluctant to get out of your world of fantasy.

But in the harsh reality what you propose is of course totally out of the question, as it would make engines that use it incompatible with older versions of WinBoard. The way I implement things in WinBoard_F stays within existing protocol, (no matter how obnoxious I think this protocol is...) so that engines would not have to support two different protocols tobe able to run in every WinBoard tournament.

ONLY if your fix is better than what we have. So far it does not seem to be so since it is violating FIDE rules in the way it behaves. For example, in FIDE rules, claiming a draw does not cause me to lose if the arbiter disallows the claim (perhaps I have an incomplete score sheet, or I incorrectly ignored enpassant on the first repetition or whatever... I just have to keep playing.

Your objections solely stem from the incorrect assumption that a 1/2-1/2 message is just a draw claim. But in fact it is defined as expressing the absolute refusal to play on. So tell me, what would the FIDE rules specify if you told the arbiter, after he ordered you to keep playing: "f** you, not n your life", and would leave the tournament hall? I doubt he would be staying up two more hours until your flag finally fell... And even if he was, you cannot expect such leniency from testers that donate their precious CPU time to testing your roque engine.

Any chance this can follow the _real_ rules of chess and not use some ad-hoc policy? If I claim a draw in a tournament, I don't lose if the draw is not upheld. I am forced to play on, sometimes with a time penalty, sometimes not. But I certainly do not lose.

You most certainly lose if you tell the referee you refuse to play on at the same time... And if you did not want to imply that, you should not have used the WinBoard command that is defined to imply that, but the other way to claim a draw (explicitly specify as "offer draw", how silly that might sound).

Thinking doesn't make it so, however. If an engine refuses to play on, let it lose on time, as it would in a FIDE event.

Not a chance any tester would accept or adopt a rule that would waste so much of their CPU time for no reason or benifit at all.[/quote]

Only step in what you are saying that I would advocate is to ELIMINATE the 1/2-1/2, 1-0 and 0-1 strings from the engine to the GUI. If the engine sends 'em, ignore 'em. By the rules of chess, one player can not end the game on his own. I can't end a game on a 50-move claim without someone agreeing. So we do it like that in the engines, or we lose games until we do...

I think you are fighting an uphill battle. No tester is going to use a GUI that forces them to wait out 99% of the games in stead of terminating them immediately when it becomes clear that one of the engines is no longer playing. If your engine will depend on such an interface for proper functioning, they will simply refuse to test it, and not admit it to their tournaments. WBEC doesn't admit any programs that don't send RESULT claims already for a long time. Get real.

Nice attitude. You won't see Crafty drop in rating. You just won't see it running under your GUI, unless you do it reasonably. If you think you can dictate a new and flawed standard, go for it. I won't follow, and I'll bet many others won't either. Do it right and most will be happy to have an improved protocol. But bury your head in the sand, and do it "your way or no way" and it ain't going to happen.

Well, it is your choice if you want Crafty to be considered WB compatible or not. Good luck in convincing the testers that they have to wait out games were one of the engines is not going to move anymore.

[hgm]

But I can hardly imagine that you, as a tester, would prefer having to wait upto 40 minutes before forfeiting the game for the offending engine, when it is abundantly clear that it is not going to make a move anymore...

Agreed - this would be most annoying. Surely there must be a way around that though?

Of course. The way I am using in WinBoard_F:

If an engine tellls you that it will not play on (by sending the RESULT string), while the game was not finished (because the current board position is not a legal draw), declare a forfeit immediately.

I don't see how any sane person could object to such an obviously optimal solution...
But the World is full of surprises!

Would you prefer it to be handled any other way?

[hgm]

No, he is proposing that the GUI follow the formal FIDE rules of chess. Ever seen a real game with an illegal move played? The person doing that does _not_ lose. In fact, the rules of chess cover this specifically. If the move played is illegal, it must be retracted but that piece must be moved to another square, unless any move of that piece is illegal. There are rules to follow, not rules to make up. While it is unlikely that a program could recover from the above, there is absolutely nothing that says that _some_ program could not, and making a legal scenario impossible doesn't seem to be particularly reasonable.

Just follow the rule book. no more, no less, and this could work. But stop trying to define your own rules and using justifications like "nobody wants to wait 40 minutes..." When I run my big matches, I don't watch all 20,000 games, I don't care if one takes longer than usual because an engine hangs in the search or plays an illegal move or just quits moving for unexplained reasons. The official rules determine the outcome...

Is there any need to continue this idiocy?

Is there anyone, besides Bob, who uses a GUI for engine-engine tournaments, and feels the need for giving engines that make illegal moves a 'second chance'????

[Matthias Gemuh]

Can you please explain how a GUI is to determine whether a draw claim is legitimate without knowing the move the engine would draw with ?
Should the GUI assume some random legal move for engine ?

Matthias.

I have already given two alternatives.

1. Send the move, then send the draw claim. The GUI can certainly figure out that even if the opponent makes a move after receiving the move just played, that the draw claim should be enforced, and do so.

2. the move and draw offer/claim can be combined into one string if desired.

ICC handles this with absolutely no problems.

Basic idea:

move Re1+
draw

and if the position is a 3-fold or 50 move draw, the draw is enforced. How hard is that???

Your first answer is exactly what I said I agree with, so your example is 100% correct.
I think our lengthy arguments are solely about some engines and FIDE who feel the move preceding the claim may be skipped.

In ChessGUI, the philosophy is simply: at the moment a draw claim comes in, the GUI has to have received all moves necessary to determine whether to terminate game or not.
A claim that is not preceeded by a move is ignored and if the drawing engine then prematurely terminates, it forfeits.
I will not read FIDE rules about drawing. They were not formulated to cover engine-engine matches with GUI as arbiter.


Matthias.

[hgm]

Very funny to read this.

As reading a little back shows that it was actually me who proposed these two ways. (Having the GUI judge the claim both before and after the last move of the opponent, or placing claim and move in a single line, namely in the result string and the comment field.) And that Bob is still fighting them as hard as he can when he addresses me. But when speaking to others, it is now suddenly his idea... ?

[Uri Blass]

No, he is proposing that the GUI follow the formal FIDE rules of chess. Ever seen a real game with an illegal move played? The person doing that does _not_ lose. In fact, the rules of chess cover this specifically. If the move played is illegal, it must be retracted but that piece must be moved to another square, unless any move of that piece is illegal. There are rules to follow, not rules to make up. While it is unlikely that a program could recover from the above, there is absolutely nothing that says that _some_ program could not, and making a legal scenario impossible doesn't seem to be particularly reasonable.

Just follow the rule book. no more, no less, and this could work. But stop trying to define your own rules and using justifications like "nobody wants to wait 40 minutes..." When I run my big matches, I don't watch all 20,000 games, I don't care if one takes longer than usual because an engine hangs in the search or plays an illegal move or just quits moving for unexplained reasons. The official rules determine the outcome...

Is there any need to continue this idiocy?

Is there anyone, besides Bob, who uses a GUI for engine-engine tournaments, and feels the need for giving engines that make illegal moves a 'second chance'????

I think that the best solution is if engines that are able to use second chance for illegal moves are going to tell it to winboard in the first place and the same for engines that are able to continue after claiming a draw.

No need for different winboard commands.
The default assumption should be that engines do not continue after illegal move or after claiming a draw but there can be exceptions.

Engines can send the interface before the game one of the following or both:
"want to continue after illegal move" or
"want to continue after claiming a draw"

Uri