WB level command received when game in progress

[hgm]

How would your engines interpret a level command sent during the game?

I am still pondering about how to best equip WinBoard with secondary time controls. Major problem is that whatever I do in terms of new or extended old commands, it will be next to useless: most engines will simply not know or implement the commands. And the few engines that do, will not be able to use the time controls beause their opponents will in generally not accept them.

So it would be better to make a modification that would already work with most engines, so that in some (sub-optimal) way they could be made to play time controls like 40/60'+40/25'+5'+0" (meaning: first 40 moves in 60 min, then 25 min (plus the left-over time) for the next 40 moves, and then 5 min for the rest of the game).

When WinBoard is requested to have the engines play such a time control, it could then (per default) only send teh parameters for the upcoming or current session, i.e. "level 40 60 0" at game start. The engine will know that the mentioned 60 min is for 40 moves, and that it can expect to get more time after move 40. Of course all engines now expect to get 60 min for the next 40 moves as well.

But the modified WinBoard would now send a new level command to the engine after they made their 40th move, namely "level 80 85 0". With a bit of luck, the engines would interpret this as having to make the remaining time (which WB sends them before every move anyway) until move 85. After move 80 WinBoard will send "level 0 90 0", to make clear that the time sent through the 'time' and 'otim' commands now is for the rest of the game.

Of course the fact that they receive only 25 new minutes (instead of 60) for the next 40 moves at move 40 might come as an unpleasant surprise (and being told that they receive 5 min for the rest of the game in stead of another 25 min for 40 moves even more so), which they would have rather known in advance. They could requst this by the feature "level=N". WinBoard will then send them the time-control parameters they can expect in the first N sessions.

But the first 3 parameters (MPS, TIME, INC) would be treated exactly as above: after each session, a new 'level' command would follow, with the first three parameters the 'accumulated' MPS, TIME, and INC of the upcoming and all previous sessions. The parameters that follow, would be those for future sessions, and thus be moved 3 places forward on every subsequent 'level' command compared to the previous one. WinBoard could then append information for sessions it could not send before (because N was not set high enough by the engine).

So with "level=2" in the feature, the engine would at any time be informed what the currently reported 'time' is for, and would get a preview of what will happen in the first session after that.

Does this sound like a workable idea? For many engines it might already work satisfactorily. Only if the time controls of subsequent sessions are wildly different it might work in a suboptimal way, and that would provide an incentive to implement N>1.

The new usage of the 'level' command need not be restricted to future protocols: it is the user, rather than teh engines, who determines if the extra 'level' commands will be sent (by specifying a secondary time control different from the first). By default, sending a new level command after a time control is made would be suppressed if the parameters would already have been implied by the previous one. E.g. "level 40 60 0" at thebeginning of the game would imply "level 80 120 0" for the next session, and this would not be sent if indeed the user specified 40/60' repetetive. This provides 100% backward compatibility for the time controls WinBoard supports now.

[wgarvin]

I'm no expert, but it sounds like a bad idea. The protocol is stateful but you don't know how existing engines would interpret it--whether it would trigger sub-optimal behaviour, bugs, or whether they would ignore it and lose on time, or what.

It would be much safer to just implement the new time controls as part of a new protocol version (or perhaps require the engine to claim that it supports it using a feature command). New or actively-developed engines can then implement it properly, and legacy engines will not be able to use it, but they also won't crash or misbehave because of it.

By the way, I think the biggest thing missing from the Winboard protocol is the ability for the engine to enumerate its configuration parameters so that the GUI can expose them directly to the user. That is one of the only things that I like about UCI.

Ideally, the GUI should be able to expose a widget for any parameter from the engine, even if the GUI does not know what the parameter is (i.e. the engine described it as a "boolean" so the GUI will just make a checkbox for it). However, for parameters where the GUI knows what it is (e.g. tablebase directory, variant to play, size of hashtable memory, ...) then the GUI could use a more specialized widget or present it in a different place, and that would be fine. Parameters which might involve both engines (such as time controls) should be handled similarly. So a dialog box allowing the user to choose time controls, might have some of its widgets disabled unless both engines claim to support the feature.

