Winboard Forum

I have problems to implement time management under the UCI protocol

The problem is that based on reading the uci protocol it seems that the interface does not give me enough information.

It only gives me time and number of moves to the next time control and it is simply not enough for smart time managament.

In case of time control of 2 hours/40 moves+1 minutes for the rest of the game it is going to be stupid to use all the 2 hours for the first 40 moves when in case of time control of 2 hours/40 moves
that repeat itself it is not going to be stupid to do it.

The problem is that based on the information that the engine get based on the uci protocol the engine is totally blind to what is going to happen after move 40 and it cannot know if it is going to have a lot of time or going to have no time so it cannot use smart time management.

Uri

Uri,

You are correct - this is indeed a weakness of the UCI protocol. However, for most 'sensible' time controls it works fine i.e. 2 hours/40 moves+1 minutes is not sensible time control. IMO it's a small weakness that is never a real problem.

Regards,

Steve

I don't see any weakness in the UCI protocol here. You're never know if you reach 40th moves. May there are difficult positions where you should use more time.

If you now creating a reserved "pool" time because you're allready know there is a sudden death tc after 40 moves you don't have this time.

In my view who doing here special stuff, like creating this pool, has a stupid timemanagement.

Best,
Daniel

Daniel Mehrmann wrote:I don't see any weakness in the UCI protocol here. You're never know if you reach 40th moves. May there are difficult positions where you should use more time.

If you now creating a reserved "pool" time because you're allready know there is a sudden death tc after 40 moves you don't have this time.

In my view who doing here special stuff, like creating this pool, has a stupid timemanagement.

Best,
Daniel

In my case I simply calculate the time that I have for 40 moves and the time that I have for all the game
For both cases I get target_time to use and I decide to use the smaller number.

I do the same also if I have 40/40+40/40 forever
at move 20 I calculate the target time assuming that I have on time control for only moves 21-40
calculate the target time assuming that I have only on time control
for moves 21-80 and continue in that way until the target time increase.

Note that at some point the target time starts to increase and
60 minutes/60 moves certainly means smaller target time than 100 minutes/100 move because I do not divide by 60 or by 100 to calculate the target time but divide by smaller number
and I have a special function to calculate that smaller number(it get closer to the target time that I have for 60 minutes for all the game when the number of moves get closer to infinite).

Note that I assume that if the target time starts to increase it is not going to go down to be smaller than the minimal time that I found(this assumption is not always correct
but I decided that I do not like to spend more time in calculating
the target time for the rare theoretical case that it is not correct).

Uri

Daniel Mehrmann wrote:I don't see any weakness in the UCI protocol here. You're never know if you reach 40th moves. May there are difficult positions where you should use more time.

If you now creating a reserved "pool" time because you're allready know there is a sudden death tc after 40 moves you don't have this time.

In my view who doing here special stuff, like creating this pool, has a stupid timemanagement.

Best,
Daniel

Sorry Daniel, I disagree here.
It is very well possible that you have saved time during the game due to ponder hits, forced moves, long book lines etc.
If you have 15 minutes time left due to this while only 1 move has to be made before time control and the next time control is a 30 minute sudden death, is it smart to use up 15 minutes, or should you save some time for the sudden death phase? I think you should do the last. Suppose the nearest time control would not be there, but instead you already add the time of the next time control. How much time would you spend then? It doesn't feel right to me to spend more time when the only difference is that you have an additional chance of being flagged ...
So I always consider two limits: The nearest time control and the next time control where I pretend the first time control does not exist. I calculate time limits for both time controls, and use the one that uses the least amount of time.
To handle the case where the next time control is e.g. 80 moves away, I'm also alway comparing the limits with the ones I would chose if the time control would be the last one (i.e. game has to finish within the remaining time). It would be weird to spend less time on a move on a recurring time control than on a sudden death one (with same amount of time on the clock).

So I really see the need for knowing at least the next time control.
Richard.

Daniel Mehrmann wrote:I don't see any weakness in the UCI protocol here. You're never know if you reach 40th moves. May there are difficult positions where you should use more time.

...

Best,
Daniel

That's simply statistically wrong. If you look at computerchess
databases(non bullet) you'll notice that around 85% of the games
are longer than 40 moves and that the average length is somewhere
between 63-68 moves.
This means we 'know' the game will most likely take longer than 40
moves, thus I don't think it is 'stupid' to reserve some pool time,
but without knowing what happens after move 40 it is difficult
to know how much.


