Moderators: hgm, Rebel, chrisw
Would 'definitely over' give you a clue?bob wrote:Now exactly where does it say that the game can't continue??? One might want to infer that from the above, but it is not how the command is actually implemented.
I understand Bob's pointhgm wrote:Would 'definitely over' give you a clue?bob wrote:Now exactly where does it say that the game can't continue??? One might want to infer that from the above, but it is not how the command is actually implemented.
Seems to me that something that is definitely over cannot continue.
But of course I probably don't understand properly what 'definitely' means. Or 'over'...
The fact that offering a draw without claiming a draw can terminate the game if you have a basis to claim draw by repetition even if the opponent does not accept the draw is against the fide rules.hgm wrote:No, the best way is to simply keep things as they are now, where they work in practice.
This involves having a command for the engine to terminate the game, so that no time is wasted in needless waiting. (The 'get-up-and-walk-away message'. And for the benifit of GUIs that cannot make reliable result determinations in all variants they support it is very desirable if that get-up-and-walk-away message goes accompanied by the result as percieved by the engine, which has the status of a recommendation, so that the GUI can do whatever it wants with it.
Secondly, there is need for a command that can be used to claim a draw and cannot lead to forfeit in situations where the draw might be uncertain (because of timing issues, that can have lead to retraction of a draw offer, or destruction of the draw condition on basis of which the claim is being made, by an opponent move).
Commands that exactly have these effects do already exist. The first is "RESULT { RESULT_DETAILS }", the second is "offer draw". So there is no reason to change anything. That a draw claim through "offer draw" is relayed to the opponent as an offer when there is no basis for a claim, is actually what the FIDE rules prescribe (9.1c)..
I won't change comamnds, nor will allow engines to changw the name of existing commands on request, just because they don't like the name of these commands. They should use the commands in their defined meanings, and if they don't the consequences are on them. That is final, and always has been final.
hgm wrote: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.bob wrote:Now exactly where does it say that the game can't continue??? One might want to infer that from the above, but it is not how the command is actually implemented.
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...
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? 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.Would 'definitely over' give you a clue?
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.Seems to me that something that is definitely over cannot continue.
But of course I probably don't understand properly what 'definitely' means. Or 'over'...
One more time:
Eliminate the result command. An engine should not be able to claim a win or draw on its own;
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.
None of the above would break existing programs. And they would solve existing problems cleanly and clearly.
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.
Why are you so impossibly thick-headed that you refuse to understand the problem with keeping the result command. Suppose I send you a version of Crafty to test that when it plays white, after a random number of moves, it just sends "Result 1-0 {black resigns}", or when it plays black, it sends "Result 0-1 {white resigns}"???hgm wrote:No, the best way is to simply keep things as they are now, where they work in practice.
This involves having a command for the engine to terminate the game, so that no time is wasted in needless waiting. (The 'get-up-and-walk-away message'. And for the benifit of GUIs that cannot make reliable result determinations in all variants they support it is very desirable if that get-up-and-walk-away message goes accompanied by the result as percieved by the engine, which has the status of a recommendation, so that the GUI can do whatever it wants with it.
Secondly, there is need for a command that can be used to claim a draw and cannot lead to forfeit in situations where the draw might be uncertain (because of timing issues, that can have lead to retraction of a draw offer, or destruction of the draw condition on basis of which the claim is being made, by an opponent move).
Commands that exactly have these effects do already exist. The first is "RESULT { RESULT_DETAILS }", the second is "offer draw". So there is no reason to change anything. That a draw claim through "offer draw" is relayed to the opponent as an offer when there is no basis for a claim, is actually what the FIDE rules prescribe (9.1c)..
I won't change comamnds, nor will allow engines to changw the name of existing commands on request, just because they don't like the name of these commands. They should use the commands in their defined meanings, and if they don't the consequences are on them. That is final, and always has been final.
Yes, what of it? So you forfeit a few games on false claims. If you wanted to lose those games youcould also have sent the proper resign commands. There is no way for a GUI to prevent engines from resigning or intentionally forfeiting, not even after a random number of moves...bob wrote:Why are you so impossibly thick-headed that you refuse to understand the problem with keeping the result command. Suppose I send you a version of Crafty to test that when it plays white, after a random number of moves, it just sends "Result 1-0 {black resigns}", or when it plays black, it sends "Result 0-1 {white resigns}"???
Only if you are livng in the stone age...Don't you grasp the idea that this leads to worse testing results than the stupid case you are trying to make for when an engine claims a result that is invalid and then they can't continue and would lose on time. You claim that wastes times. I claim not doing that wastes more time because now I have to go through every game carefully to see if the result matches what the programs thought it should be.
Well, you would forfeit only once every 4 games. Beats me why you would want to forfeit at all, though...how is that better? Aren't we talking about automated matches? Where you can't trust your opponent to not throw in a bad result.
What if I send you a version of crafty that doesn't do this _every_ time. Just say one of every 4 games I claim to be winning when I know I am losing?
Not at all. The command is extremely useful, as long as the reported result is corrected when the GUI can recognize it is in error.The command needs to go. It doesn't exist in human tournaments for obvious reasons. It doesn't belong here either.
Well, many commands now accomplish that, so no problem.A program should be able to resign whenever it wants. GUI has no say-so.
Then follow the recommendation of the protocol, and use "offer draw".program should be able to claim a draw whenever it wants, but the GUI has to approve and accept it, else the game continues.
It should always be possible for a program to tell the GUI it is not going to play on.A program should be able to mate its opponent and the GUI should recognize this and end the game. So a program should be able to beat its opponent, or resign the game, otherwise the GUI is the final arbiter to decide whether or not the game is over...
Excuse me?bob wrote: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...
I don't know what game you think you are playing here by these gros distortions of reality...bob wrote: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.
Zero would be a good number. As it wouldn't make the slightest difference...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?
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...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.
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.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.
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.One more time:
Eliminate the result command. An engine should not be able to claim a win or draw on its own;
For one, you are discussing a protocol change now, which is beyond the scope of this discussion. I have no say over the protocol.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.
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.None of the above would break existing programs. And they would solve existing problems cleanly and clearly.
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.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.
There is a logical reason for offering a draw without claiming a draw even when you can claim a draw.hgm wrote:You want a draw offer that the opponent can reject even in a draw situation. That is not a useful combination. You either want a draw, or you don't. And you should not offer it if you don't and you should be happy to get it (for whtever reason) if you do. So no one should ever want to use that command.
I am not going to waste time by implementing useless features. FIDE rules or not...