Hello H.G.Muller : upgrading the protocol

[bob]

Crafty _always_ sends the 1/2-1/2 _after_ it makes a move.

No !

The reason Crafty forfeited in the game that started this discussion is that it sent the 1/2-1/2 while GUI was waiting for a move

I wonder whether the sequence was

Code: Select all

crafty --> offer draw
                          GUI gets "offer draw" from Crafty
crafty --> move Rh8
                          GUI gets "move Rh8" from Crafty
                                 (here GUI should declare a 
                                   draw with the new behavior 
                                   of offer draw)
                          GUI gets "move Kb7" from opponent faster 
                                        than next command from Crafty
crafty --> 1/2-1/2
                          GUI sees that it is not a draw anymore.

Were you processing "offer draw" as the protocol now indicates?
What I just wrote is what could happen with the old behavior of winboard.

Miguel

Code: Select all

Eng1 &#40;Crafty 23.0 32-bit&#41; <- 21      1     437 7781866  72. Kf1
Eng1 &#40;Crafty 23.0 32-bit&#41; <- 21      1     935 16387909  72. Kf1
Eng1 &#40;Crafty 23.0 32-bit&#41; <- 22      1     935 16387910  72. Kf1
Eng1 &#40;Crafty 23.0 32-bit&#41; <- 22      1    2976 50514331  72. Kf1
Eng1 &#40;Crafty 23.0 32-bit&#41; <- 23      1    2976 50514332  72. Kf1
Eng1 &#40;Crafty 23.0 32-bit&#41; <- 1/2-1/2 &#123;Drawn by 3-fold repetition&#125;


Now in WB_EndOfGameClaim&#40;) at Time0000000939539828

Now in EndTheGame&#40;) at Time0000000939539828

0-1 &#123; Game Nr. 1 &#58; Crafty 23.0 32-bit resigns against ProDeo 1.6 
 GameDuration = 02&#58;15&#58;14, Finalposition 8/P7/5pk1/6pp/4P1nP/8/5KN1/6Qq w - - 11 72 &#125;
.

This isn't an "offer draw" case. It is a case of crafty sending "1/2-1/2" followed by a move that results in a draw...

BTW, this is yet another good example of why "timing" of commands is the wrong way to go. Given this:

I move xxx

1/2-1/2

I move yyy

Which move does the 1/2-1/2 go with? How do you know? Currently, I move XXX, I try to send 1/2-1/2 but the GUI gets my move, sends it to the opponent, gets his move and sends it back, and then sees the 1/2-1/2 and thinks this is for the current position. It is not. It was for the position after _my_ move which the GUI has not misinterpreted.

And it gets recorded as a loss, incorrectly.

[Matthias Gemuh]

Just to highlight redundantly what all this talk is about:


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

Therefore no move is to be expected after "1-0" {...}", or "0-1 {...}", or "1/2-1/2 {...}".

Matthias.

And _that_ is a serious problem. I hope you can now see why. Because it can't possibly work like that due to the example I have given more than once now.

I see your point.
This problem only arises, if game is allowed to continue after a 3-fold-rep or 50-move.
Current ChessGUI escapes by terminating the game on first appearance of 3-fold-rep or 50-move rule.
I was about to just let ChessGUI flag any 3-fold-rep or 50-move rule as a pending draw and let game continue till a claim, but now I will stay with termination till we find a solution.

Simply sending a claim before the move would indeed solve the problem, but leave hundreds of existing engines hanging.

Matthias.

[Spock]

I'm pretty sure the same issues arise with Arena and Crafty as well. I'll check that.

What I can also say is that every other engine I've tried has worked perfectly under ChessGUI.

I'm not sure what the solution is for this issue - but what I am sure of is that Matthias should hold off making any quick changes to ChessGUI until the solution is clear.

[Matthias Gemuh]

Lousy solution. I then lose on time while you are waiting. There are too many holes. I have already suggested ignoring the claims and assume that if a program repeats for the 3rd time, or meets the 50-move rule criterion, that the game is simply ended with that result. But not the loss you are currently doing, which makes no sense at all IMHO.

BTW, I don't know your programming background, but we are in a "parallel world" here since there are two programs sending info at the same time. You are making a classic beginner's mistake when you start talking about "I will wait for a bit". In parallel programming you _NEVER_ base anything on some amount of time elapsing. You base things on events getting properly detected or posted. That's where this problem is coming from. It seems simple to me, but I've been doing parallel stuff for 30+ years now and it is second nature. Forget the "time" word. It leads to massive trouble.

ChessGUI has been flagging the sequence "claim before move" with a loss because that is how Winboard/Xboard handle that issue, a sort of penalty for not respecting the details of the "result" command.

ChessGUI must stay in sync on this one with other interfaces, so as not to affect engines ratings too much.

I time-limit the events I set concerning your moves. They only live as long as the time on your clock. Just because two engines are running at once "in parallel programming", that doesn't mean a GUI cannot know when to kill the event of one engine.

Matthias.