Regards,
Guenther

Steve Maughan wrote:Uri,

You are correct - this is indeed a weakness of the UCI protocol. However, for most 'sensible' time controls it works fine i.e. 2 hours/40 moves+1 minutes is not sensible time control. IMO it's a small weakness that is never a real problem.

Just look at the last few moves before a time control. Suppose the engine was able to save a lot of time by ponder hits, long book line, force/easy moves etc. In a 2h/40+1h time control (which was once the tc at the IPCCC in Paderborn), we're at move 38 with 30 minutes still available.
I would not like my engine to use 30 minutes in the remaining 2 moves before the time control. That might very well throw away the carefully saved time and the engine will need to move significantly faster once this time is spent.
Richard.

Richard,I think that you did good job of explaining the practical importance of it.

I can describe myself more as a mathematician than as a programmer
so I think that it was natural for me to think about extreme cases that are not practical but of course the problem is also practical problem.

I think that for UCI I will simply assume always level of the type 40/40+40/40 forever if I get number of moves to go to the next time control.

Note that it is not trivial for me to implement UCI support also because of a bad choice of functions to calculate information like information about the target time and the function are based on strings that I got from the interface so practically I cannot use my existing functions for UCI when the strings are different.

I think that it is probably better first to translate all the strings to numbers and call function to calculate information about target_time based on the numbers so later I can support other interfaces more easily because the numbers are the same for all interfaces and I will only need to add a function that translate strings to numbers.

Uri

Hi Richard,

well, theoretically your view sounds logical. But how often comes this in practise ? How much ELO points do you gained ?
I think you gained nothing in practise. In your example, you only must search one move to next tc, may it can be a capture too So my engine wouldn't use full planned time anyway.

I think its just overkill to look at next possible tc, but i accept your points of course (Uri too).

Much more interesting is how accurate your clocks are versus your opponent clock.

Best,
Daniel

Daniel Mehrmann wrote:Hi Richard,

well, theoretically your view sounds logical. But how often comes this in practise ? How much ELO points do you gained ?
I think you gained nothing in practise. In your example, you only must search one move to next tc, may it can be a capture too So my engine wouldn't use full planned time anyway.

It's hard to quantify this as I never really use more than a single time control myself. The only tournament I participated in that had multiple time controls was the one in Paderborn some time ago. I remember a game against SOS where both the Baron and SOS saved quite a bit of time. And I was glad it did, because it turned out to be a long game that the Baron eventually won.

Daniel Mehrmann wrote:I think its just overkill to look at next possible tc, but i accept your points of course (Uri too).

Much more interesting is how accurate your clocks are versus your opponent clock.

That is something that I do as well. When ahead in time, spend a little extra time. This can be turned configured ('useotime') in the baron.ini file.
Richard.

Daniel,
if we lose only 1 ratingpoint due to lack of information in uci there is a problem with the protocol. It can be the difference of winning a tourment or not. The protocol should ideally not affect the result in any way at all.
/Peter

Peter Fendrich wrote:Daniel,
if we lose only 1 ratingpoint due to lack of information in uci there is a problem with the protocol. It can be the difference of winning a tourment or not. The protocol should ideally not affect the result in any way at all.
/Peter

The problem is not only this

The problem is that the UCI protocol is not clear

Instead of the level command I get only the following commands

* wtime <x>
white has x msec left on the clock
* btime <x>
black has x msec left on the clock
* winc <x>
white increment per move in mseconds if x > 0
* binc <x>
black increment per move in mseconds if x > 0
* 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

problems:
1)What should I do if movei as white get something like
movestogo 20 winc 10
Can I assume that the interface will never send it?

2)I do not have level command and without level command movei has no function that tell it how much time to use(under winboard I simply calculate some parameters like number of moves in every time control from the level command and based on them decide about the target time).

I can translate the first go to level command but the main question is when to assume that I get another level command

Should I assume that I get another level command if movestogo or winc or binc are different than what I expect
should I assume that I get another level command after movei change sides because undo command or maybe I should assume that I get another level command only if the increasement is different for both sides.

possible soultion is simply to have level_uci command that get only
the times, the increasements and the moves to go to the next time control but I do not like to have different time management for winboard and for uci and I prefer the uci option to assume something like assuming that if you get x minutes/(y-n) moves in the first go at move n+1 it is going to continue forever
x minutes/y moves.

