Repetition detection structure.

[hgm]

That is all extremely hypothetical (in practice you will not know the probabilities precisely enough to make such calculations). Furthermore, it does not apply to computers: they won't even remember if you offered a draw or not. For Human vs computer I would not be in favor of having the GUI do anything at all. Just relay the draw offer, even in a draw situation. The engine can always use the RESULT command if he is 100% sure, to claim the draw. For an engine that is advanced enough to use this kind of psychological tactics against the opponent, it should be no problem to correctly determine if it is draw. And if the engine claims wrong, the Human will know it, and doesn't need reassurance from a GUI. In Human-engine games it is the Human who controls the score sheet, not the GUI. For on-line games it is the ICS. This whole issue only exists in automated engine-engine games.

[bob]

I am willing to admit defeat here. This is old, you don't want to get it, so you are never going to get it. I will make one more pass below, you can reply, and I will let that be the last word because this is pointless.
First, how you hijacked the thread to get back on this topic is beyond me, because we started off disagreeing on repetition detection, where you made a statement that was wrong and I gave data to prove it. Then it slowly worked its way back to a different argument...

Excuse me?
It was _you_ who actually 'hijacked' the thread by bringing up this topic again:

I think this is all pretty interesting in light of the discussion we had about winboard_F and its apparently policy of terminating a game when the rules of chess do not allow it. In the case we were discussing, false draw claims, and possibly illegal moves were grounds for terminating the game on the spot.

I don't know what game you think you are playing here by these gros distortions of reality...

Nope. Whose perspective is "definitely over" from? The engine's? How many times do I need to say that the result command should be eliminated?

Zero would be a good number. As it wouldn't make the slightest difference...

It won't break a single engine. If the GUI recognizes that the game is over, the result is not needed. If it doesn't, either the game is not over and the program can continue or lose on time, or else if it is over, the GUI needs to be fixed. Plain and simple logic.

Yes, you want towaste time waiting out the flag. Or, more accurately, you want _others_ that have far less computing power than you to waste the little they have. As _you_ are not even using WinBoard for testing your engine. You only want to spoil it for others. Pretty sick, actually...

Just because _I_ believe something does _not_ make it a fact. Same for you. Do you "get" that concept? An engine can be wrong. It has happened thousands of times in my testing with Arasan versions as I have reported here. It thinks it is losing, wants to resign, but rather than sending a "resign" it would send a result with the 1-0 reversed if it was playing black. Xboard would take that and end the game as a loss for Crafty assuming Arasan sent the result command before Crafty. I modified xboard to not accept result from any program except Crafty to solve this My "cluster GUI" ignores results from other programs, which solves the problem, and doesn't cause those programs any problems whatsoever. Every one I have tried that emits a "result" has continued to play just fine. So perhaps you _don't_ get "definitely over". Because a program can think the game is definitely over and be wrong for any of several reasons.

Then it should be more careful in using commands that might be equivalent to 'resign'. Especially if there are recommended alternatives where it would not run that risk.

One more time:

Eliminate the result command. An engine should not be able to claim a win or draw on its own;

As the result command has none of the properties for which you dislike it, unless you select it to have those properties, and fulfills a useful / necessar function, I have no intension to do so.

keep the current "offer draw" which is a way to offer a draw to the opponent _only_, the GUI takes no other action.

add a "claim draw" which is a way to claim a draw if a program believes the game has ended by rule. The program should be prepared to have the claim ignored if the position is actually not drawn. For example, one could decide to ignore the 50-move rule for certain endings, as FIDE did many years ago, and the GUI would implement that decision and the program should be able to continue.

For one, you are discussing a protocol change now, which is beyond the scope of this discussion. I have no say over the protocol.

Apart from that, I don't see what is to be gained by introducing this 'claim' command next to 'offer'. By FIDE rules the 'claim' command would have to be relayed as a draw offer to the opponent anyway, if there is no basis for a claim.

That is simply incorrect. If I want to claim a draw, I write down my move, I stop the clock, and I call the arbiter/TD over. They will check the validity of my claim using my score sheet and the position on the board, and make a ruling. If they say "this is not a draw, at the first repetition, you could have made an en passant capture, while on the second and third times the position was reached no EP capture was possible." they will then deny my claim and the game continues. The TD may assess a time penalty, or he might not. If I made the claim without writing a move down, because I believe that the position was reached the third time before I make a move or the 50 move rule was reached before I make a move, then the TD will simply start my clock. A claim of draw on my part does _not_ offer a draw to my opponent. No idea where you get that from...

