Hello H.G.Muller : upgrading the protocol

[bob]

ICC does this correctly. "draw" is all you need to say. If a draw is claimable, that claims it. If a draw offer is pending, that accepts it. If none of the above, it offers your opponent a draw. It simply says either end the game if possible, or offer a draw if not. You can use it before or after your move with correct results. And with no race conditions.

ICC does require the draw before your move if you want to claim a repetition after your move. And even that is a bit of a kludge. But that was done years ago when I first discovered this issue. The current proposal for xboard is a better solution without the kludge of offering before you really mean it.

[hgm]

I think I am even more confused now what it required and what is not.

In the sequence (as you suggest)

offer draw
move Rh7+
1/2-1/2

Is 1/2-1/2 a workaround to maximize backward compatibility with older GUIs or a requirement of the protocol? you talk here like it is a requirement but where is that in the protocol?

In both the original description of the protocol and my extended one, the description of the RESULT command says that the engine "must output" it. And the reason for that requirement still exists. From the offer draw in a non-claimable situation the GUI cannot see if it was intended as a genuine offer, or if it was in fact a false claim, and the engine now thinks it is done. I want it to clearly state its intentions when it signs off.

So the requirement to send 1/2-1/2 is not only there for backward compatibility: it helps detect false claims in the new implementation. I don't want to offer engines new ways to hide their bugs, such as not sending 1/2-1/2 when they know the GUI does not really need it if their claim was correct, just out of fear their claim might be wrong. Like you wanted to do. That is not the kind of response I want to see / facilitate. You should make sure your engine claims correctly, not try to optimize how it can get away with buggy claiming logic.

unless I missed something, the protocol specifies that I should do offer draw & move Rh7+ and it does not look 1/2-1/2 is required.

Also, with the old winboard, offer draw was not used to claim draws, now it does.

The "must output" is still there, in the specs.

In the old specs, offer draw was prescribed to accept draw offers, which could be viewed as a special case of claiming a draw: when my opponent offers me a draw, he creates a situation where I have the right to claim it, just as much as when he would have repeated moves.

The description of this property of offer draw was hidden in the description of the GUI->engine draw command. What I did is copied it to the decription of the offer draw command as well.

I read this remark as "A draw offer will be granted by the GUI immediately when there is no need to consult the opponent, because the opponent is not in a position where he can refuse" (e.g. because he did offer a draw, and is not allowed to retract the offer). It is just that the original specs failed to give an exhaustive list of the situations where this is the case. Note that even old XBoard behavior did require the offer draw before the move in ICS play, although the protocol specs fail to mention this.

[bob]

I think I am even more confused now what it required and what is not.

In the sequence (as you suggest)

offer draw
move Rh7+
1/2-1/2

Is 1/2-1/2 a workaround to maximize backward compatibility with older GUIs or a requirement of the protocol? you talk here like it is a requirement but where is that in the protocol?

In both the original description of the protocol and my extended one, the description of the RESULT command says that the engine "must output" it. And the reason for that requirement still exists. From the offer draw in a non-claimable situation the GUI cannot see if it was intended as a genuine offer, or if it was in fact a false claim, and the engine now thinks it is done. I want it to clearly state its intentions when it signs off.

So the requirement to send 1/2-1/2 is not only there for backward compatibility: it helps detect false claims in the new implementation. I don't want to offer engines new ways to hide their bugs, such as not sending 1/2-1/2 when they know the GUI does not really need it if their claim was correct, just out of fear their claim might be wrong. Like you wanted to do. That is not the kind of response I want to see / facilitate. You should make sure your engine claims correctly, not try to optimize how it can get away with buggy claiming logic.

unless I missed something, the protocol specifies that I should do offer draw & move Rh7+ and it does not look 1/2-1/2 is required.

Also, with the old winboard, offer draw was not used to claim draws, now it does.

The "must output" is still there, in the specs.

In the old specs, offer draw was prescribed to accept draw offers, which could be viewed as a special case of claiming a draw: when my opponent offers me a draw, he creates a situation where I have the right to claim it, just as much as when he would have repeated moves.

The description of this property of offer draw was hidden in the description of the GUI->engine draw command. What I did is copied it to the decription of the offer draw command as well.

