ambiguous UCI protocol question

[Don]

I found something in the UCI protocol that seems a bit ambiguous to me. It has to do with the how time is sent to the engines.

The spec says that you send the remaining time and the increment. For instance:

go wtime 10000 winc 1000

which means 10 seconds left on the clock, and the increment is 1 second.

However, fischer time control specifies that the time is added to the clock BEFORE the move is made.

So what should a program assume and what should a user interface send? There are 2 possibilities:

1. Just before searching, the user interface adds the increment to the total remaining time and sends this as the wtime (or btime).

2. The user interface sends the time remaining BEFORE the move and the engine can add the increment to determine how much total time is remaining.

I believe 1 is correct, because UCI says that wtime or btime represents the time left on the clock, and this is added BEFORE the move is played according the fischer clock rule. But it's not 100% clear to me.

Does anyone have a definitive answer to this?

[Gian-Carlo Pascutto]

Are you sure that Fischer time adds time before the move?

[alpha123]

I found something in the UCI protocol that seems a bit ambiguous to me. It has to do with the how time is sent to the engines.

The spec says that you send the remaining time and the increment. For instance:

go wtime 10000 winc 1000

which means 10 seconds left on the clock, and the increment is 1 second.

However, fischer time control specifies that the time is added to the clock BEFORE the move is made.

So what should a program assume and what should a user interface send? There are 2 possibilities:

1. Just before searching, the user interface adds the increment to the total remaining time and sends this as the wtime (or btime).

2. The user interface sends the time remaining BEFORE the move and the engine can add the increment to determine how much total time is remaining.

I believe 1 is correct, because UCI says that wtime or btime represents the time left on the clock, and this is added BEFORE the move is played according the fischer clock rule. But it's not 100% clear to me.

Does anyone have a definitive answer to this?

I think 1 is correct also, but probably do something like email SMK just to make sure.

Peter

EDIT: @GCP: Yeah, it adds before. http://en.wikipedia.org/wiki/Game_clock#Time_controls

[Don]

Are you sure that Fischer time adds time before the move?

I'm not sure, but according to wikipedia it does. Of course that doesn't make it so.

[Don]

I think possiblity one is more logical too, and that is how my tester implements it. The winc/binc tokens are necessary for the engine to manage it's time better and it almost seems like an overloaded field if it also represents part of the current moves total accumulated time.

I found something in the UCI protocol that seems a bit ambiguous to me. It has to do with the how time is sent to the engines.

The spec says that you send the remaining time and the increment. For instance:

go wtime 10000 winc 1000

which means 10 seconds left on the clock, and the increment is 1 second.

However, fischer time control specifies that the time is added to the clock BEFORE the move is made.

So what should a program assume and what should a user interface send? There are 2 possibilities:

1. Just before searching, the user interface adds the increment to the total remaining time and sends this as the wtime (or btime).

2. The user interface sends the time remaining BEFORE the move and the engine can add the increment to determine how much total time is remaining.

I believe 1 is correct, because UCI says that wtime or btime represents the time left on the clock, and this is added BEFORE the move is played according the fischer clock rule. But it's not 100% clear to me.

Does anyone have a definitive answer to this?

I think 1 is correct also, but probably do something like email SMK just to make sure.

Peter

EDIT: @GCP: Yeah, it adds before. http://en.wikipedia.org/wiki/Game_clock#Time_controls

[diep]

Are you sure that Fischer time adds time before the move?

100%

I have a clock here if you want to see it

The idea then is that players then easier can see at which time control the clock has been set.

Vincent

[Sven]

I found something in the UCI protocol that seems a bit ambiguous to me. It has to do with the how time is sent to the engines.

The spec says that you send the remaining time and the increment. For instance:

go wtime 10000 winc 1000

which means 10 seconds left on the clock, and the increment is 1 second.

However, fischer time control specifies that the time is added to the clock BEFORE the move is made.

So what should a program assume and what should a user interface send? There are 2 possibilities:

1. Just before searching, the user interface adds the increment to the total remaining time and sends this as the wtime (or btime).

2. The user interface sends the time remaining BEFORE the move and the engine can add the increment to determine how much total time is remaining.

I believe 1 is correct, because UCI says that wtime or btime represents the time left on the clock, and this is added BEFORE the move is played according the fischer clock rule. But it's not 100% clear to me.

Does anyone have a definitive answer to this?

For me it is clearly 1 because 2 would be illogical for me: it would imply that the user interface would *never* add the increment, so the engine would have to add N*inc internally, for N being the number of moves played so far. Effectively the user interface would ignore the increment, and eventually call the flag although there is still much time left on the clock. This is not what happens, though, so for me 2 must be wrong.

The only question left for me is whether adding the increment is also applied before the very first move of the game. The FIDE rules say (6.2a):

"When using a chess clock, each player must make a minimum number of moves or all moves in an allotted period of time and/or may be allocated an additional amount of time with each move."

The question is what "with each move" means: is the additional time available already before or only after making the move? "Before" would be logical for me. But I'm not sure how it is really handled.

Isn't it possible to simply test what UCI GUIs do really send as wtime/btime for the very first move of the game if you specify 10+1 time control?

Sven

[Don]

I found something in the UCI protocol that seems a bit ambiguous to me. It has to do with the how time is sent to the engines.

The spec says that you send the remaining time and the increment. For instance:

go wtime 10000 winc 1000

which means 10 seconds left on the clock, and the increment is 1 second.

However, fischer time control specifies that the time is added to the clock BEFORE the move is made.

So what should a program assume and what should a user interface send? There are 2 possibilities:

1. Just before searching, the user interface adds the increment to the total remaining time and sends this as the wtime (or btime).

2. The user interface sends the time remaining BEFORE the move and the engine can add the increment to determine how much total time is remaining.

I believe 1 is correct, because UCI says that wtime or btime represents the time left on the clock, and this is added BEFORE the move is played according the fischer clock rule. But it's not 100% clear to me.

Does anyone have a definitive answer to this?

For me it is clearly 1 because 2 would be illogical for me: it would imply that the user interface would *never* add the increment, so the engine would have to add N*inc internally, for N being the number of moves played so far. Effectively the user interface would ignore the increment, and eventually call the flag although there is still much time left on the clock. This is not what happens, though, so for me 2 must be wrong.

The only question left for me is whether adding the increment is also applied before the very first move of the game. The FIDE rules say (6.2a):

"When using a chess clock, each player must make a minimum number of moves or all moves in an allotted period of time and/or may be allocated an additional amount of time with each move."

The question is what "with each move" means: is the additional time available already before or only after making the move? "Before" would be logical for me. But I'm not sure how it is really handled.

Isn't it possible to simply test what UCI GUIs do really send as wtime/btime for the very first move of the game if you specify 10+1 time control?

Sven

I don't have access to many UCI GUI's, and there is no guarantee that the ones I would be looking at are correct. I'm a bit anal about making software with bugs on purpose for compatibility, I don't want to do this. I want to know what the right way is, not how some GUI implements it.

[Richard Allbert]

Interesting point... not just for UCI

I've just corrected a time loss bug at fast time controls, because I was allocating time/30 + inc, and loosing on time e.g for time control 10s + 1s

The engine would have 0.3s left, and allocate 1.03s for the move, and lose on time, ( in winboard ) - so I think there the time was being added after the move. Since removing the + inc the problem has gone.

I've just tried WB to check, and it adds the inc after the move is played.

[Don]

Interesting point... not just for UCI

I've just corrected a time loss bug at fast time controls, because I was allocating time/30 + inc, and loosing on time e.g for time control 10s + 1s

The engine would have 0.3s left, and allocate 1.03s for the move, and lose on time, ( in winboard ) - so I think there the time was being added after the move. Since removing the + inc the problem has gone.

I've just tried WB to check, and it adds the inc after the move is played.

Regardless of which is correct, your engine should assume the worst. Defensive programming