[Matthias Gemuh]

I'm pretty sure the same issues arise with Arena and Crafty as well. I'll check that.

What I can also say is that every other engine I've tried has worked perfectly under ChessGUI.

I'm not sure what the solution is for this issue - but what I am sure of is that Matthias should hold off making any quick changes to ChessGUI until the solution is clear.

ChessGUI 0.151a handles the draw claim in a "Crafty-friendly" manner.
I now realize that this can affect engine rating lists because Winboard/Xboard does not do that.

I will go back to previous approach to stay in sync with Winboard/Xboard, till a conscensus is found.

Matthias.

[Spock]

Well, Crafty doesn't support FRC so I won't be running it for ratings purposes

Crafty has always been troublesome one way or another - the "smpnice" fix that was necessary, the time control fix when using a neutral book etc etc.

[bob]

Just to highlight redundantly what all this talk is about:


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

Therefore no move is to be expected after "1-0" {...}", or "0-1 {...}", or "1/2-1/2 {...}".

Matthias.

And _that_ is a serious problem. I hope you can now see why. Because it can't possibly work like that due to the example I have given more than once now.

I see your point.
This problem only arises, if game is allowed to continue after a 3-fold-rep or 50-move.
Current ChessGUI escapes by terminating the game on first appearance of 3-fold-rep or 50-move rule.
I was about to just let ChessGUI flag any 3-fold-rep or 50-move rule as a pending draw and let game continue till a claim, but now I will stay with termination till we find a solution.

Simply sending a claim before the move would indeed solve the problem, but leave hundreds of existing engines hanging.

Matthias.

It doesn't really leave them hanging. They are _already_ hanging if they send the claim after the move. I gave a simple example. If they are given a simple guideline "Any claims you want to make during your turn to move, must be sent prior to sending your move. Once you send your move, it will be relayed to the opponent, and any claim made after that may well not be dealt with until after your opponent moves. As a result, the standard behavior for handling your claims for a draw, etc will be as follows: When your claim is received, it will be immediately checked against the current game state. If the claim is valid, the game will end with the appropriate result. If the claim is not valid with the current state, it will be held until you send a move. After the move is made, before it is relayed to your opponent, your claim will again be evaluated to see if it is applicable after your move. If so, the game will immediately end, as it did for the previous case. If the claim is not valid either before or after your move, the claim will be ignored and the game will continue."

That will work. I don't think it is optimal, but it works with no loopholes. What this is doing is to treat the claim / move as if it were either claim - move, or move-claim, depending on which works. I'd rather the protocol be more explicit, but there seems to be little interest in fixing something that is definitely broken. Fixing this would also let a program comply with the official FIDE rules of chess and offer/claim things at the correct time and in a way that an arbiter would be satisfied that the rules have been met. At present, the interface is not doing that.

[bob]

I'm pretty sure the same issues arise with Arena and Crafty as well. I'll check that.

What I can also say is that every other engine I've tried has worked perfectly under ChessGUI.

I'm not sure what the solution is for this issue - but what I am sure of is that Matthias should hold off making any quick changes to ChessGUI until the solution is clear.

This is not surprising. We have had this discussion many times in the past. 99% of existing programs do not comply with the FIDE rules of chess. Crafty does. And it has withstood a couple of challenges on this issue in real OTB events. Just because "every other engine works perfectly" doesn't mean they work _correctly_. I have found this to be so poorly done that my referee completely ignores draw claims or offers and just assumes that the games should end when a by-rule draw condition arises. Hardly anybody gets it right.

Here's some example output from crafty.

1. If the position before it moves allows a draw claim, one of these is issued:

