Time control - ineffective use of incremental time

[cyberfish]

I am trying to implement time management as per the time management page on the chessprogramming wiki
http://chessprogramming.wikispaces.com/Time+Management

The scheme proposed there is to simply divide the remaining time by a constant (for now we can ignore things like easy moves and fail-low time extension), which should work well for time controls without increment.

However, for time controls with increment, I think it doesn't effectively use the incremental time.


For example, if the divisor constant is 10 (just to make it easier to calculate), and the time control is 60 seconds + 10 seconds after each move.

The first move will take
60 seconds / 10 = 6 seconds

second move will take
64 seconds (54+10) / 10 = 6.4 seconds

third move will take
67.6 seconds / 10 = 6.76 seconds

As a net result, the time remaining will be increasing slowly, until there is 100 seconds on the clock, then it will stay there (since 10 seconds is used for each move, and 10 sec is added after each move).

What do people do with incremental time?

I am thinking about doing
time_for_move = (time_remaining / constant) + inc

What do you think?

[krazyken]

One thing to watch out for is that the increment is added AFTER the move.
Say you have 10 secs left with your 10 sec increment, would you allocate 10/10 + 10 = 11 secs?

[Zach Wegner]

What do people do with incremental time?

I am thinking about doing
time_for_move = (time_remaining / constant) + inc

Yes, that is much closer to current practice. The CPW page is talking about fixed (sudden death) time controls. Obviously you should use a bit more for increments. ZCT uses only part of the increment so that it can build up some time if it's low, and isn't always using more than the increment. IIRC the formula right now is:

time_for_move = (time_remaining / 24) + inc * 3/4;

[cyberfish]

Ah great! Thanks!

[Harald Johnsen]

One thing to watch out for is that the increment is added AFTER the move.
Say you have 10 secs left with your 10 sec increment, would you allocate 10/10 + 10 = 11 secs?

Whatever the way you compute it, it is good practive to verify that you don't use more than you have, plus you must keep a lag margin.

So you want to allocate 11 seconds, you reduce that to 10 (the max you have), then you subtract the lag (500 ms to 1000ms if you don't do lightspeed games). So you really want to use 9.5 seconds here even if you computation gives you 11 seconds.

HJ.

[hgm]

In micro-Max I guarantee the safety margin by always calculating 2 target times: one that I need to not overrun time in the next move, and one for not jeopardizing the quality of all subsequent moves. I then use the minimum of the two.

In uMax, where the search time is extremely variable, because it always finishes an iteration, once its starts it, the target time (after which I do not start a new iteration) must be at most 10% of the remaining time on the clock, or there is a significant probability that it will forfeit on time with the current move. On average it uses about 1.5 times as much time as this target time, but the distribution has a very long tail towards long thinking times.

For the long-run target, you can assume that thegame will last 40 more moves, so that you have timeLeft + 40*timeInc, and that you want on the average to spend 4% of that remaining time on the next move. So you get targetTime = 0.04*(timeLeft+40*timeInc)/1.5.

This works for any incremental time control, whether the increment is zero (sudden death), or most of the time must come from the increment.