I would really like to see this sort of parameter enumeration added to the Winboard protocol so that users can customize engine settings through the GUI and not have to mess with configuration files or whatever. At that point there would basically be no reason to use UCI over the Winboard protocol.

[bob]

How would your engines interpret a level command sent during the game?

I am still pondering about how to best equip WinBoard with secondary time controls. Major problem is that whatever I do in terms of new or extended old commands, it will be next to useless: most engines will simply not know or implement the commands. And the few engines that do, will not be able to use the time controls beause their opponents will in generally not accept them.

So it would be better to make a modification that would already work with most engines, so that in some (sub-optimal) way they could be made to play time controls like 40/60'+40/25'+5'+0" (meaning: first 40 moves in 60 min, then 25 min (plus the left-over time) for the next 40 moves, and then 5 min for the rest of the game).

When WinBoard is requested to have the engines play such a time control, it could then (per default) only send teh parameters for the upcoming or current session, i.e. "level 40 60 0" at game start. The engine will know that the mentioned 60 min is for 40 moves, and that it can expect to get more time after move 40. Of course all engines now expect to get 60 min for the next 40 moves as well.

But the modified WinBoard would now send a new level command to the engine after they made their 40th move, namely "level 80 85 0". With a bit of luck, the engines would interpret this as having to make the remaining time (which WB sends them before every move anyway) until move 85. After move 80 WinBoard will send "level 0 90 0", to make clear that the time sent through the 'time' and 'otim' commands now is for the rest of the game.

Of course the fact that they receive only 25 new minutes (instead of 60) for the next 40 moves at move 40 might come as an unpleasant surprise (and being told that they receive 5 min for the rest of the game in stead of another 25 min for 40 moves even more so), which they would have rather known in advance. They could requst this by the feature "level=N". WinBoard will then send them the time-control parameters they can expect in the first N sessions.

But the first 3 parameters (MPS, TIME, INC) would be treated exactly as above: after each session, a new 'level' command would follow, with the first three parameters the 'accumulated' MPS, TIME, and INC of the upcoming and all previous sessions. The parameters that follow, would be those for future sessions, and thus be moved 3 places forward on every subsequent 'level' command compared to the previous one. WinBoard could then append information for sessions it could not send before (because N was not set high enough by the engine).

So with "level=2" in the feature, the engine would at any time be informed what the currently reported 'time' is for, and would get a preview of what will happen in the first session after that.

Does this sound like a workable idea? For many engines it might already work satisfactorily. Only if the time controls of subsequent sessions are wildly different it might work in a suboptimal way, and that would provide an incentive to implement N>1.

The new usage of the 'level' command need not be restricted to future protocols: it is the user, rather than teh engines, who determines if the extra 'level' commands will be sent (by specifying a secondary time control different from the first). By default, sending a new level command after a time control is made would be suppressed if the parameters would already have been implied by the previous one. E.g. "level 40 60 0" at thebeginning of the game would imply "level 80 120 0" for the next session, and this would not be sent if indeed the user specified 40/60' repetetive. This provides 100% backward compatibility for the time controls WinBoard supports now.

Crafty just takes it at the instant it arrives and "plugs it in". 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...

[Uri Blass]

How would your engines interpret a level command sent during the game?

I am still pondering about how to best equip WinBoard with secondary time controls. Major problem is that whatever I do in terms of new or extended old commands, it will be next to useless: most engines will simply not know or implement the commands. And the few engines that do, will not be able to use the time controls beause their opponents will in generally not accept them.

So it would be better to make a modification that would already work with most engines, so that in some (sub-optimal) way they could be made to play time controls like 40/60'+40/25'+5'+0" (meaning: first 40 moves in 60 min, then 25 min (plus the left-over time) for the next 40 moves, and then 5 min for the rest of the game).

When WinBoard is requested to have the engines play such a time control, it could then (per default) only send teh parameters for the upcoming or current session, i.e. "level 40 60 0" at game start. The engine will know that the mentioned 60 min is for 40 moves, and that it can expect to get more time after move 40. Of course all engines now expect to get 60 min for the next 40 moves as well.

