WB level command received when game in progress

[Uri Blass]

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.

The problem is not to support level command at the middle of the game but the fact that part of the programmers stopped to work on their program and if you want to test them you may have problems.

If we talk about active programmers there is no problem because they can release fix to their program and the question is what solution is going to cause less problems to programs that their programmers are not active.

Uri

[Matthias Gemuh]

The problem is not to support level command at the middle of the game but the fact that part of the programmers stopped to work on their program and if you want to test them you may have problems.

If we talk about active programmers there is no problem because they can release fix to their program and the question is what solution is going to cause less problems to programs that their programmers are not active.

Uri

We should not care too much about backward compatibility to old engines because the use of such engines can be limited to cases where old time formats are used.
It is perfectly OK if the exotic time formats we are trying to establish are supported only by engines currently under development and future ones.

Matthias.

[Uri Blass]

The problem is not to support level command at the middle of the game but the fact that part of the programmers stopped to work on their program and if you want to test them you may have problems.

If we talk about active programmers there is no problem because they can release fix to their program and the question is what solution is going to cause less problems to programs that their programmers are not active.

Uri

We should not care too much about backward compatibility to old engines because the use of such engines can be limited to cases where old time formats are used.
It is perfectly OK if the exotic time formats we are trying to establish are supported only by engines currently under development and future ones.

Matthias.

I think that all decisions are equal for the future and the only difference is in backward compatibility.

Programmers of engines under developement and future engines should have no problem to support what is accepted.

I am not sure if I am going to support it in future movei because I plan to write new bitboard engine so I am not sure if I continue to work on movei.

Uri

[hgm]

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.

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...

[bob]

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.

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...

[hgm]

There seems to be an extended level command around, that simply has multiple triples of session parameters (movesPerSession, timeControl, timeIncrement). A handful of WinBoard engines actually implement this form of the command. It is very likely that when other engines receive this command, they would treat it as a normal 'level' command, ignoring everything but the first triple. (It is not very likely that they explicitly check if a new-line immediately follows the third parameter, for no other reason than to make trouble if it doesn't.)

This seems to fit your desire to know in advance what to expect. To stay absolutely compatible with earlier protocol versions, the GUI should enable the sending of the extra session parameters with the feature command, "feature level=N", with N the maximum acceptable number of sessions (default N=1). None of the engines that do implement the extended level command seem to set this feature, however.

The problem is how the GUI should act when the time control specified by the user contains more sessions than the engine accepts. Preferably it should be able to trick the engine into the desired behavior as accurately as possible. Just sending the parameters of the first session to an engine that has N=1, and leaving it at that, (relying on the times sent by the GUI) can have disastrous effects.

One way to change the behavior of engine (which Uri proposed) is to simply restart the game as time-control parameters change, set it to a new time control (combining all sessions that already have been played with the upcoming one), feed all the moves that have been played back into the engine, and play from there. This sounds like a completely safe method, but I know from experience that for many engines it does not work: they do not count moves that were force-fed to them, and start applying the time control from when they receive the 'go' command.

A better way thus might be to send the engine a new 'level' command at the end of a session (but only if it is needed, i.e. if the session parameters actually change). There are two ways to do this:

1) accumulative: add time and moves of the sessions that have already been played to that of the one to come, and send this sum as a new first session. So that 40/60+20/15 would lead to sending of a "level 60 75 0", and 20/20+5 would lead to "level 0 25 0".

2) differential: simply send the parameters of the next session as firsst session in a new level command. So in the above examples "level 20 15 0" and "level 0 5 0", respectively.

If the engine has specified N>1, all following sessions could simply be moved one place forwards. (Either the earlier sessions are now combined into one, or simply drop off.) So that with N=2 you at least have a preview into the session that will come after the current one finishes, while with N=3 your preview horizon is two sessions.