I read this remark as "A draw offer will be granted by the GUI immediately when there is no need to consult the opponent, because the opponent is not in a position where he can refuse" (e.g. because he did offer a draw, and is not allowed to retract the offer). It is just that the original specs failed to give an exhaustive list of the situations where this is the case. Note that even old XBoard behavior did require the offer draw before the move in ICS play, although the protocol specs fail to mention this.

Here is the crux of the problem. Tell me how to do this:

I absolutely want to end the game. I am not going to play on. And I want to claim a 3-fold draw by repetition that happens _after_ my move. According to the current interpretation of the protocol, the "result" command is the proper way to do this.

I know how to end the game on a repetition that occurs prior to my making a move. I just send 1/2-1/2 and the game ends. But how do I do it in the more common case where I want to claim the repetition after my move and end the game unconditionally?

move Rh7+
1/2-1/2 won't work as we now all know.

If you can make

1/2-1/2
Move Rh7

work in the case that the game is a draw prior to my move (and Crafty would not send Rh7 there anyway, but I suppose an engine could, which should not cause any problem) and work in the case where the game is a draw after my move, this would solve the problem I am looking at. My program knows _exactly_ where the game ends, with 100% reliability. But it doesn't have a safe way to inform the GUI at present, because of that ever-present race condition after I make a move and then try to do something else immediately following.

[hgm]

Here is the crux of the problem. Tell me how to do this:

I absolutely want to end the game. I am not going to play on. And I want to claim a 3-fold draw by repetition that happens _after_ my move. According to the current interpretation of the protocol, the "result" command is the proper way to do this.

The RESULT command is the prescribed way to do this, both in the original protocol specs as in my elaborations on it, but not until _after_ you have sent the move that draws.

So you send:

move xxxx
1/2-1/2 {3-fold repetition}

It is the job of the GUI to make sure that this works (i.e. grants you your rightful draw). Unfortunately, this requires to open a loophole for cheats (claiming in retrospect dependent on what your opponent has moved), and can cause your engine to receive a bogus move of the opponent, which is not consistent with the draw being granted.

Now unfortunately this does not always work in ICS play even for securing your draw, and there is nothing we could do in the GUI to with the above sequence to make it always work: only the ICS can solve the race condition. To be sure you get the draw, you have to make the ICS aware that you intend to claim the draw after your move in advance. This is the solution they have chosen to resolve the race condition, and we will have to follow it. This requires you do something to provole the GUI into sending "draw" to the ICS, before relaying your move. This something is sending an offer draw, as on all GUIs in all versions this translates to "draw" being sent to the ICS in ICS play. So you send

offer draw
move xxxx
1/2-1/2 {3-fold repetition}

To not make what you send dependent on if you are playing ICS or locally, you also send that same sequence in local play. This has the additional benefit that in local play newer GUIs can now also guarantee that you will not receive any bogus moves.

I know how to end the game on a repetition that occurs prior to my making a move. I just send 1/2-1/2 and the game ends. But how do I do it in the more common case where I want to claim the repetition after my move and end the game unconditionally?

move Rh7+
1/2-1/2 won't work as we now all know.

If you can make

1/2-1/2
Move Rh7

work in the case that the game is a draw prior to my move (and Crafty would not send Rh7 there anyway, but I suppose an engine could, which should not cause any problem) and work in the case where the game is a draw after my move, this would solve the problem I am looking at. My program knows _exactly_ where the game ends, with 100% reliability. But it doesn't have a safe way to inform the GUI at present, because of that ever-present race condition after I make a move and then try to do something else immediately following.

The safe way is the sequence I gave above, on current XBoard / WinBoard. If other GUIs deny you the draw if you use this sequence, they are to be considered buggy and will have to be fixed. There is nothing in the (original) protocol that could be used as an excuse for this sequence not resulting in a draw (if the claim was justified). Do not try to invent work-arounds to make your engine work under such buggy GUIs, that is a hopeless battle.

[Uri Blass]

I think that the sequence that you give is a good solution to the problem.
It was not logical to claim a draw by offering a draw but both offering a draw and claiming it is something that can be done also in human events.

