WB level command received when game in progress

[bob]

the only time controls I have ever encountered in real chess tournaments has been either

40/120 then 20/60,

or 40/120 then 20/60 then game/30

or game/60

I am not sure who dreamed up the idea of 3-4-5-6 levels of time control, and you can support those if you want. But if you handle the above 3 types, along with the chessclub.com form of time + inorwhich is what the level command was about, you will really cover the time control alternatives that matter to most, I'd bet...

I think we should agree on 2 time formats. The GUI should send time control to engine in one of the 2 formats at beginning of game or between sessions.

FORMAT1: a/b (values of a,b can change in any session, no time increments)

FORMAT2: game/t (no more sessions, time increments including value 0)


So FORMAT2 is always final session or only session, if used.


Example:
40/120+20/60+30 would mean that 40/120 is sent before move 1,
20/60 is sent between moves 40 and 41, and 30 is sent between moves 60 and 61.

My engines do just fine already with these proposals/conventions.

Matthias.

I don't like the idea of sending the second time control later. For example, suppose you are going to play one of the two following time controls:

40/120 + 20/60

or

40/120 + game/30

My time allocation during the first 40 moves would be different depending on the secondary time control. That's why I prefer to get the whole kit and kaboodle up front so I can use all available information to make hopefully better time-control decisions.

[Matthias Gemuh]

I don't like the idea of sending the second time control later. For example, suppose you are going to play one of the two following time controls:

40/120 + 20/60

or

40/120 + game/30

My time allocation during the first 40 moves would be different depending on the secondary time control. That's why I prefer to get the whole kit and kaboodle up front so I can use all available information to make hopefully better time-control decisions.

I remember you once said that.

I wouldn't mind sending all time controls up front with a "xlevel" command and again sending the associated time control for each session with a "level" command inbetween sessions.

That should satisfy everybody. My engine would ignore "xlevel" and yet live, while your engine ignores any "level" after an "xlevel".

Only question is the format for "xlevel" that does not lose much of the flexibility of several "level" commands.
Propose (perhaps again) the comprehensive "xlevel" format(s) you prefer.
My guess is that if last time control in "xlevel" mentions a non-zero move count, then that time control repeats infinitely for subsequent sessions.
Furthermore, "xlevel" is limited to
1) a/b (repeating, no increments)
2) a/b + c/d (c/d repeating, no increments)
3) a/b + c (and increments in c)
4) a/b + c/d + e (and increments in e)
5) a (and increments, i.e. standard fischer)
no exotic jokes like a/b+c/d+e/f+g

How do we then formuate cases 2,3,4 above in WB language ?


Matthias.

[hgm]

Indeed, one would not exclude the other.

To get the stuff up front the engine should first tell the GUI he can handle that, though, by sending "feature level=10". The GUI can then send all time controls up front. For engines that can handle only a single session at the time, it will be necessary to send multiple level commands, when new sessions start, to replace the old parameters by the new set.

The GUI can stop sending level commands once the engine has seen the parameters for all sessions. So if there are 3 sessions, an engine which set level=3 or larger gets them all up front, and no later level commands. An engine that set level=2 gets the first two sessions at the beginning of the game, and then session 2 & 3 in the level command after session 1 finishes. There will be no level command at the end of session 2.

An engine with level=1 would have to receive level commands at the beginning of all 3 sessions.

[bob]

I don't like the idea of sending the second time control later. For example, suppose you are going to play one of the two following time controls:

40/120 + 20/60

or

40/120 + game/30

My time allocation during the first 40 moves would be different depending on the secondary time control. That's why I prefer to get the whole kit and kaboodle up front so I can use all available information to make hopefully better time-control decisions.

I remember you once said that.

I wouldn't mind sending all time controls up front with a "xlevel" command and again sending the associated time control for each session with a "level" command inbetween sessions.

That should satisfy everybody. My engine would ignore "xlevel" and yet live, while your engine ignores any "level" after an "xlevel".

Only question is the format for "xlevel" that does not lose much of the flexibility of several "level" commands.
Propose (perhaps again) the comprehensive "xlevel" format(s) you prefer.
My guess is that if last time control in "xlevel" mentions a non-zero move count, then that time control repeats infinitely for subsequent sessions.
Furthermore, "xlevel" is limited to
1) a/b (repeating, no increments)
2) a/b + c/d (c/d repeating, no increments)
3) a/b + c (and increments in c)
4) a/b + c/d + e (and increments in e)
5) a (and increments, i.e. standard fischer)
no exotic jokes like a/b+c/d+e/f+g

How do we then formuate cases 2,3,4 above in WB language ?


Matthias.

Crafty currently has a "time command" that has evolved to work in any human tournament I have played in over the past 10+ years (it came from Cray Blitz so it actually goes back a lot farther)...

time 40/120 20/60

is a traditional repeating time control setting where the first time control is 40/120, and after that another hour is added every 20 moves until the game ends.

time 40/120 sd/60

This is a 40/120 time limit, but once we reach move 40, one hour is added to the clock and the rest of the game has to be played out in whatever time is left.

I later added

time 40/120 sd/60 inc

for those that insist on using a Fischer-clock in their games, where "inc" is added to the clock after each move is played...

Those have actually worked in every event Ihat I have ever played in. I added a third time control a few years ago but removed it when cleaning things up a year or two later since I never found a tournament with more than two time controls. Many are just sd/n type events, but there are some that have a normal first time control then sudden death after that to make the rounds end on time.

[bob]

Indeed, one would not exclude the other.

