Repetition detection structure.

[bob]

For clarity's sake, here is what I have been saying, repeatedly.

1. Any GUI should follow the FIDE rules of chess.

2. FIDE has clearly defined rules, with some exceptions in how they are implemented when it comes to specific issues with players. Blind or handicapped players for example. Or computer players.

3. None of the FIDE rules of chess are violated by the exceptions. You still offer/claim draws in the same way. Etc. But if you are blind, or can not speak, you can do it thru a 3rd party. Ditto for moving pieces and the like.

Why you can't grasp this stuff is beyond me...

My opinion.
1)Every gui should follow Fide rules in games agaisnt humans.
Some modifications that do not change much are needed for
comp-comp games.

The modifications are about situations that do not happen often(and should never happen assuming the program has no bugs) like wrong draw claims or illegal moves.

There are 2 reasons for that
1)saving computer time because continue the game in this case may cause loss on time in significant part of the cases.
2)Helping the programmers to find bugs in their program.

reason 1 is not very important because I believe programs do not make wrong draw claims in more than 99% of the games.

I have seen quite a few programs that handle repetitions incorrectly. Many count 2-fold repetitions as draws and then announce this claim to the opponent. I don't see a problem with it at all, as in the case of ICC, it is ignored just like it would be in a human vs computer game.

I have seen more than one program incorrectly implement the 50 move draw rule. Just because you have made 50 reversible moves, and I just played my 50th reversible move, you can't _always_ claim a draw. Because my 50th move might have checkmated you and the checkmate rule is honored before the 50-move draw rule.

No argument from me there. Certainly nothing wrong with a GUI informing me that a draw claim was invalid. But I don't see any justification for ending the game when such a claim is made... FIDE certainly does not do so, and I have personally witnessed several times over the years when incorrect claims were made. Including some where I was serving as TD. And I simply said "this is not a draw by repetition, because of "....." and then I told them to continue the game and I started the clock.

reason 2 is the important reason.
If a program makes draw claim than it is better for the programmer to know about it only based on the pgn(the programmer may get pgn without logfile).


If the program makes the wrong claim and continue the game
then the programmer cannot know based on the pgn that it made a draw claim.

No argument from me there. Certainly nothing wrong with a GUI informing me that a draw claim was invalid. But I don't see any justification for ending the game when such a claim is made... FIDE certainly does not do so, and I have personally witnessed several times over the years when incorrect claims were made. Including some where I was serving as TD. And I simply said "this is not a draw by repetition, because of "....." and then I told them to continue the game and I started the clock.

I think that most programmers are going to agree that they prefer to lose the game so they know about the bug and not to avoid losing when they get no information about the bug.

Uri

The question is, are we trying to debug their program, or are we trying to determine which program is better, A or B? Do I want A to win a lost or drawn position because B made the claim improperly???

[Uri Blass]

For clarity's sake, here is what I have been saying, repeatedly.

1. Any GUI should follow the FIDE rules of chess.

2. FIDE has clearly defined rules, with some exceptions in how they are implemented when it comes to specific issues with players. Blind or handicapped players for example. Or computer players.

3. None of the FIDE rules of chess are violated by the exceptions. You still offer/claim draws in the same way. Etc. But if you are blind, or can not speak, you can do it thru a 3rd party. Ditto for moving pieces and the like.

Why you can't grasp this stuff is beyond me...

My opinion.
1)Every gui should follow Fide rules in games agaisnt humans.
Some modifications that do not change much are needed for
comp-comp games.

The modifications are about situations that do not happen often(and should never happen assuming the program has no bugs) like wrong draw claims or illegal moves.

There are 2 reasons for that
1)saving computer time because continue the game in this case may cause loss on time in significant part of the cases.
2)Helping the programmers to find bugs in their program.

reason 1 is not very important because I believe programs do not make wrong draw claims in more than 99% of the games.

I have seen quite a few programs that handle repetitions incorrectly. Many count 2-fold repetitions as draws and then announce this claim to the opponent. I don't see a problem with it at all, as in the case of ICC, it is ignored just like it would be in a human vs computer game.

