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

[Graham Banks]

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?

[Guetti]

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?

Well, if an engine crashes, that is a forfeit.

- Andy

[BubbaTough]

In the Lemming GUI, if either side claims a draw it is awarded either a win or a loss based on a randomly generated number weighted by the rating of the two players, the last score they reported, a trend analysis of the scores over the last 5 moves, and tournament standings (if in tournament mode). Just like in FIDE rules! I suggest that Winboard version g support this interpretation. Should this suggestion be headed, I can email algorithmic specifics to the upcoming author of Winboard version g.

-Sam

p.s. fortunately, since Lemming uses UCI which has no support for draws or draw offers in any form, this feature is rarely invoked.

[Ovyron]

I suggest that Winboard version g support this interpretation. Should this suggestion be headed, I can email algorithmic specifics to the upcoming author of Winboard version g.

Winboard F is called F because it supports Fairy chess, not that there was an E version before it.

[bob]

That means that making the claim before the move will result in a forfeit under any conditions, even when you specify a move in the COMMENT. Due to a protocol violation, rather than a FIDE rules violation.

So engine programmers, beware!

Absolutely same in ChessGUI !

Matthias.

Then you, too, have a broken system. I can claim a draw without making a move of any kind. At least in _real_ chess...

No, my system is not broken !! If some FIDE guys can't define GUI-meaningful rules for lack of programming insight, the GUI programmers must set the standards. It is _real_ chess, not FIDE theory.

Sorry, but the FIDE rules make perfect sense, and work just fine the way they are written. And when a GUI acts like a _real_ arbiter, there are no problems. ICC works perfectly for both computer and human (FIDE) events in fact, if the engine programmers take the time to make it work.

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

[Graham Banks]

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.

[hgm]

OK, in that same tone, "HELLO..." Who gives a damn about some non-standard version of winboard that drastically changes the way things work from the 100 previous releases?

Organizers of engine-engine tournaments, and (rating) testers give a damn. It is at their request that I am building these features in WinBoard. They want a GUI that takes a firm stance against faulty engines, rather than one that lets such engines call the shots (as WinBoard 4.2.7 and earlier does).

You yourself just stated that WinBoard was unacceptable to you, and you had to write your own software for engine-engine tplay. So it must be easy to see even for you how likely it is that this new WinBoard will become the new 'industry standard' in most tournaments that are now played under WinBoard.

My posting was just a friendly warning. Give as many damns as you like. But if you want to be stubborn, be prepared to see Crafty forfeit games, loose a few Elo points and drop a few places on the rating lists.

We have discussed now already two work-arounds for this: the draw offer before the move, and giving the move in the comment field. In fact there even is a third: the GUI can judge the validity of a claim both in the position before and after the last move of the opponent, if the the side making the claim is on move, and accept the claim if it would be valid in either of these positions.

And I explained why that won't work in the general case where a _program_ is allowed to claim an actual result. You can't claim a draw before you repeat the position for the third time. The GUI has no business holding up the game for what has to be an indeterminate amount of time waiting to see if the engine is also going to send a move after the draw offer. And, in fact, the idea is broken. Does that mean while it is my move, I can't simply offer my opponent a draw and see how he response, as the rules of chess specify?

Oh man... Why don't you for once READ what others write, in stead of immediately starting fumigating against your own silly misconceptions? NONE of the three methods did involve waiting of the GUI for what the engine might send. I am sorry if you don't like the tone, but it seems the only way to get through to your imaginary world, and pull you back to reality...

The _right_ way to do this would be the following:

1. A specific string to claim a draw by repetition or by 50-move rule, where the claim is valid _right now_ without my having to make a move. In real chess, I can claim a forced draw before or after making my move.

2. A specific string to claim a draw by repetition or by 50 move rule, where the claim is valid _after_ I make a move, and the move has to be sent with the claim (but not as a comment, since it is a real move and needs to be entered in the PGN correctly).

3. A mechanism to offer draws to my opponent, and accept draw offers from my opponent without having to make a move.

4. A mechanism to offer my opponent a draw, but includes a move. It is now his turn to move, his clock is running, he has a draw offer that is valid until he accepts or makes a move of his own.

5. programs must _not_ be able to tell the GUI the game outcome. Or, at the very least, they can only claim they lost. They can not claim draws or wins. Causes too many problems for non-debugged programs.

When winboard/xboard can do all of that correctly, it will be worth something. As it is, I rely on ICC which does know how to handle draw offers/claims, and which _never_ lets an opponent tell it how the game ended...