To get the stuff up front the engine should first tell the GUI he can handle that, though, by sending "feature level=10". The GUI can then send all time controls up front. For engines that can handle only a single session at the time, it will be necessary to send multiple level commands, when new sessions start, to replace the old parameters by the new set.

The GUI can stop sending level commands once the engine has seen the parameters for all sessions. So if there are 3 sessions, an engine which set level=3 or larger gets them all up front, and no later level commands. An engine that set level=2 gets the first two sessions at the beginning of the game, and then session 2 & 3 in the level command after session 1 finishes. There will be no level command at the end of session 2.

An engine with level=1 would have to receive level commands at the beginning of all 3 sessions.

I think this sounds fine as defined above. Just don't forget the "inc" option...

[Matthias Gemuh]

The GUI can stop sending level commands once the engine has seen the parameters for all sessions. So if there are 3 sessions, an engine which set level=3 or larger gets them all up front, and no later level commands. An engine that set level=2 gets the first two sessions at the beginning of the game, ...

I agree with the above but not with "and then session 2 & 3 in the level command after session 1 finishes. There will be no level command at the end of session 2.
An engine with level=1 would have to receive level commands at the beginning of all 3 sessions".

Sessions that depend on "xlevel" should get time controls up front.
The count of such xlevel sessions is given in "features".

All other sessions depend on "level" and should expect the command at session begin, not earlier. I don't want to receive a "level" command for session 3 between sessions 1 and 2.

Matthias.

[hgm]

The problem is that earlier discussions on protocol extensions have 'overloaded' the level keyword, to also serve the function of xlevel. So there actually exist engines that understand things like

level 40 120 0 20 60 0 0 30 0

and interpret it as 40/120'+20/60'+30'. And there are GUIs that send this command to effect such a time control. The general syntax is

level MPS1 TC1 INC1 MPS2 TC2 INC2 MPS3 TC3 INC3 ...

where you can have arbitrary many triples MPS, TC, INC (but at least one).

To not lose compatibility with that, we would be forced to implement 'xlevel' this way.

So what I propose would be to send to an engine that has N=2:
before move 1 : level 40 120 0 20 60 0
before move 41: level 20 60 0 0 30 0

while an engine with N=1 would receive
before move 1 : level 40 120 0
before move 41: level 20 60 0
before move 61: level 0 30 0

Only engines which set N>=3 would receive the entire set up front (and nothing else).

As an alternative, when the option /firstAccumulateTC (/secondAccumulateTC) is set, the engines with N=1 would receive
before move 1 : level 40 120 0
before move 41: level 60 180 0
before move 61: level 0 210 0

and those with N=2
before move 1 : level 40 120 0 20 60 0
before move 41: level 60 180 0 0 30 0

Within the context of level and xlevel commands using the same keyword 'level', I think your proposal only differs from mine by only sending the first set of parameters on the level commands at later moves, and sending the level commands at the beginning of every new session.

I think there are good reasons for not doing that:
1) sending level commands during the game remains a risky business, as there is no guarantee how engines will react to it. This holds for standard WinBoard engines that only implement the default level=1, but also to engines that implement the extension of the level command now. So I would like to minimize it wherever possible. In particular, if an engine with N>1 has seen all the session parameters up front, I would not want to take the chance of upsetting it by sending later levels.

2) In situations where engines only expect level commands with one session, the extra session parameters are likely to be simply ignored. So once you decide to send a level (where the parameters of the first session will almost certainly have an effect, be it an ill-defined one), sending the extra parameters is not adding much risk.

3) You would have to stop sending level commands at some point anyway, when you run out of sessions. If the last specified session is a classical time control, it is supposed to repeat indefinitely. But for maximum compatibility with the currently supported classical time control, such repeated sessions should not be sent as a new level command at their beginning.

I would want to encourage GUI writers to suppress sending of level commands that the engine already should understand (so that the compatibility mentioned above is automatic). E.g. if the time control is 40/60'+40/60'+15'+5", an N=1 engine would have to receive (in yours as well as my system)
before move 1 : level 40 60 0
before move 41: level 40 60 0
before move 81: level 0 15 5
But there is no need to send the command at move 41, since this is already what the engine expects. I don't think this is too hard to implement for the GUI: just remember what you send to the engine last time; shift all sessions one forward (duplicating the last session that was sent), and if that is the same thing as what you would want to send now, (which is obtained by a similar forward shift, but now duplicating the last session that was specified, rather than sent), suppress the sending. A side effect of that general strategy would suppress the sending of further level commands after the engine has seen all the sessions (as the last session is understood to repeat indefinitely).

[Matthias Gemuh]

The problem is that earlier discussions on protocol extensions have 'overloaded' the level keyword, to also serve the function of xlevel. So there actually exist engines that understand things like

level 40 120 0 20 60 0 0 30 0

and interpret it as 40/120'+20/60'+30'. And there are GUIs that send this command to effect such a time control. The general syntax is

level MPS1 TC1 INC1 MPS2 TC2 INC2 MPS3 TC3 INC3 ...

where you can have arbitrary many triples MPS, TC, INC (but at least one).

To not lose compatibility with that, we would be forced to implement 'xlevel' this way.

So what I propose would be to send to an engine that has N=2:
before move 1 : level 40 120 0 20 60 0
before move 41: level 20 60 0 0 30 0

while an engine with N=1 would receive
before move 1 : level 40 120 0
before move 41: level 20 60 0
before move 61: level 0 30 0

Only engines which set N>=3 would receive the entire set up front (and nothing else).

OK, that is easy to understand.
I will implement it in ChessGUI.

Matthias.