Engine authors, beware of false-draw-claim forfeits!

[Uri Blass]

At first glance I think you summarize my algorithm correctly.

But on second thought I think it is better to start adding the increment only in 'intervals' (= parts of the game to which an MPS and BASE apply) that have MPS=0. If you have to play 60 moves in 60 minutes, with an increment of 1 sec/move, you might as well specify 60 moves in 61 minutes, without increment.

So the increment adds no new feature if a number of moves is specified. Note that the current protocol does not even define an effect of the level command if not at least one of the moves or increment is zero. (Internally it forces one of the two to zero in the current implementation.) So it seems useles to specify both MPS(i) and BASE(i). There just has to one INC, for the interval that has MPS(i) = 0.

AFAIK there is no protocol-3 definition. Rather than implementing anything that flies around over the net, I would first have a consensus that has been thought about well enough to eliminate the nonsense. And even more importantly, look what time controls other GUIs do support for other protocols, and make sure that fuctionality is also supported. Otherwise I would prefer implementing my own ideas over just following someone who happened to be first in shouting a silly idea.

60 minutes/60 moves with an increasement of 1 second/move is not equivalent to 61 minutes/60 moves.


In the first case you are going to lose on time if you use 60 minutes and 40 seconds for the first 30 moves when in the second case you do not lose on time in this case and only get into time trouble when you have to make 30 moves in 20 seconds.

If you ask why to do it then there are cases when it can be good to do it.
Imagine that you can force a draw by repetition at move 30
You decide to use more time because maybe you can find something better than repetition.
If after 60 minutes and 40 seconds you find a mate combination.
you can decide to play it and win the game and if you find nothing then you can still force the repetition draw.

Uri

[Matthias Gemuh]

Yes, UCI controls the engines while WB sits there pondering what the engines are doing.
The lack of flexible time controls in WB is very annoying.
UCI handles a vast variety of time controls, e.g.

a/b+c
a/b +c/d+e/f+g

This is not a fundamental shortcoming of the WinBoard philosophy. It would be easy enough to add more 'flavors' of time control in the 'level' command. E.g. by allowing an arbitrary odd number of numeric arguments.

level a b c d e f 0 g 0

where a, c, e and 0 would specify number of moves, and b, d, f and g would specify number of minutes for these moves. Once a number of moves is 0 it would mean "rest of the game", and that no more (moves,minutes) pair will follow. The last number would be seconds of increment per move. Then the above would exactly produce your second example. If the last specified moves/minute interval would not have 0 moves, it would be taken repetitively for the rest of the game.

I could implement this for you in a minute, if anyone wants it. The engine could switch it on through the protocol-2 "features" command, by setting xlevel=1. There is no reason to introduce a higher protocol version for this, in protocol 2 GUIs that do not implement it, the feature would simply be rejected. The engine would not even have to test for acceptance or rejecting of the feature, as it does not affect anything the engine does, but something the GUI does. The engine will know it was accepted if it gets a level command with more than 3 arguments, and if it was rejected, it will simply never get that. And the interpretation of level commands with 3 arguments is not changed.

So I could add any time, if there is demand for this.

I definitely would appreciate an xlevel in WB.
If you implement it, I will do likewise in ChessGUI and then we can hope that authors will deliver time-flexible engines.

Matthias

[hgm]

60 minutes/60 moves with an increasement of 1 second/move is not equivalent to 61 minutes/60 moves.


In the first case you are going to lose on time if you use 60 minutes and 40 seconds for the first 30 moves when in the second case you do not lose on time in this case and only get into time trouble when you have to make 30 moves in 20 seconds.

If you ask why to do it then there are cases when it can be good to do it.
Imagine that you can force a draw by repetition at move 30
You decide to use more time because maybe you can find something better than repetition.
If after 60 minutes and 40 seconds you find a mate combination.
you can decide to play it and win the game and if you find nothing then you can still force the repetition draw.

I did not claim that 60/61 is exactly equivalent as 60/60+1, but for all practical purposes it is way too close to justify it as a separate option. And for nitpickers who care about these few seconds: they can always specify 1/60+1/0:01+1/0:01+1/0:01+ .... +1/0.01+1/60:01+1/0:01+....
which is exactly the same.

Current WinBoard does not support increments on a time control with a given number of moves per session, and I don't see any reason to create such a possibility. Especially if the protocol is already sufficiently flexible to specify it in an alternative, albeit cumbersome way.

[Uri Blass]

60 minutes/60 moves with an increasement of 1 second/move is not equivalent to 61 minutes/60 moves.


In the first case you are going to lose on time if you use 60 minutes and 40 seconds for the first 30 moves when in the second case you do not lose on time in this case and only get into time trouble when you have to make 30 moves in 20 seconds.

If you ask why to do it then there are cases when it can be good to do it.
Imagine that you can force a draw by repetition at move 30
You decide to use more time because maybe you can find something better than repetition.
If after 60 minutes and 40 seconds you find a mate combination.
you can decide to play it and win the game and if you find nothing then you can still force the repetition draw.

