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/s ... =-5c8abf0a

Matthias.

[Matthias Gemuh]

From Top 50, only 2 engines did not know what to do with "level" at the beginning of the 2nd TC session.

[hgm]

The current protocol specs already recommend engines to interpret intra-game level commands that way. So there is nothing to stop a GUI from using this on existing engines, in the hope it will work.

I would like to extend the protocol to allow engines that are especially programmed to do multi-session TC to receive advance info on the future sessions. This would involve a (boolean) feature xlevel, with which the engine can request to receive not only the parameters of the upcoming session, but also for all sessions after it. This could be done in two ways:

1) A single long level command, of the form

level MPS1 TC1 INC1 MSP2 TC2 INC2 ...

where the first group of 3 parameters is for the session that starts at the current move, the second group for the session after that, etc.

2) A normal level command, followed by an arbitrary number of extension commands, each specifying a single session:

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

In both cases, if the last mentioned session does not specify a 'rest of game' session, it is supposed to repeat indefinetely.

Which of these two solutions would be preferable?

[michiguel]

The current protocol specs already recommend engines to interpret intra-game level commands that way. So there is nothing to stop a GUI from using this on existing engines, in the hope it will work.

I would like to extend the protocol to allow engines that are especially programmed to do multi-session TC to receive advance info on the future sessions. This would involve a (boolean) feature xlevel, with which the engine can request to receive not only the parameters of the upcoming session, but also for all sessions after it. This could be done in two ways:

1) A single long level command, of the form

level MPS1 TC1 INC1 MSP2 TC2 INC2 ...

where the first group of 3 parameters is for the session that starts at the current move, the second group for the session after that, etc.

2) A normal level command, followed by an arbitrary number of extension commands, each specifying a single session:

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

In both cases, if the last mentioned session does not specify a 'rest of game' session, it is supposed to repeat indefinetely.

Which of these two solutions would be preferable?

==> 2

I think we had a long discussion at the WB forum and I will need to refresh my mind with all the issues. But I think Pradu recommended something like 2 and backed it up with good reasons related to flexibility, extensibility and how easy they are to be parsed.

Miguel

[Matthias Gemuh]

I like level MPS1 TC1 INC1 MSP2 TC2 INC2 ...

[Don]

The current protocol specs already recommend engines to interpret intra-game level commands that way. So there is nothing to stop a GUI from using this on existing engines, in the hope it will work.

I would like to extend the protocol to allow engines that are especially programmed to do multi-session TC to receive advance info on the future sessions. This would involve a (boolean) feature xlevel, with which the engine can request to receive not only the parameters of the upcoming session, but also for all sessions after it. This could be done in two ways:

1) A single long level command, of the form

level MPS1 TC1 INC1 MSP2 TC2 INC2 ...

where the first group of 3 parameters is for the session that starts at the current move, the second group for the session after that, etc.

2) A normal level command, followed by an arbitrary number of extension commands, each specifying a single session:

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

In both cases, if the last mentioned session does not specify a 'rest of game' session, it is supposed to repeat indefinetely.

Which of these two solutions would be preferable?

Although I'm not actually using winboard protocol, I think 1 is highly preferable. It's one less command to parse and can be handled in a single parsing "session" or routine.

It seems like your suggestion is more "windows-centric" where there is a different name for everything instead of a consistent abstraction. So what I would suggest is something like this if you must have multiple commands:

level N MPS TC INC

where N would be the session number starting with one. So there is a separate level command for each session instead of 2 different tokens that have the same meaning but in an inconsistent way (level and session always mean the same things except level is always for session 1 but "session" is always for session 2 unless it's for session 3 or 4 or more etc.)

[hgm]

Hmm, interesting. Too bad slipping in the session number in front is not compatible with the old level command. I guess we could make it so if we sacrifice the INC field (i.e. allow only increments in the last session). Negative numbers in the increment field could than code for the number of level commands to follow. E.g.

level 40 60 -2
level 25 20 -1
level 0 5 1

for 40/60 + 25/20 + 5 + 1sec/move.

Of course this would make people that want increments in earlier sessions unhappy.

[michiguel]

The current protocol specs already recommend engines to interpret intra-game level commands that way. So there is nothing to stop a GUI from using this on existing engines, in the hope it will work.

I would like to extend the protocol to allow engines that are especially programmed to do multi-session TC to receive advance info on the future sessions. This would involve a (boolean) feature xlevel, with which the engine can request to receive not only the parameters of the upcoming session, but also for all sessions after it. This could be done in two ways:

1) A single long level command, of the form

level MPS1 TC1 INC1 MSP2 TC2 INC2 ...

where the first group of 3 parameters is for the session that starts at the current move, the second group for the session after that, etc.

2) A normal level command, followed by an arbitrary number of extension commands, each specifying a single session:

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

In both cases, if the last mentioned session does not specify a 'rest of game' session, it is supposed to repeat indefinetely.

Which of these two solutions would be preferable?

Although I'm not actually using winboard protocol, I think 1 is highly preferable. It's one less command to parse and can be handled in a single parsing "session" or routine.

This is one of the threads in which this was discussed.
http://www.open-aurec.com/wbforum/viewt ... ilit=level

I agree with the firs post by Pradu= #2 is easier to parse and more robust.

Miguel

It seems like your suggestion is more "windows-centric" where there is a different name for everything instead of a consistent abstraction. So what I would suggest is something like this if you must have multiple commands:

level N MPS TC INC

where N would be the session number starting with one. So there is a separate level command for each session instead of 2 different tokens that have the same meaning but in an inconsistent way (level and session always mean the same things except level is always for session 1 but "session" is always for session 2 unless it's for session 3 or 4 or more etc.)

[Don]

Hmm, interesting. Too bad slipping in the session number in front is not compatible with the old level command. I guess we could make it so if we sacrifice the INC field (i.e. allow only increments in the last session). Negative numbers in the increment field could than code for the number of level commands to follow. E.g.

level 40 60 -2
level 25 20 -1
level 0 5 1

for 40/60 + 25/20 + 5 + 1sec/move.

Of course this would make people that want increments in earlier sessions unhappy.

I wondered if there would be a compatibility issue. Could the session number be placed at the end?

Or better yet, use the level command for deprecated backward compatibility, but encourage the use of the modern and more flexible alternative (giving it a new name.)

[bob]

Hmm, interesting. Too bad slipping in the session number in front is not compatible with the old level command. I guess we could make it so if we sacrifice the INC field (i.e. allow only increments in the last session). Negative numbers in the increment field could than code for the number of level commands to follow. E.g.

level 40 60 -2
level 25 20 -1
level 0 5 1

for 40/60 + 25/20 + 5 + 1sec/move.

Of course this would make people that want increments in earlier sessions unhappy.

I wondered if there would be a compatibility issue. Could the session number be placed at the end?

Or better yet, use the level command for deprecated backward compatibility, but encourage the use of the modern and more flexible alternative (giving it a new name.)

I like the idea of fixing it outright, and leave the old level command alone. Then everyone can use the new facility to make this work, and eventually the old approach can be discontinued. Trying to sneak in fixes may well result in more problems than solutions...