I have seen more than one program incorrectly implement the 50 move draw rule. Just because you have made 50 reversible moves, and I just played my 50th reversible move, you can't _always_ claim a draw. Because my 50th move might have checkmated you and the checkmate rule is honored before the 50-move draw rule.

No argument from me there. Certainly nothing wrong with a GUI informing me that a draw claim was invalid. But I don't see any justification for ending the game when such a claim is made... FIDE certainly does not do so, and I have personally witnessed several times over the years when incorrect claims were made. Including some where I was serving as TD. And I simply said "this is not a draw by repetition, because of "....." and then I told them to continue the game and I started the clock.

reason 2 is the important reason.
If a program makes draw claim than it is better for the programmer to know about it only based on the pgn(the programmer may get pgn without logfile).


If the program makes the wrong claim and continue the game
then the programmer cannot know based on the pgn that it made a draw claim.

No argument from me there. Certainly nothing wrong with a GUI informing me that a draw claim was invalid. But I don't see any justification for ending the game when such a claim is made... FIDE certainly does not do so, and I have personally witnessed several times over the years when incorrect claims were made. Including some where I was serving as TD. And I simply said "this is not a draw by repetition, because of "....." and then I told them to continue the game and I started the clock.

I think that most programmers are going to agree that they prefer to lose the game so they know about the bug and not to avoid losing when they get no information about the bug.

Uri

The question is, are we trying to debug their program, or are we trying to determine which program is better, A or B? Do I want A to win a lost or drawn position because B made the claim improperly???

Some comments:
1)The interface of winboard today including the old interface finish the game after a draw claim so the meaning of claiming a draw under the winboard interface is refusing to continue(this is not something that H.G.Muller decided).

The only solution that can make all happy is to add another winboard command to claim draw without refusing to continue the game.

Today there is no option under the winboard protocol to claim draw without refusing to continue the game and if you change winboard to continue the game after wrong draw claim then it mean changing the rules of the interface.

If you want to add another command to the winboard protocol to claim a draw without refusing to continue there is no problem with it.

2)The option to continue the game without changing the time on the clocks is also against the fide rules so I do not see how this solution is better than the solution of finishing the game as a loss for the side that made wrong claim if we talk about being consistent with the fide rules.

3)I think that helping the programmers to debug their program is more important for most programmers and this is the reason that I guess most programmers are not going to support the command of claiming a draw without refusing to continue the game.

Uri

[hgm]

Why you can't grasp this stuff is beyond me...

Not surprising, as you made it pretty obvious that about anything we are discussing here is beyond you. But unfortunately there is no way to say it any simpler than this:

If you send a signal or perform an action that is defined to mean resignation, you will lose the game instantly.

If you think that is in violation of FIDE rules.. Well, then think again! It might help eventually. And now stop wasting our time, please...

[hgm]

The only solution that can make all happy is to add another winboard command to claim draw without refusing to continue the game.

But this command does exist: "offer draw".

The only thing that can be said against it is that it does not make a distinction between claiming a draw (an offer that cannot be refused), or merely proposing one to your opponent (which he can refuse). But on an ICS this distinction is not made either, and in both cases you have to send "draw". So for ICS play there is nothing to be gained from differentiating these commands.

The entity acting as final arbiter (GUI or ICS, depending on the situation) can always figure out what is meant (i.e. if you request the draw from the arbiter or from the opponent). Differentiating the commands for claiming and proposing a draw can only serve to create the possibility for illegal use of these commands, inflicting the problem on yourself how to handle the illegal uses. In the best case you would have added new commands only to be able to then ignore them. A total waste of effort.

Of course, when I would be in charge of defining a WB protocol version 3, just to please Bob I could add a new command "claim draw" especially for claiming a draw in situations where a draw cannot be claimed by rule, which will then _not_ be transmitted as a draw offer to the opponent. For compatibility with earlier protool versions an engine would have to enable this through the features comand, by

feature PleaseDoNotTransmitIllegalDrawClaimsAsDrawOffersToTheOpponent=1