The problem is that I am afraid of more bugs if I try to implement something like that when there may be unexpected input that may cause problems that I did not think about.

What do you suggest to do?

Uri

Uri Blass wrote:

Peter Fendrich wrote:Daniel,
if we lose only 1 ratingpoint due to lack of information in uci there is a problem with the protocol. It can be the difference of winning a tourment or not. The protocol should ideally not affect the result in any way at all.
/Peter

The problem is not only this

Yes I know. I just answered Daniel about the problem with a protocol affecting the result.

The problem is that the UCI protocol is not clear

Instead of the level command I get only the following commands

* wtime <x>
white has x msec left on the clock
* btime <x>
black has x msec left on the clock
* winc <x>
white increment per move in mseconds if x > 0
* binc <x>
black increment per move in mseconds if x > 0
* 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

problems:
1)What should I do if movei as white get something like
movestogo 20 winc 10
Can I assume that the interface will never send it?

I suppose that if the GUI sends this it is a bug but Alaric will use wtime 0 in this case.

2)I do not have level command and without level command movei has no function that tell it how much time to use(under winboard I simply calculate some parameters like number of moves in every time control from the level command and based on them decide about the target time).

I can translate the first go to level command but the main question is when to assume that I get another level command

I don't think that is a good idea. The first go is not necessarily using the same time setting as the next. The UCI protocol is stateless and you can never assume that you receive the continuation from the ongoing game. The level command is not appropriate in this sense...

Should I assume that I get another level command if movestogo or winc or binc are different than what I expect
should I assume that I get another level command after movei change sides because undo command or maybe I should assume that I get another level command only if the increasement is different for both sides.

I think you must recompute your "level" before computing each move.

possible soultion is simply to have level_uci command that get only
the times, the increasements and the moves to go to the next time control but I do not like to have different time management for winboard and for uci and I prefer the uci option to assume something like assuming that if you get x minutes/(y-n) moves in the first go at move n+1 it is going to continue forever
x minutes/y moves.

The problem is that I am afraid of more bugs if I try to implement something like that when there may be unexpected input that may cause problems that I did not think about.

What do you suggest to do?
Uri

This is why I skipped the winboard protocol in Alaric. UCI and Winboard are not fully compatible and it will always be a source of problems. I have them in Terra...
/Peter

Peter Fendrich wrote:Daniel,
if we lose only 1 ratingpoint due to lack of information in uci there is a problem with the protocol. It can be the difference of winning a tourment or not. The protocol should ideally not affect the result in any way at all.
/Peter

Hi Peter !
You're right of course.
My question is if you do test matches with movei with timecontrol 40/40 + 20/20 + 0/30 and one version used wb2 and the other version used UCI protocol, how many ELO points is wb2 movei better than uci movei based on a better timemanagenent ?

I guess 0 points. My point is that you have no benefit of the level command at general.

Best,
Daniel

ps: If Movei UCI is ready i will do such tests vs Homer, which used same timemanagent on both protocols (backend core identical, i'm just remapping values).

Daniel Mehrmann wrote:

Peter Fendrich wrote:Daniel,
if we lose only 1 ratingpoint due to lack of information in uci there is a problem with the protocol. It can be the difference of winning a tourment or not. The protocol should ideally not affect the result in any way at all.
/Peter

Hi Peter !
You're right of course.
My question is if you do test matches with movei with timecontrol 40/40 + 20/20 + 0/30 and one version used wb2 and the other version used UCI protocol, how many ELO points is wb2 movei better than uci movei based on a better timemanagenent ?

I guess 0 points. My point is that you have no benefit of the level command at general.

Best,
Daniel

ps: If Movei UCI is ready i will do such tests vs Homer, which used same timemanagent on both protocols (backend core identical, i'm just remapping values).

Movei UCI is still not ready and the problem is that I am not sure what assumption I should assume about the level command.

I can simply divide 2 numbers to calculate the target time and to add increasement in case that there is an increasement but I have a lot of code exactly not to do it in that stupid way and one of the reasons that I started chess programming is that I considered chess programs to be stupid and this is one example.

There are other things that I consider chess programs to be stupid when movei is not smarter and I may make it smarter only after rewriting it.

I guess that in the specific time control that you plan to use it is not very important but it can be important in different type of time control.

Uri