Print(128, "%sI claim a draw by 3-fold repetition.%s\n"
Print(128, "%sI claim a draw by the 50 move rule.%s\n",
Print(128, "%sI claim a draw due to insufficient material.%s\n",

2. if the position after its move allows a draw claim, one of these is issued:

Print(128, "%sI claim a draw by 3-fold repetition after my move.%s\n",
Print(128, "%sI claim a draw by the 50 move rule after my move.%s\n",
Print(128,"%sI claim a draw due to insufficient material after my move.%s\n",

That is done so that in "console mode", which is how I play crafty in human tournaments, it is clear to an arbiter/TD what it is claiming and when. You won't find many programs that get those correct. When the operator (me) sees the above, I write the move down, and call the TD over, without hitting the clock and ending my move. And it follows the FIDE rule book _perfectly_ that way.

[wgarvin]

Just to highlight redundantly what all this talk is about:


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

Therefore no move is to be expected after "1-0" {...}", or "0-1 {...}", or "1/2-1/2 {...}".

Matthias.

And _that_ is a serious problem. I hope you can now see why. Because it can't possibly work like that due to the example I have given more than once now.

I see your point.
This problem only arises, if game is allowed to continue after a 3-fold-rep or 50-move.
Current ChessGUI escapes by terminating the game on first appearance of 3-fold-rep or 50-move rule.
I was about to just let ChessGUI flag any 3-fold-rep or 50-move rule as a pending draw and let game continue till a claim, but now I will stay with termination till we find a solution.

Simply sending a claim before the move would indeed solve the problem, but leave hundreds of existing engines hanging.

Matthias.

It doesn't really leave them hanging. They are _already_ hanging if they send the claim after the move. I gave a simple example. If they are given a simple guideline "Any claims you want to make during your turn to move, must be sent prior to sending your move. Once you send your move, it will be relayed to the opponent, and any claim made after that may well not be dealt with until after your opponent moves. As a result, the standard behavior for handling your claims for a draw, etc will be as follows: When your claim is received, it will be immediately checked against the current game state. If the claim is valid, the game will end with the appropriate result. If the claim is not valid with the current state, it will be held until you send a move. After the move is made, before it is relayed to your opponent, your claim will again be evaluated to see if it is applicable after your move. If so, the game will immediately end, as it did for the previous case. If the claim is not valid either before or after your move, the claim will be ignored and the game will continue."

That will work. I don't think it is optimal, but it works with no loopholes. What this is doing is to treat the claim / move as if it were either claim - move, or move-claim, depending on which works. I'd rather the protocol be more explicit, but there seems to be little interest in fixing something that is definitely broken. Fixing this would also let a program comply with the official FIDE rules of chess and offer/claim things at the correct time and in a way that an arbiter would be satisfied that the rules have been met. At present, the interface is not doing that.

I didn't read the whole discussion, but in regards to this specific situation of "engine wants to claim a draw in the position that results after engine makes its move", would it work to send the following sequence?

Code: Select all

offer draw
move <whatever>
1/2 - 1/2  &#123; draw by 3-fold repetition &#125;

In other words, (1) you first "claim" the draw using the "offer draw" followed by the move you want to play. And then (2) assert that the game is definitely now over.

GUIs which recognize a "claim" in the form of "offer draw" followed by the move, will already have ended the game. GUIs which simply forward "offer draw" to the opponent without handling claims, will hopefully be dumb enough to just believe you when you assert that the game has ended in a draw.

Any GUI which fails to treat your "offer draw" as a claim after the move is sent, and then also fails to handle the asserted result correctly, would seem to be totally broken.

[bob]

Lousy solution. I then lose on time while you are waiting. There are too many holes. I have already suggested ignoring the claims and assume that if a program repeats for the 3rd time, or meets the 50-move rule criterion, that the game is simply ended with that result. But not the loss you are currently doing, which makes no sense at all IMHO.

BTW, I don't know your programming background, but we are in a "parallel world" here since there are two programs sending info at the same time. You are making a classic beginner's mistake when you start talking about "I will wait for a bit". In parallel programming you _NEVER_ base anything on some amount of time elapsing. You base things on events getting properly detected or posted. That's where this problem is coming from. It seems simple to me, but I've been doing parallel stuff for 30+ years now and it is second nature. Forget the "time" word. It leads to massive trouble.

ChessGUI has been flagging the sequence "claim before move" with a loss because that is how Winboard/Xboard handle that issue, a sort of penalty for not respecting the details of the "result" command.

I can play a few dozen games between Crafty and another opponent using xboard on my computer here. Would you like me to ship you a couple of dozen games that end in draw and show you that at least my version of xboard does _not_ behave like this. There is no "penalty" in the version I have been using for years.

ChessGUI must stay in sync on this one with other interfaces, so as not to affect engines ratings too much.

I time-limit the events I set concerning your moves. They only live as long as the time on your clock. Just because two engines are running at once "in parallel programming", that doesn't mean a GUI cannot know when to kill the event of one engine.

Matthias.

No, but it shows an incredibly poor design. One doesn't use "time" to try to synchronize two parallel events. It never works. The original intent here was to correct the protocol to eliminate these kludge solutions. Not to find more kludge solutions so that the protocol remains unchanged...

I'm beginning to think that the right answer for me is to simply fix the protocol, but change all the keywords so that they are no longer compatible with xboard at all, and then simultaneously release an xboard that works correctly with crafty, lives within the FIDE rules of chess, and works for interfacing Crafty to ICC but nothing else. At least I will know things work correctly in that context.

Right now, part of this is simply a mess to deal with, with kludge after kludge, assumption after assumption, none of which makes any real sense. Some see the problem. Some don't. I'm not so concerned whether Crafty is compatible with various GUIs or not. And based on this result, where Crafty is losing drawn games, I'm becoming more and more convinced that it is just not worth the trouble. Xboard was one almost solely developed for Crafty. GnuChess was dead, and I worked closely with Tim to add more and more features that I found useful. Now we have something that needs addressing.

I find it pointless to have the GUI know whether or not the game is a draw or not, and then even bother with the result from a program. If the GUI knows, why does it need the program to tell it something?

In any case, from my perspective, I'm going to consider what to do next, as I want this done right, regardless of how everyone else does it. Right is right. And the current approach is simply not "right". If I have to go my own way with this, I've done that before.