But the modified WinBoard would now send a new level command to the engine after they made their 40th move, namely "level 80 85 0".

I think that it is a bad idea to send level in the middle of the game.

What the interface can do is simply save the moves of the game and tell the engines simply to quit the game and start a new game with level 80 85 0 when you also give the engines the first moves of the game(note that this idea is only for old engines and of course it is better for new engine to support extended level command so they will not get new game and get information about the level at the beginning of the game).

Engines may clear the hash and lose some time because of it but it is better than sending level in the middle of the game when engines may not understand it(note that movei always clear the hash between moves).

I am not sure what movei does in this case because I did not think about this situation and I need to look at my code to see what it does in that case but I do not think that it is important what it does in this case because the case of getting level command in the middle of the game should not happen in the first place.

Uri

[hgm]

he problem with your idea is that very many WB engines do not handle it well when you feed them moves in force mode at classical time control. They don't count these moves. This can lead to disastrous timing errors:

Feed them 1 move in force mode, and statrt playing 40/40. After 39 moves, (which they count as 38) they have stil 3-4 min left on the clock, for the two moves they think they still have to do (plus some safety margin). But then they do the 40th move (which they count as 39), and suddenly get another 40 min added to their time. They then see 43-44 min on the clock, and think they only have to do 1 move (their 4oth) in this time. So they start thinking for 40 min or so over this one move, confident that they will receive new time after it.

But after the 41th move they of course get nothing. So now they have only 3 min left for the remaining 39 moves of the second session. This is of course always fatal.

[Uri Blass]

I think that the problem that you describe is mainly problems of weak engines that do not participate in CEGT or CCRL.

I guess that programmers who cared about CEGT or CCRL rating of their program in most cases noticed the problem and fixed it.

Note that based on my memory old Movei had the same problem in the first public version Movei0.07a(I tested it at that time against other engines not from fixed positions but simply by changing the first move in every game so I did not notice this problem).

My guess is that at least in the level of joker and higher than it more programs may have problems if you send them the level command in the middle of the game because this experience is new to many programmers when the experience of getting the level command and later moves at force mode is experience that is not new to most of the programmers of programs at that level.

Uri

[Matthias Gemuh]

Crafty just takes it at the instant it arrives and "plugs it in". ...

That is also what my engines do.

Matthias.

[Matthias Gemuh]

I think that it is a bad idea to send level in the middle of the game.

What the interface can do is simply save the moves of the game and tell the engines simply to quit the game and start a new game with level 80 85 0 when you also give the engines the first moves of the game(note that this idea is only for old engines and of course it is better for new engine to support extended level command so they will not get new game and get information about the level at the beginning of the game).

Uri

That sounds complicated. How does GUI give engine the extra time saved from previous time control (assume a/b + c/d ) ?

Matthias

[Matthias Gemuh]

My guess is that at least in the level of joker and higher than it more programs may have problems if you send them the level command in the middle of the game because this experience is new to many programmers
...

Uri

In the strength range you mention, no programmer can have problems coping with a level command anywhere.
BTW defining a time format that weak engines too weak for CEGT/CCRL may not handle correctly is a bad idea.

Matthias.

[Uri Blass]

I think that it is a bad idea to send level in the middle of the game.

What the interface can do is simply save the moves of the game and tell the engines simply to quit the game and start a new game with level 80 85 0 when you also give the engines the first moves of the game(note that this idea is only for old engines and of course it is better for new engine to support extended level command so they will not get new game and get information about the level at the beginning of the game).

Uri

That sounds complicated. How does GUI give engine the extra time saved from previous time control (assume a/b + c/d ) ?

Matthias

There is no problem with the extra time saved because the gui tell the engine the time that it has to complete the next time control before every move.

The GUI can simply tell the engine a+c/b+d time control and give it the moves in force mode.

The only problem is with engines that are confused by CEGT or CCRL conditions.

Uri