In the past my first step before claiming a draw in a tournament game was simply to offer a draw to my opponent and I claimed a draw only after my opponent said no to the offer or asked me to play a move before responding.

The reason is simple.
I prefer to save time and not to spend the time of other people to check that my claim is correct.

It means that it is clearly logical to have the following order also in human events:

1)offer draw in your move
2)write move xxxx in your scoresheet
3)claim:1/2-1/2 {3-fold repetition}

[michiguel]

I think that the sequence that you give is a good solution to the problem.
It was not logical to claim a draw by offering a draw but both offering a draw and claiming it is something that can be done also in human events.

In the past my first step before claiming a draw in a tournament game was simply to offer a draw to my opponent and I claimed a draw only after my opponent said no to the offer or asked me to play a move before responding.

The reason is simple.
I prefer to save time and not to spend the time of other people to check that my claim is correct.

It means that it is clearly logical to have the following order also in human events:

1)offer draw in your move
2)write move xxxx in your scoresheet
3)claim:1/2-1/2 {3-fold repetition}

Not exactly, because in human events you never lose for an invalid claim.

Miguel

[rjgibert]

ICC does this correctly. "draw" is all you need to say. If a draw is claimable, that claims it. If a draw offer is pending, that accepts it. If none of the above, it offers your opponent a draw. It simply says either end the game if possible, or offer a draw if not. You can use it before or after your move with correct results. And with no race conditions.

ICC may do this, but it is definitely is not correct. If you make a draw claim and it is invalid, you should be penalized by 5 minutes being subtracted from your clock even if it means you forfeit on time. Allowing a draw claim to morph into a draw offer is totally wrong.

ICC does require the draw before your move if you want to claim a repetition after your move. And even that is a bit of a kludge. But that was done years ago when I first discovered this issue. The current proposal for xboard is a better solution without the kludge of offering before you really mean it.

[Uri Blass]

ICC may do this, but it is definitely is not correct. If you make a draw claim and it is invalid, you should be penalized by 5 minutes being subtracted from your clock even if it means you forfeit on time. Allowing a draw claim to morph into a draw offer is totally wrong.

These may be the rules in the past but not today
when you are not allowed to deduct more than 3 minutes and draw claim is automatically draw offer by definition:

http://www.fide.com/fide/handbook?id=124&view=article

9.5)b) of the fide rules:

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.

9.1)c) of the fide rules:

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

[rjgibert]

ICC may do this, but it is definitely is not correct. If you make a draw claim and it is invalid, you should be penalized by 5 minutes being subtracted from your clock even if it means you forfeit on time. Allowing a draw claim to morph into a draw offer is totally wrong.

These may be the rules in the past but not today
when you are not allowed to deduct more than 3 minutes and draw claim is automatically draw offer by definition:

http://www.fide.com/fide/handbook?id=124&view=article

9.5)b) of the fide rules:

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.

9.1)c) of the fide rules:

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

I've been out of circulation tournament-wise for some 13 years. This is definitely different. In any case, my point still stands. Allowing an invalid draw claim to morph into a draw offer and elude the penalty is definitely wrong (which is what happens at ICC, BTW).

[Uri Blass]

I think that the sequence that you give is a good solution to the problem.
It was not logical to claim a draw by offering a draw but both offering a draw and claiming it is something that can be done also in human events.

In the past my first step before claiming a draw in a tournament game was simply to offer a draw to my opponent and I claimed a draw only after my opponent said no to the offer or asked me to play a move before responding.

The reason is simple.
I prefer to save time and not to spend the time of other people to check that my claim is correct.

It means that it is clearly logical to have the following order also in human events:

1)offer draw in your move
2)write move xxxx in your scoresheet
3)claim:1/2-1/2 {3-fold repetition}

Not exactly, because in human events you never lose for an invalid claim.

Miguel

You do not lose but you cannot continue with the same times on the clock.

There is no problem if the gui allows the engine to continue(assuming that the engine tells the gui that it can continue after false claims).

We need this assumption because many engines are designed based on the winboard protocol and cannot continue after they make a draw claim because the winboard protocol today say that the game is finished and we do not like to spend time to wait for them to lose on time instead of finishing the game immediately.

Uri