We cannot expect the engines to specify which of the two methods they need, as when engines would have to be changed, they might as well be immediately changed to make N large enough so that none of these kludges are needed. (i.e. the combining or dropping of sessions will only take place as long as there are still sessions 'out of view' of the (known) limited scope of the engine.

So a command-line argument (or a user menu) to WinBoard would have to specify which of the two methods should be used (or perhaps which of the three, if we also implement Uri's method), and the user should then experiment and hope there is one amongst them that works for the engine in question. As the option should allow different setting for one engine and the other, these should be options of the form /firstTimeControlType, /secondTimeControlType, etc.

[bob]

There seems to be an extended level command around, that simply has multiple triples of session parameters (movesPerSession, timeControl, timeIncrement). A handful of WinBoard engines actually implement this form of the command. It is very likely that when other engines receive this command, they would treat it as a normal 'level' command, ignoring everything but the first triple. (It is not very likely that they explicitly check if a new-line immediately follows the third parameter, for no other reason than to make trouble if it doesn't.)

This seems to fit your desire to know in advance what to expect. To stay absolutely compatible with earlier protocol versions, the GUI should enable the sending of the extra session parameters with the feature command, "feature level=N", with N the maximum acceptable number of sessions (default N=1). None of the engines that do implement the extended level command seem to set this feature, however.

The problem is how the GUI should act when the time control specified by the user contains more sessions than the engine accepts. Preferably it should be able to trick the engine into the desired behavior as accurately as possible. Just sending the parameters of the first session to an engine that has N=1, and leaving it at that, (relying on the times sent by the GUI) can have disastrous effects.

One way to change the behavior of engine (which Uri proposed) is to simply restart the game as time-control parameters change, set it to a new time control (combining all sessions that already have been played with the upcoming one), feed all the moves that have been played back into the engine, and play from there. This sounds like a completely safe method, but I know from experience that for many engines it does not work: they do not count moves that were force-fed to them, and start applying the time control from when they receive the 'go' command.

A better way thus might be to send the engine a new 'level' command at the end of a session (but only if it is needed, i.e. if the session parameters actually change). There are two ways to do this:

1) accumulative: add time and moves of the sessions that have already been played to that of the one to come, and send this sum as a new first session. So that 40/60+20/15 would lead to sending of a "level 60 75 0", and 20/20+5 would lead to "level 0 25 0".

2) differential: simply send the parameters of the next session as firsst session in a new level command. So in the above examples "level 20 15 0" and "level 0 5 0", respectively.

If the engine has specified N>1, all following sessions could simply be moved one place forwards. (Either the earlier sessions are now combined into one, or simply drop off.) So that with N=2 you at least have a preview into the session that will come after the current one finishes, while with N=3 your preview horizon is two sessions.

We cannot expect the engines to specify which of the two methods they need, as when engines would have to be changed, they might as well be immediately changed to make N large enough so that none of these kludges are needed. (i.e. the combining or dropping of sessions will only take place as long as there are still sessions 'out of view' of the (known) limited scope of the engine.

So a command-line argument (or a user menu) to WinBoard would have to specify which of the two methods should be used (or perhaps which of the three, if we also implement Uri's method), and the user should then experiment and hope there is one amongst them that works for the engine in question. As the option should allow different setting for one engine and the other, these should be options of the form /firstTimeControlType, /secondTimeControlType, etc.

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...

[Matthias Gemuh]

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.

[hgm]

I think my engines would accept this too. It might be that there are some engines that would need to be sent 60/180 between move 40 and 41. The 180 in fact would be superfluous, as the 'level command would be sent just before the 'time' command of move 41, and this time would overrule whatever the engine ould extract from the 'level' command time-control parameter.

The engines would not be aware of what to expect next, though. Engines that want to be aware can use the level=N feature to look N-1 sessions ahead.

[Matthias Gemuh]

I think my engines would accept this too. It might be that there are some engines that would need to be sent 60/180 between move 40 and 41. The 180 in fact would be superfluous, as the 'level command would be sent just before the 'time' command of move 41, and this time would overrule whatever the engine ould extract from the 'level' command time-control parameter.

The engines would not be aware of what to expect next, though. Engines that want to be aware can use the level=N feature to look N-1 sessions ahead.

I don't see any need for the 60/180. We should not try simulations just to offer backward compatibility. The time control should NEVER include a move count that differs from number of actual moves to expect in a session.

"The 180 in fact would be superfluous ...". The fact that the remaining time is sent immediately after a time control should NOT have any influence on the format of the time control.

Engines designed to ignore remaining time info (many presently) should still function with time control alone.

Matthias.