[

So only the case remains where an "offer draw" command would be sent in a legal draw position. You would want to dey the offferer the draw it wants in that case, to penalize it for not using the poper command, perhaps because it did not recognize the lagal draw? How large do you think the probabiity is that this happens, and how large the probability that the opponent in such a case would also not recognize it, and refuse the draw offer?

None of the above would break existing programs. And they would solve existing problems cleanly and clearly.

Of course it would break existing programs. It would break all programs that follow the current protocol, which uses "offer draw" in this situation (because this already works in WinBoard-mediated ICS play.

So get off the "result" hang-up and move on. basic programs with every statement having a line number is a thing of the past. This should be too.

Your suffer from tunnel vision focused on FIDE Chess. There are many games for which WinBoard is not capable to reliably determine game end. It has no choice but trusting the engines for the result, in those games.

[hgm]

A claim of draw on my part does _not_ offer a draw to my opponent. No idea where you get that from...

From FIDE Online:

Article 9: The drawn game
9.1

a) A player wishing to offer a draw shall do so after having made a move on the chessboard and before stopping his clock and starting the opponent`s clock. An offer at any other time during play is still valid, but Article 12.6 must be considered. No conditions can be attached to the offer. In both cases the offer cannot be withdrawn and remains valid until the opponent accepts it, rejects it orally, rejects it by touching a piece with the intention of moving or capturing it, or the game is concluded in some other way.

b) The offer of a draw shall be noted by each player on his scoresheet with a symbol (See Appendix E13).

c) A claim of a draw under 9.2, 9.3 or 10.2 shall be considered to be an offer of a draw.

9.2 The game is drawn, upon a correct claim by the player having the move, when the same position, for at least the third time (not necessarily by a repetition of moves)

a) is about to appear, if he first writes his move on his scoresheet and declares to the arbiter his intention to make this move, or

b) has just appeared, and the player claiming the draw has the move.

Positions as in (a) and (b) are considered the same, if the same player has the move, pieces of the same kind and colour occupy the same squares, and the possible moves of all the pieces of both players are the same. Positions are not the same if a pawn that could have been captured en passant can no longer in this manner be captured or if the right to castle has been changed temporarily or permanently.

9.3 The game is drawn, upon a correct claim by the player having the move, if

a) he writes his move on his scoresheet, and declares to the arbiter his intention to make this move which shall result in the last 50 moves having been made by each player without the movement of any pawn and without any capture, or

b) the last 50 consecutive moves have been made by each player without the movement of any pawn and without any capture.

[bob]

OK, a point for your side there. My (admittedly old) FIDE Laws of Chess has this:

If the claim is found to be incorrect, the arbiter shall add three minutes to the opponent`s remaining time. Additionally, if the claimant has more than two minutes on his clock the arbiter shall deduct half of the claimant`s remaining time up to a maximum of three minutes. If the claimant has more than one minute, but less than two minutes, his remaining time shall be one minute. If the claimant has less than one minute, the arbiter shall make no adjustment to the claimant`s clock. Then the game shall continue and the intended move must be made.

It has no reference to the "if a draw claim is made, it is also considered a draw offer". The FIDE web site has this, which I guess is a change introduced somewhere during the last 30 years or so (my book is old as I said). However, I will add that I have never seen this particular rule applied in any event I have played in with a computer or myself. Including events like the US Open, World Open, and so forth. Probably because if side A is claiming a draw, side B does not and would therefore not react to the pseudo-offer.

But, in light of this rule, I would then say that "offer draw" is good enough. But result still needs to be ignored...

[hgm]

But result still needs to be ignored...

It is clear by now that you have a strong opinion on that, but I just do not not share it. 90% of your case againt the RESULT command is built on properties that it already doesn't have anymore: the latest WinBoard does not allow the engine to determine the score of the game. So as far as I am concerned that kind of RESULT command does no longer exist already. But considerng the actua result only as an explanation / recommandation, it leaves enough functionality to make RESULT an important command that we cannot do without. Engines should have a means to unambiguously terminate a game if they do not know how to play on, to prevent senseless waiting. In the current protocol, RESULT is the only command that does that.

The other 10% of your case is built on the idea that forfeiting because a player walks out on a game would be against FIDE rules. We also disagree on that:

Article 12: The conduct of the players

...

12.5 Players are not allowed to leave the `playing venue` without permission from the arbiter. The playing venue is defined as the playing area, rest rooms, refreshment area, area set aside for smoking and other places as designated by the arbiter.
The player having the move is not allowed to leave the playing area without permission of the arbiter.

...

12.7 Infraction of any part of the Articles 12.1 to 12.6 shall lead to penalties in accordance with Article 13.4.

12.8 Persistent refusal by a player to comply with the Laws of Chess shall be penalised by loss of the game. The arbiter shall decide the score of the opponent.

...

Article 13: The role of the arbiter (see Preface)

...

13.4 The arbiter can apply one or more of the following penalties:

a) warning,

b) increasing the remaining time of the opponent,

c) reducing the remaining time of the offending player,

d) declaring the game to be lost,

e) reducing the points scored in a game by the offending party,

f) increasing the points scored in a game by the opponent to the maximum available for that game,

g) expulsion from the event.

If the protocol contains a command that is defined to be the equivalent of leaving the playing venue, using it before the game is finished is a grave breach of article 12.5, which according to articles 12.7 and 13.4 can be punished by forfeit of the game. So having a "walk out" command to force termination of the game, and awarding abuse of this command by usage of it on a game that is still in progress conforms perfectly to FIDE rules.

But it is the prerogative of the GUI developer to determine which keywords to assign to which actions. And the designers of the protocol have chosen to use RESULT for this purpose. From a formal point of view this is as good as any other keyword, so I am not going to change that.

Note that WinBoard 4.2.7 does ignore the RESULT command completely, in ICS mode. So it can also not be used to claim draws in ICS mode.

WinBoard_x 4.2.7, however, does relay RESULT commands to the server, either as draw offers (for "1/2-1/2") or as resign ("0-1" or "1-0"). This is repairing an obvious bug in WinBoard 4.2.7, where resign commands of the form "0-1 { white resigns }" would never reach the ICS.

In summary:
1) engines should claim draws by "offer draw". Using RESULT will lead to improper operation for ICS play on WinBoard 4.2.7 (where the claim will get lost).

2) Do not use RESULT to send false result claims. In non-ICS play on WinBoard 4.2.7 and WinBoard_x 4.2.7 this will lead to a wrong game result. On WinBoard 4.3.12 and higher you will furthermore run the risk of forfeiting the game (presumably an undesired game resut) if you make false claims through the RESULT command. So if you want to make false claims, do it through the "offer draw" command. (Better, of course, would be to not make false claims ever...)

3) Follow the recommendation in the protocol description under accepting draws, to never use the RESULT command if you still know how to play on, and want to keep the option open to do so.