With this option "offer draw" would then never be interpreted by the GUI as a draw claim, and simply passed to the opponent even in a 50-move or 3-fold-rep sitution.

Of course the engine should test if the feature is actually accepted, by the response

accepted PleaseDoNotTransmitIllegalDrawClaimsAsDrawOffersToTheOpponent

or

rejected PleaseDoNotTransmitIllegalDrawClaimsAsDrawOffersToTheOpponent

from the GUI, and take appropriate action when the feature is rejected.

[bob]

For clarity's sake, here is what I have been saying, repeatedly.

1. Any GUI should follow the FIDE rules of chess.

2. FIDE has clearly defined rules, with some exceptions in how they are implemented when it comes to specific issues with players. Blind or handicapped players for example. Or computer players.

3. None of the FIDE rules of chess are violated by the exceptions. You still offer/claim draws in the same way. Etc. But if you are blind, or can not speak, you can do it thru a 3rd party. Ditto for moving pieces and the like.

Why you can't grasp this stuff is beyond me...

My opinion.
1)Every gui should follow Fide rules in games agaisnt humans.
Some modifications that do not change much are needed for
comp-comp games.

The modifications are about situations that do not happen often(and should never happen assuming the program has no bugs) like wrong draw claims or illegal moves.

There are 2 reasons for that
1)saving computer time because continue the game in this case may cause loss on time in significant part of the cases.
2)Helping the programmers to find bugs in their program.

reason 1 is not very important because I believe programs do not make wrong draw claims in more than 99% of the games.

I have seen quite a few programs that handle repetitions incorrectly. Many count 2-fold repetitions as draws and then announce this claim to the opponent. I don't see a problem with it at all, as in the case of ICC, it is ignored just like it would be in a human vs computer game.

I have seen more than one program incorrectly implement the 50 move draw rule. Just because you have made 50 reversible moves, and I just played my 50th reversible move, you can't _always_ claim a draw. Because my 50th move might have checkmated you and the checkmate rule is honored before the 50-move draw rule.

No argument from me there. Certainly nothing wrong with a GUI informing me that a draw claim was invalid. But I don't see any justification for ending the game when such a claim is made... FIDE certainly does not do so, and I have personally witnessed several times over the years when incorrect claims were made. Including some where I was serving as TD. And I simply said "this is not a draw by repetition, because of "....." and then I told them to continue the game and I started the clock.

reason 2 is the important reason.
If a program makes draw claim than it is better for the programmer to know about it only based on the pgn(the programmer may get pgn without logfile).


If the program makes the wrong claim and continue the game
then the programmer cannot know based on the pgn that it made a draw claim.

No argument from me there. Certainly nothing wrong with a GUI informing me that a draw claim was invalid. But I don't see any justification for ending the game when such a claim is made... FIDE certainly does not do so, and I have personally witnessed several times over the years when incorrect claims were made. Including some where I was serving as TD. And I simply said "this is not a draw by repetition, because of "....." and then I told them to continue the game and I started the clock.

I think that most programmers are going to agree that they prefer to lose the game so they know about the bug and not to avoid losing when they get no information about the bug.

Uri

The question is, are we trying to debug their program, or are we trying to determine which program is better, A or B? Do I want A to win a lost or drawn position because B made the claim improperly???

Some comments:
1)The interface of winboard today including the old interface finish the game after a draw claim so the meaning of claiming a draw under the winboard interface is refusing to continue(this is not something that H.G.Muller decided).

I realize that. But he has proposed yet another issue, where a draw claim now is not ignored, it will cause that engine to forfeit. Which is even worse. I will also add that winboard/xboard does terminate the game properly when playing on ICC.

The only solution that can make all happy is to add another winboard command to claim draw without refusing to continue the game.

Today there is no option under the winboard protocol to claim draw without refusing to continue the game and if you change winboard to continue the game after wrong draw claim then it mean changing the rules of the interface.

I pointed that out previously and specifically said that I did not like giving an engine the option of ending the game except if that engine chooses to lose by resigning. I've seen too many bugs where engines end the game improperly.

