Sudden death time controls

[lkaufman]

When playing sudden death games, say game/5', with NO INCREMENT, traditionally I think most programs just set goal time to X% of remaining time per move. We still do so in Komodo, not having researched these time controls too much as the testing organizations don't use them. I haven't even checked open-source programs to see what they do. What is the state-of-the-art on this? Has anyone come up with a better algorithm than this crude but reasonable rule? It seems there should be one, but it's not so obvious.

[Mincho Georgiev]

It's much more complicated than just x% of the time, because you will have a very high number of unfinished iterations that way.
What I do (and probably others) is to use time boundaries. One for the absolute maximum allowed (which can be considered for the X%
that you mention, just bigger) and one for the regular slice. If you accomplish the "regular" boundary but the iteration isn't finished yet,
you keep going until the max boundary is reached. On the other hand, if you have let say 70% of the regular finished, don't go for new iteration,
unless something bad is happening (or whatever you decide) - if you do that, use the max boundary.
You have a wide variety with this method and you can choose what part of the max to use and when and so on.

Best Regards!

[hgm]

It's much more complicated than just x% of the time, because you will have a very high number of unfinished iterations that way.

Note that Larry proposes to set the goal time to a fraction of the remaining clock time, not a fixed or maximum time per move. So he is already doing everything you say. The question is just how to globally distribute the available time over the game.

I use remaining time / 30, but I admit this is rather course. (But I don't care much for sudden-death TC, so I never considered it worth the effort to improve on this.) An obvious refinement would be to make the fraction dependent on the game phase. It should be easy to compute the average remaining duration of a game (until the point where the game get decided, e.g. where abs(QS) > 200cP) as a function of the game phase, on a database of computer games.

Probably more important is to watch the opponent time. If your opponent thinks just a little bit faster than you (say 5% faster), near the end of a long sudden-death game, you get in a situation where he can have 2 or 3 times as much time left on his clock. At that point he will outsearch you by 1 or 2 ply, which is a very dangerous situation. It could have been easily avoided by also thinking 5% shorter, which would not have hurt you much.

So in Joker I keep track of the ratio of opponent time and own time, and if it climbs above 1.5, I apply a reduction of ~20% to the goal time.

[Uri Blass]

When playing sudden death games, say game/5', with NO INCREMENT, traditionally I think most programs just set goal time to X% of remaining time per move. We still do so in Komodo, not having researched these time controls too much as the testing organizations don't use them. I haven't even checked open-source programs to see what they do. What is the state-of-the-art on this? Has anyone come up with a better algorithm than this crude but reasonable rule? It seems there should be one, but it's not so obvious.

personally I use in movei expected moves to finish the game or the next time control based on my memory(I did not work on movei in the last years and did not look at the source at the time of this post).

The idea is that if I expect long game I want to use less time to keep time for the next moves.

I am sure my function to evaluate expected number of moves to finish the game can be improved but I basically had 2 rules.

1)I expect less moves to finish the game in pawn endgames.

2)I expect less moves to finish the game when one side has a big advantage(at least 2 pawns)

I think that it may be productive also to use more time when you are close to draw by the fifty move rule.

Note that I do not think that you can get a big elo improvement in repeating time control like the CEGT or the CCRL use thanks to using more time when you expect the game to be finished faster than the number of the remaining moves but my guess is that you can get 1-5 elo improvement even at that time control.

I believe that using the opponent time can be also a good idea for sudden time control.

I believe that if you see that the opponent has a time advantage then it may be a good idea to play faster and that if you see that you have a time advantage then it may be a good idea to play slower(at least in ponder off games)

I am not sure if the same is correct for ponder on games.

[Mincho Georgiev]

It's much more complicated than just x% of the time, because you will have a very high number of unfinished iterations that way.

Note that Larry proposes to set the goal time to a fraction of the remaining clock time, not a fixed or maximum time per move. So he is already doing everything you say. The question is just how to globally distribute the available time over the game.

Thanks for clarifying, my bad.

[zamar]

When playing sudden death games, say game/5', with NO INCREMENT, traditionally I think most programs just set goal time to X% of remaining time per move. We still do so in Komodo, not having researched these time controls too much as the testing organizations don't use them. I haven't even checked open-source programs to see what they do. What is the state-of-the-art on this? Has anyone come up with a better algorithm than this crude but reasonable rule? It seems there should be one, but it's not so obvious.

Stockfish allocates thinking time based on current move number and statistics of "how many games are still undecided after n moves".

If I remember correctly this system gave around +10 elo boost in most time controls compared to old Glaurung time management system.

[Evert]

I think I use "remaining time / N" as the target time for the current move, with some ad-hoc way of picking the number of remaining moves N.
One way I thought to change this is t internally handle it as "N moves in M seconds" followed by "K moves in L seconds" followed by "all remaining moves in J seconds", with M+L+J adding up to the total time. The reason for doing that would be to emulate a more standard time-control for which I do most of my own testing (I don't really care for sudden-death time control), but I could also go for a Fischer-like time control until the pool of remaining time has become small enough that it's better to switch to "remaining time / N".

Haven't tested any of this though.

[lkaufman]

When playing sudden death games, say game/5', with NO INCREMENT, traditionally I think most programs just set goal time to X% of remaining time per move. We still do so in Komodo, not having researched these time controls too much as the testing organizations don't use them. I haven't even checked open-source programs to see what they do. What is the state-of-the-art on this? Has anyone come up with a better algorithm than this crude but reasonable rule? It seems there should be one, but it's not so obvious.

Stockfish allocates thinking time based on current move number and statistics of "how many games are still undecided after n moves".

If I remember correctly this system gave around +10 elo boost in most time controls compared to old Glaurung time management system.

That is an interesting idea, as is also the suggestion to modify goal time by oppoent's time. One thing about the idea is not clear to me; are you saying that the percentage of REMAINING time to use, or of INITIAL time, is based on the stats? If you use remaining time, the amount of time left already decays more or less in line with those stats, so this seems illogical to me. But if you use initial time, how do you modify your time use based on time actually used? In other words, both ways seem wrong to me. I'm sure you found a good solution to this.
Now that I think about it, perhaps you take the expected number of remaining moves given the current move number, and divide remaining time by that number. Is that correct? So if it is move ten, and the average number of remaining moves from move ten in the database is forty, you would divide total time by 40. I suppose you measure remaining moves until someone is up by perhaps 2 pawns or so, not until resignation.

[zamar]

Now that I think about it, perhaps you take the expected number of remaining moves given the current move number, and divide remaining time by that number. Is that correct? So if it is move ten, and the average number of remaining moves from move ten in the database is forty, you would divide total time by 40.

Yes, that's how it goes in nutshell!

I suppose you measure remaining moves until someone is up by perhaps 2 pawns or so, not until resignation.

Exactly!

[Uri Blass]

Now that I think about it, perhaps you take the expected number of remaining moves given the current move number, and divide remaining time by that number. Is that correct? So if it is move ten, and the average number of remaining moves from move ten in the database is forty, you would divide total time by 40.

Yes, that's how it goes in nutshell!

I suppose you measure remaining moves until someone is up by perhaps 2 pawns or so, not until resignation.

Exactly!

I think that using only the move number to decide about expected number of moves to finish the game is not the best idea when there are other factors like the evaluation of the position.

Examples:
I expect more moves when stockfish has a small advantage and not when stockfish has a big advantage and I expect less moves when there are already 49 moves without capture or pawn moves and the evaluation is 0.00

If other factors are the same I expect more moves when there is more material on the board even if we have the same move number.

Did you try to use other factors and failed to get an improvement?