Well, WinBoard protocol does support ALL that correctly, so why are you arguing against my implementation of stricter enforcement of the protocol? Do you just want to be difficult?

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

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.

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.

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.

5. Exactly. This is why WinBoard_F makes them forfeit the game when the 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????

This makes no sense to me. Why allow an engine to send a result string if the GUI might or might not use it? In real chess I can't just say "I win" and the game ends. That is not something either player should be able to do. If the GUI handles the clocks, the players should not have to call "flag" either, as there is a timing hole there. The one that should call the flag is the one watching the flag. Since the program might not know that the flag dropped when the opponent took .6 seconds too long, but then the clock increment took it back to positive, the program is unsuited to handling this. Makes no sense for the GUI to tell the program "his clock went below 0.0" either... Because who would not claim the win, making the tit-for-tat messages redundant...

Should I read this as an admission that it starts to dawn on you why WinBoard_F is superior to the WinBoard you prefer, which does allow the engines to claim any result at any time?

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.

Unfortunately Chess engines are not reasonably entities, that you can argue with. They are stupid state machines, and when the get into the state "game finished", no amount of input given to them is going to convince them that this game is not finished. WinBoard protocol does not specify any mechanism to tell an engine to restart a game after a RESULT command has been received; it defines it as the ultimate refusal to play on. If a Human would refuse to play on in the case you describe above, wouldn't you think that the _real_ rules of Chess would in the end declare the game forfeited? Seems to me you have no case...

"Of Course"??? I've worked with Tim Mann for many years adding features to the winboard/xboard protocol. "winboard_f" certainly doesn't conjure up ideas of "the latest winboard version" to me. Does this carry to xboard as well???

Well, WinBoard is open source, and Tim Mann currently doesn't seem to be a very active developer. If you only look at Tim Mann, you will be likely to find yourself in the stone age soon.

That means that making the claim before the move will result in a forfeit under any conditions, even when you specify a move in the COMMENT. Due to a protocol violation, rather than a FIDE rules violation.

Again, that is wrong. If this doesn't follow the FIDE rules of chess, nobody is going to use/accept it. I can _always_ claim a draw without making a move. If you make a move, hit your clock, and I notice that both sides have made at least 50 or more moves without a capture or pawn push, I can claim a draw "right now" without having to make a move or anything. Ditto for repetitions. If the position before my move has occurred twice previously with me on move, I can claim a draw without having to make any move at all, and it ends the game once verified.

We were talking here about the case where no draw condition exists before the move. So the examples you give here are irrelevant. Draw claims in these situations are accepted by WinBoard_F without any problems. The whole issue is what the GUI should do if an engine unconditionally refuses to play on (by sending the 1/2-1/2 command) in a position 3 moves after a capture, that has never been on the board before, and isn't a stalemate. If you would deem such a claim to "follow FIDE rules", I think it is you who are wrong!

I'm not going to beware, I am not going to use it if it doesn't actually match the official FIDE rules. And assuming the "feature" command doesn't get broken, I would probably modify Crafty to refuse to play if the GUI behaves as you are describing, since it is broken.

Well, as I am an engine programmer next to being a GUI programmer, I always enjoy seeing competitors drop in rating...

[hgm]

Hm. Should I care about Winboard_F? I don't run Windows. I run Unix.
I use xboard. Latest version is 4.2.7.

By the way, from where comes this "false draw claim = forfeit" rule? FIDE? 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?

The problem is that in WB protocol, sending the RESULT string is not only a draw claim, but a draw claim + unconditional refusal to play on:

RESULT {COMMENT}
When your engine detects that the game has ended by rule, your engine must output a line of the form "RESULT {comment}" (without the quotes), where RESULT is a PGN result code (1-0, 0-1, or 1/2-1/2), and comment is the reason. Here "by rule" means that the game is definitely over because of what happened on the board. In normal chess, this includes checkmate, stalemate, triple repetition, the 50 move rule, or insufficient material; it does not include loss on time or the like. Examples:

I don't see how else to interpret the "definitely over". Even if a clever lawyer could argue differently, we are faced with the practical problem that virtually every engine that exists will in practice not play on after sending the draw claim, so waiting until it forfeits on time after sending it more moves would just be a gigantic waste of precious CPU time. And I think we all would agree that "False draw claim + refusal to play on = forfeit" is a quite normal rule, that FIDE also applies.

To claim a draw that might be refused, (such as in acceptig a draw offer, as due to sync problems the offer might have been withdrawn) WB protocol explicitly specifies the command "offer draw" should be used.

[hgm]

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.