If you want to add another command to the winboard protocol to claim a draw without refusing to continue there is no problem with it.

2)The option to continue the game without changing the time on the clocks is also against the fide rules so I do not see how this solution is better than the solution of finishing the game as a loss for the side that made wrong claim if we talk about being consistent with the fide rules.

I don't know what you mean about continuing the game without changing the time on the clocks. Typically the TD will not change the clocks, but he can penalize a player if he chooses. And nothing prevents winboard/xboard from doing this since it keeps up with the time...

3)I think that helping the programmers to debug their program is more important for most programmers and this is the reason that I guess most programmers are not going to support the command of claiming a draw without refusing to continue the game.

Uri

[bob]

The only solution that can make all happy is to add another winboard command to claim draw without refusing to continue the game.

But this command does exist: "offer draw".

The only thing that can be said against it is that it does not make a distinction between claiming a draw (an offer that cannot be refused), or merely proposing one to your opponent (which he can refuse). But on an ICS this distinction is not made either, and in both cases you have to send "draw". So for ICS play there is nothing to be gained from differentiating these commands.

Sorry, but that is wrong, once agan. If you offer a draw on ICC, and the game is drawn by any valid rule, the game ends immediately, and the opponent gets no say-so. This means repetition, 50-move draws will completely and instantly end the game. Otherwise the draw offer is sent to the opponent.

Always been this way. You just send "draw" (not offer draw) to the server, and if it is a legit draw, the game ends right then. Otherwise the draw command is sent to the opponent which effectively offers him the opportunity to accept the draw and still end the game...

The entity acting as final arbiter (GUI or ICS, depending on the situation) can always figure out what is meant (i.e. if you request the draw from the arbiter or from the opponent). Differentiating the commands for claiming and proposing a draw can only serve to create the possibility for illegal use of these commands, inflicting the problem on yourself how to handle the illegal uses. In the best case you would have added new commands only to be able to then ignore them. A total waste of effort.

Of course, when I would be in charge of defining a WB protocol version 3, just to please Bob I could add a new command "claim draw" especially for claiming a draw in situations where a draw cannot be claimed by rule, which will then _not_ be transmitted as a draw offer to the opponent. For compatibility with earlier protool versions an engine would have to enable this through the features comand, by

feature PleaseDoNotTransmitIllegalDrawClaimsAsDrawOffersToTheOpponent=1

With this option "offer draw" would then never be interpreted by the GUI as a draw claim, and simply passed to the opponent even in a 50-move or 3-fold-rep sitution.

Of course the engine should test if the feature is actually accepted, by the response

accepted PleaseDoNotTransmitIllegalDrawClaimsAsDrawOffersToTheOpponent

or

rejected PleaseDoNotTransmitIllegalDrawClaimsAsDrawOffersToTheOpponent

from the GUI, and take appropriate action when the feature is rejected.

[hgm]

Sorry, but that is wrong, once agan. If you offer a draw on ICC, and the game is drawn by any valid rule, the game ends immediately, and the opponent gets no say-so. This means repetition, 50-move draws will completely and instantly end the game. Otherwise the draw offer is sent to the opponent.

Since this is _exactly_ what I say, I wonder what exactly is wrong. But it must be something pretty bad, at your end...

Always been this way. You just send "draw" (not offer draw) to the server, and if it is a legit draw, the game ends right then. Otherwise the draw command is sent to the opponent which effectively offers him the opportunity to accept the draw and still end the game...

Why you try to mix up WinBoard protocol with ICS communication now is also a mystery. Seems to me I could not have stated more explicitly what command to use in which protocol.

[wgarvin]

Could it just be made to work like this?

(1) If you send "offer draw" to the GUI in a situation where you can legally claim a draw, it is interpreted as a draw claim and the game ends instantly.

(2) If you send "offer draw" to the GUI in a situation where you CAN'T legally claim a draw, it is forwarded to the opponent who can then respond to it in the usual way.

(3) If you send a RESULT of draw to the GUI in a situation where you can legally claim a draw, it is interpreted as a draw claim and the game ends instantly.

