New Time Controls for WB

[Matthias Gemuh]

New Time Controls for WB using ChessGUI.

I am currently running a Swiss tournament using only WB engines and the
classical TC "25moves/1min" + "20moves/1min" + "Game/1min + 1sec/move".

ChessGUI sends the "level" command for each TC session to the engines at the beginning of each session.
So far, the top 32 WB engines have played, allocating their time reasonably in all TC sessions.
There is therefore a high degree of backward compatibility with the idea of sending a "level" command per session.
That is almost identical with what the UCI protocol does.

HGM, will you think about officially extending WB time controls this way rather than the other complicated way which no engine author has till today implemented ?

Anybody can see this idea in action under ChessGUI.
Grab version 0.197d here
http://w2410tmq9.homepage.t-online.de/
and update the exe file to 0.198b with
http://www.hugedrive.com/published/WG/show.php?q=QklHTElPTg==-5c8abf0a

Matthias.

[H.G.Muller]

Indeed, I am very much in favor of using a (mostly) backward-compatible way to handle mlti-session TCs.

There are several ways to do this, however, and last time we discussed it, it was not clear which of those would capture most of the existing engines. The main possibilities are 'absolute' and 'relative':

Relative would be the system where the engine interprets a level command relative to the moment it receives it. That is, it when it receives level 25 20 0, t would think it the current session will end 25 moves from now, and it has 20 minutes left on its clock. The latter is not really important, as it will in practice always be overruled by the time command the engine gets before every move.

Absolute would be when the engine interprets the level parameters relative to the beginning of the game. Such an engine would require you to add the parameters of all sessions that have already passed to the current one. E.g. for 40/60+25/20, you would have to send the engine level 65 80 0 after move 40, so that it knows it has 25 moves to go to the next TC.

It was at the time not clear to me if most engines would be absolute or relative. Apparently you more or less figured this out now. (So what exactly are the intra-game level commands you send them, and when do you send them? Is it level 25 1 0 before the game, level 20 1 0 after move 25, and level 0 1 1 after move 45, just before the time command?)

WinBoard is in fact all set up for doing multi-session TC; its internal time management already handles the clocks properly for that, when you request a multi-session TC in the -tc argument (e.g. -mps 40 -tc 60+25/20+5 -inc 1 would be understood as one session of 40 moves in 60 min, the next session of 25 moves in 20 min, and 5 min + 1 sec/move for the rest of the game. The only problem is that it does not send the intra-game level commands yet, because I was not sure what to send.

For engines that like to be informed in advance how long the later sessions can take, we can add a feature to the protocol (feature xlevel) to piggy-back the parameters for those sessions onto the level command, behnd the first session.

[Matthias Gemuh]

It was at the time not clear to me if most engines would be absolute or relative. Apparently you more or less figured this out now. (So what exactly are the intra-game level commands you send them, and when do you send them? Is it level 25 1 0 before the game, level 20 1 0 after move 25, and level 0 1 1 after move 45, just before the time command?)

I and existing WB engines like the relative approach. I hope increments are allowed in all sessions.
ChessGUI does it just as in the quote.
From Top 50, only 2 engines did not know what to do with "level" at the beginning of the 2nd TC session.

[H.G.Muller]

OK, the relative approach is fortunately also what I put in the specs for intra-game level commands.

The number of moves given in the level command (when non-zero) should be taken as the number of moves still to do before the specified time will be added to the clock, if the "level" command is received after some moves have already been played. The time given should be interpreted as the time left on its clock (including any time left over from the previous sessions), and not necessarily the time that will be added to the clock after the specified number of moves has been played.

I have not implemented increments in any session but the last in WinBoard. It seems pretty pointless to have increments in internal sessions. Because the number of moves in the session is known,so you could simpy add that many times the increment to the duration of the session.

But that of course does not mean that the protocol does not have to support them.

So I guess it is not so much a protocol change that is needed. Just a GUI that uses the existing protocol to the max. After all, we are going to dump this on existing engine, so the last thing we would want is to introduce some feature that would suppress the use of it in existing engines not specifically made to support it.

I would like to add new protocol to allow engines that want it to inquire about what to expect. To this end there would be a new boolean feature 'xlevel'. Engines that would send feature xlevel = 1 at startup would get not just the parameters for the next session sent in a normal level command, but also the parameters for all subsequent time controls. Problem is that we cold not really agree about the format. My original idea was to simply send all sessions in one level command, with as many groups of 3 parameters as needed. But most authors seemed to like the command split up in a normal level command, followed by a number of separate commands, one for each upcoming session. (Yegh!) Perhaps I should bring it up on TalkChess again...

[Matthias Gemuh]

I would like to add new protocol to allow engines that want it to inquire about what to expect. To this end there would be a new boolean feature 'xlevel'. Engines that would send feature xlevel = 1 at startup would get not just the parameters for the next session sent in a normal level command, but also the parameters for all subsequent time controls. Problem is that we cold not really agree about the format. My original idea was to simply send all sessions in one level command, with as many groups of 3 parameters as needed. But most authors seemed to like the command split up in a normal level command, followed by a number of separate commands, one for each upcoming session. (Yegh!) Perhaps I should bring it up on TalkChess again...

Yes, let's hear what engine authors think about it.

[Michel]

In GNUChess I made the level command relative. This seemed to be the most natural and
flexible.

It does not quite work correctly with "undo" as the previous level command
is not restored. I guess to be absolutely correct one should remember all previous level
commands...

[H.G.Muller]

Good point. But we can specify it does not have to work with undo. Engines don't remember their timeLeft from all time commands either. They rely on the GUI to restore the clock time after a 'retract move'. So perhaps it should be able to rely on the GUI for restoring the time-control setting as well.

So the action of the engine on receiving undo or remove will remain limited to adding back the move to its 'movesToGo' counter (however it implements that). If retracting the moves passes a control point, the GUI should send a new level command with a session of 1 move. For better backward compatibility we can specify it only does that if a multi-session control is specified for the current game.