Back Up Next

Time Allocation

Time allocation is important, because if you spend more time at appropriate moments, it is like having a faster processor at those moments, and having a faster processor is a good thing.

I'm not going to go into a lot of detail here, because I don't think a lot is warranted.  I think that if I just mention a few things, people can get a few ideas about how to handle this problem.

General considerations

All commonly used time controls allow you to decide if you want to spend more time on this move, or save it up for later.  I think that it makes most sense to spend a little more time now, rather than saving it up, because you'd feel pretty silly if you achieved a lost position with 75% of your time left.

Another obvious suggestion is that the program think especially long the first few moves out of book.  Very often a program will come out of book in a position it doesn't understand very well, and the hope is that giving it an extra dose of time in these cases might prevent it from making an immediate decisive error.

Another place to add time is when the program is failing low.  If you've thought for several minutes about a position, and suddenly the score starts to drops for the move you plan to make, you don't want to make this move just because you've run out of time.  Spending more time, in order to try to find a better move, seems to make a lot of sense.

Sometimes you might want to subtract time.  Some programs instantly move once they find that they are checkmating the opponent.  Other times you might want to move more quickly if you are making an obvious recapture.

Tournament time control

The traditional tournament chess time control is X moves in Y minutes.  Some number of moves, typically 30 or 40, and some number of minutes, which can be anything.  A long club game might be 40 moves in 90 minutes.

The most obvious stab at designing a time control system involves simply dividing the time by the number of moves, and thinking for that amount of time regardless.  So, if you have 30 moves to make in 30 minutes, you think for one minute each time.  You can also keep some reserve time, or try to use more time up front.

It is very tricky to implement this properly.  Is you sometimes make instantaneous moves after pondering,  you will accumulate time.  This saved time is used on subsequent moves, so if you are not careful, you will spend more time thinking about later moves than you did about earlier ones.  If this is what you want, no problem, but this doesn't sound right to me.  I don't think that you want to spend five minutes a piece on the last four moves until time control, if you spent one minute each on the first four.

Sudden-death time control

A sudden-death time control can be handled by always considering that X moves always remain until the time control.  Let's say that you pick the number 30 as X.  You'll use about 1/30 of your remaining time on the first move.  When it's time to move again, you'll use 1/30 of the remaining time again.  This works rather well in practice.  You move faster and faster as the game goes on, which is probably what you should do anyway.

So this is a lot easier to implement than the tournament time control logic.

Fischer time control

Fischer time control implementation is very tricky.  In my own program, I set a target time that I would like to "hover" around.  If I'm above this amount of time now, I'll use the full increment and then some.  This will cause me to drift toward the hover time.  If I'm under the hover time, I use less than the full increment, so my program will tend to slowly accumulate time.

The tricky parts are selecting a hover time that makes sense given the time control, and creating a system that uses roughly the same amount of time per move.

 
Send mail to brucemo@seanet.com with questions or comments about this web site.
Copyright © 2001 Bruce Moreland
Last modified: 01/24/03