(4) If you send a RESULT of draw to the GUI in a situation where you CAN'T legally claim a draw, you have made an erroneous draw claim, *and* your engine is refusing to continue the game, so you forfeit.


Sending of RESULT strings seems kind of bogus anyway (it should be the GUI's job to recognize the end of the game and report it to both players?) but since its in the protocol, and since most engines can't continue sensibly after they send it, it makes sense to me for engines to forfeit if they send an incorrect RESULT string. Maybe its the moral equivalent of, claiming the draw and then standing up and walking away from the board and not coming back. Engines should prefer not to send RESULT strings anyway, and just use "offer draw" both to claim draws when that is legal, and to offer a draw to the opponent in other situations.

Have I missed anything important?

[hgm]

You didn't miss anything, and this is indeed exactly how it works in WinBoard 4.3.13 (already available for month for download under the name alpha.tst from my website, but still undergoing regular bugfixes to make it ready for release). Problem is that Bob takes perpetual offense to that...

The official description of WinBoard protocol supports your interpretation: The RESULT command should only be used "when the game is definitely over", i.e. when the engine under no circumstances is prepared to continue the game. For situations where you unexpectedly might have to continue the game (such as accepting draw offers, as they might be retracted by the time you accept them), the protocol specifies that "offer draw" should be used, not RESULT.

The RESULT command is a legacy from the time where the GUI was merely a dumb graphical display program meant for communication between a Human user and an all-knowing engine. But I should stress that this situation still exists in many Chess variants. WinBoard can be used as a GUI for many games for which it doesn't even know how the pieces move (with legality checking turned off, obviously). In such variants it has to trust the engines to inform it about the game end.

I could also add that WinBoard 4.3.13 delays passing draw offers to the opponent until it is also ready to pass the move of the draw offerer. This way it can also check if a draw condition is fulfilled after the move of the offerer (and then declare the draw without consulting the opponent). This is also good for not disturbing the pondering process: you will only get input from the GUI when your turn started anyway (draw offer + times + move).

To give engines that claim draws that exist after their own move through the RESULT command, without being tricked by the opponent sneaking in a fast move between this move and the draw claim, no forfeits will be declared if the draw condition existed before the opponent's move, but not after it.

[Uri Blass]

You didn't miss anything, and this is indeed exactly how it works in WinBoard 4.3.13 (already available for month for download under the name alpha.tst from my website, but still undergoing regular bugfixes to make it ready for release). Problem is that Bob takes perpetual offense to that...

The official description of WinBoard protocol supports your interpretation: The RESULT command should only be used "when the game is definitely over", i.e. when the engine under no circumstances is prepared to continue the game. For situations where you unexpectedly might have to continue the game (such as accepting draw offers, as they might be retracted by the time you accept them), the protocol specifies that "offer draw" should be used, not RESULT.

The RESULT command is a legacy from the time where the GUI was merely a dumb graphical display program meant for communication between a Human user and an all-knowing engine. But I should stress that this situation still exists in many Chess variants. WinBoard can be used as a GUI for many games for which it doesn't even know how the pieces move (with legality checking turned off, obviously). In such variants it has to trust the engines to inform it about the game end.

I could also add that WinBoard 4.3.13 delays passing draw offers to the opponent until it is also ready to pass the move of the draw offerer. This way it can also check if a draw condition is fulfilled after the move of the offerer (and then declare the draw without consulting the opponent). This is also good for not disturbing the pondering process: you will only get input from the GUI when your turn started anyway (draw offer + times + move).

To give engines that claim draws that exist after their own move through the RESULT command, without being tricked by the opponent sneaking in a fast move between this move and the draw claim, no forfeits will be declared if the draw condition existed before the opponent's move, but not after it.

Note that the fact that the game is finished if one player offers a draw and has a justification to claim a draw is against the fide rules.

This is not only in games between computers but also in games between humans.

The only solution that is consistent with the fide rules is to add an option to players to claim a draw when they have to explain the reason that they claim a draw and to punish humans who do not claim a draw for the right reason on the clock.

Uri