UCI protocol movestogo

[lucasart]

From Stefan MK's UCI protocol definition:

Code: Select all

* movestogo <x>
    there are x moves to the next time control,
    this will only be sent if x > 0,
    if you don't get this and get the wtime and btime it's sudden death

Now let's assume
- you play a time control like 40/x (x minutes per 40 moves, repeating)
- it is your turn to play move #40, and you have 10 seconds left on the clock
- you play white
The UCI interface will therefore send you this command:

go wtime 10000

The problem is that:
- you hsould *use* all the 10 seconds (minus a buffer to allow for lag), because your clock will be credited some extra time after this move.
- but what if the time control is actually a blitz time control, rather than a tournament time control ? If it's like 5'+0" and you have 10" left, you shouldn't use 10 seconds for the move, as you'll have nothing left for the rest of the game!

When I implemented the movestogo command, I never knew how to deal with that situation. Typically I make the conservative assumption that "go wtime ... [winc] ..." is interpreted as though it was blitz tc in the absence of a movestogo. But that means that I play way too fast at move #40, #80 etc. And sometimes lose the game because of that.

Is it a bug of the UCI protocol ? How does one get around it ?

[hgm]

In a sudden-death control like 5'+0 the interface would of course not send movestogo 1. Why do you even think it would? That would be plain lying, because there still is the entire game to go.

In UCI, the presence of movestogo implies classical TC, which will give you new time after that number of moves. Absence of movestogo implies sudden-death / incremental. For fixed time per move there is movetime.

The deficiency of the protocol is that it does not tell you how much new time. If it says wtime 119999 movestogo 1 it could be because you are playing 20moves/2min, and came out of book after 19 moves. So basically you have 4 min for the next 21 moves, and the engine might use half of it for the first of those. Which is far from optimal use of the time.

I guess you could solve this by counting moves loaded into the engine (and paying attention to the move-number field of the FEN, if present).

[lucasart]

In a sudden-death control like 5'+0 the interface would of course not send movestogo 1. Why do you even think it would? That would be plain lying, because there still is the entire game to go.

In UCI, the presence of movestogo implies classical TC, which will give you new time after that number of moves. Absence of movestogo implies sudden-death / incremental. For fixed time per move there is movetime.

Thank you for the clarification. So it should send "movestogo 1" in the case I described.

The deficiency of the protocol is that it does not tell you how much new time. If it says wtime 119999 movestogo 1 it could be because you are playing 20moves/2min, and came out of book after 19 moves. So basically you have 4 min for the next 21 moves, and the engine might use half of it for the first of those. Which is far from optimal use of the time.

Good point.

I guess you could solve this by counting moves loaded into the engine (and paying attention to the move-number field of the FEN, if present).

Hum... That's kind of ugly... But the only way to get around it, I suppose.

[Don]

From Stefan MK's UCI protocol definition:

Code: Select all

* movestogo <x>
    there are x moves to the next time control,
    this will only be sent if x > 0,
    if you don't get this and get the wtime and btime it's sudden death

Now let's assume
- you play a time control like 40/x (x minutes per 40 moves, repeating)
- it is your turn to play move #40, and you have 10 seconds left on the clock
- you play white
The UCI interface will therefore send you this command:

go wtime 10000

The problem is that:
- you hsould *use* all the 10 seconds (minus a buffer to allow for lag), because your clock will be credited some extra time after this move.
- but what if the time control is actually a blitz time control, rather than a tournament time control ? If it's like 5'+0" and you have 10" left, you shouldn't use 10 seconds for the move, as you'll have nothing left for the rest of the game!

When I implemented the movestogo command, I never knew how to deal with that situation. Typically I make the conservative assumption that "go wtime ... [winc] ..." is interpreted as though it was blitz tc in the absence of a movestogo. But that means that I play way too fast at move #40, #80 etc. And sometimes lose the game because of that.

Is it a bug of the UCI protocol ? How does one get around it ?

No, there should NEVER be less than one moves to go. If you are on the last move you have 1 move to go, then the next move will show 40 moves to go (assume 40 moves in X time control).

Don