hgm wrote:OK, I am returning to this topic, as I have now implemented the user interface for setting secondary time controls in WinBoard. The WinBoard clock seems to follow the instructions flawlessly, allowing any number of sessions (where the last one is either sudden-death/incremental or a classical one repeated as often as needed).
But this still leaves the question of how to send it to the engines.
bob wrote:Crafty just takes it at the instant it arrives and "plugs it in".
Unfortunately, this is not unambiguous. There are two obvious ways that time controls could be implemented. Either the engine keeps track of the move number, and awards new time quota each time moveNumber % movesPerSession == 0. The other way is to maintain a countdown counter, and reset it to movesPerSession (and award new time if you don't want to rely on the GUI handing it to you). Some engines even seem to decrement the countdown on moves that they actually find through search (ignoring forced moves), which is totally wrong, but nevertheless very common amongst WB engines.
Just "plugging it in" as it arrives (i.e. overwrite the movesPerSession) has a completely different effect in the two cases. If the first session has 40 moves, and the second 25, the first strategy would expect the time handed to it each move should last to move 50, the other to 65. Which one would Crafty expect?
But for real winboard/xboard matches, I don't much care about the values since I get time updates after each and every move anyway. For me, that would be an acceptable way of handling secondary time controls except for one detail.
Given the choice of 40/120, 20, 60 and game/30, which is not that uncommon, I want to know the entire set up front. For a more conventional rapid-type time control,
60,60 game/30
I don't want to find out about the game/30 after the first 60 moves have elapsed, as I would probably have allocated time differently if I knew that any time saved from the first time controll would be added into a sudden-death time control where every second might be critical...
Here's the problem as I see it, discussing two different aspects separately:
(1) what is the time control? I use this to decide how much time to use on a single move, and Crafty keeps up with how far ahead (or behind) it actually is. And it then makes a decision on the target time, the absolute time limit, and so forth, and then off it goes;
(2) how much time is left on the clock? xboard protocol sends this after each move anyway, so one could just munge those numbers as the game progresses and most engines would probably play reasonably with respect to time.
For some things, (1) is irrelevant for the most part. ICC time controls for example, where you get an initial time limit and then possibly an increment after each move. I don't do much with that kind of "level" command other than to try to use a fixed percentage of the time left, + the increment. I pretty much ignore things because winboard/xboard keeps me up to date with respect to the time left, and by experimentation I have found a reasonable formula to take time left + increment and come up with a target time.
Now if we get into non-winboard type time controls, then yes, I would like to know, but I would really want to know before-hand, what each time control is, because for this kind of time control (primary time/moves, secondard time/moves and then perhaps sudden-death time limit) I want all the info up front so that I can decide what to do near the end of the primary time control, or the secondard time control, etc. For example, I might be more aggressive if the time control is traditional as in 40/120, 20/60, where the secondary time control is repeated indefinitely. I could afford to burn my remaining time down on move 59 or 60, knowing I am about to get another increment added in, whereas if we are going to sudden-death, I might be less aggressive before reaching the sudden-death time control so that I have more time to use then.
My suggestion is simply a new time control command. Defined as a part of a new protocol version 3 standard. Whether you overload the current "level" command (I didn't in Crafty) or use a different command (I did this in Crafty to keep things simpler) to set the time control is really up to you. Either approach would work and I don't see how it would cause problems, other than you should verify that the engine can handle the new feature however it is actually implemented...
If you can tell me the time control in an unambiguous manner, and then continue to update the clock as the game progresses, my program will work with no problems...