I did not claim that 60/61 is exactly equivalent as 60/60+1, but for all practical purposes it is way too close to justify it as a separate option. And for nitpickers who care about these few seconds: they can always specify 1/60+1/0:01+1/0:01+1/0:01+ .... +1/0.01+1/60:01+1/0:01+....
which is exactly the same.

Current WinBoard does not support increments on a time control with a given number of moves per session, and I don't see any reason to create such a possibility. Especially if the protocol is already sufficiently flexible to specify it in an alternative, albeit cumbersome way.

The point is that there are already winboard engines that implemented support for more than one time control and they assume 3 numbers for every period of moves.

You can decide not to support both MPS(i)>0 and INC(i)>0 but even if you do it then it is still better if you give the engines 3 numbers for every interval because there are already engines that were designed for 3 numbers and I think that even today if you use them under arena as winboard engines it is possible to test the extended winboard command with 3 numbers.

movei already has code to read the first 3 numbers and later again 3 numbers and assuming that I have no bugs in that code movei can understand the meaning of 3 numbers correctly based on the suggestion that I read.

Uri

[hgm]

Then we are in dire straits, forced to choose between forcing the rogue engines to change their interpretation of the level command, or adopting a bad protocol.

I will contact the author of Arena, then, to see if he would be willing to support the level command with pairs of MPS, BASE values, in stead of triples, for engines that set the feature "xlevel=N" (with N>1). As I understand, the option with triples is switched on by feature "level=1", so there would be no confusion which engine uses what.

WinBoard would then only support the xlevel featur.

[bob]

Well, I have no idea what your problem is. Fact is that WinBoard_F works satisfactory no matter what order the packets come in. Hence I consider your problems imaginary. And as long as you don't actually show me a winboard.debug file that documents the occurrence of a wrong call, the problems are also hypothetical.

OK, here is the problem.

First, you say you do the "move" and then the "offer draw".

How do you handle the following:

1. I want to claim a repetition or 50-move rule draw without making a move. So I send "offer draw" which ought to work.

2. I want to claim a repetition or 50-move rule draw after making a move, so I send "move xxx" and then "offer draw". How can that work reliably?

Scenario 1. You get the "move xxx" and make it on the board and send it to my opponent. You still have not seen the "offer draw" from me because either my process is not running, you have not been scheduled to run so that you can read it, etc. So the "offer draw" is in a buffer somewhere unseen by you. My opponent then makes a move and sends it to you. You still have not seen the "offer draw" from me, you relay the move to me. Now you get the "offer draw" and since his last move was a pawn push, there is no repetition or draw, so you think I am offering him a draw, and I have to play on, you just missed properly ending the game.

How do you solve that first, then we can go on to the other timing issues.... That is not an imaginary issue. It happened on ICC. It took some work to fix.

The optimal solution is to combine the "offer draw" as in "move xxx offer draw" sent as one message to the GUI. Even better would be "move xxx draw" which makes the move and claims the draw at the same time so that the timing hole is closed...

But that requires a change to the protocol, which is what several of us have been telling you would be a better solution here. Just add protocol version 3 and allow either or both of the two opponents to use it if they choose. The one that uses it won't have the problem. The one that doesn't might see it, but that is his choice until he fixes his program to use the more correct approach...

That's not an imaginary problem. It isn't one that will never happen in practice either. Ask fishbait on ICC...

[hgm]

Unfortunately moderator policy makes this forum unsuitable for extended point-by-point answer of your posts. If you want them answered, post the same questions in the WinBoard forum, and I promise a detailed answer.

[Graham Banks]

Unfortunately moderator policy makes this forum unsuitable for extended point-by-point answer of your posts. If you want them answered, post the same questions in the WinBoard forum, and I promise a detailed answer.

Hi HG,

You had a post removed in which you suggested that Bob rename Crafty as Clown plus another comment that was deemed inappropriate.
You were sent a copy of your post and were invited to repost it without the two comments.
However you've chosen not to do so, instead putting the blame on moderation policy. That is disappointing.
I might add that once moderators remove a post, it cannot be restored to where it was. We have also given an undertaking not to edit posts.
The moderators very rarely interfere in the programming subforum, but the same standards of behaviour are expected here as elsewhere.

Regards, Graham.

[hgm]

Yes, it is disappointing. But I don't consider "Clown" a derogative term, as it is practically a synonym for the name of my own engine, Joker. And I doubt it is even against the charter to 'insult' someones engine. If shielding the world from this suggestion was important enough to delete my lengthy post, in which I addressed all Bob's points in detail, I furthermore don't understand why you feel free to quote it in public now. That kind of seems to subvert the purpose of deleting it...

If you want to censor my posts, fine, but then _you_ cary the full responsibility for it. You cannot make me an accomplish by forcing me to change my own post in ways which I fundamentally disagree. The moderaters might have a policy w.r.t. censorship, but I have my own. And if these policies are mutually incompatible, we should draw the consequences. I am _not_ going to type long posts if they can be entirely deleted at a whim of the moderators.

No bad feelings, just logic.

[Graham Banks]

No bad feelings

Good. I hope you'll continue to contribute here.
I have no wish to cause any ill feeling.

Regards, Graham.