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.
New Time Controls for WB
Moderators: hgm, Rebel, chrisw
-
- Posts: 3245
- Joined: Thu Mar 09, 2006 9:10 am
New Time Controls for WB
My engine was quite strong till I added knowledge to it.
http://www.chess.hylogic.de
http://www.chess.hylogic.de
-
- Posts: 3245
- Joined: Thu Mar 09, 2006 9:10 am
Re: New Time Controls for WB
From Top 50, only 2 engines did not know what to do with "level" at the beginning of the 2nd TC session.
My engine was quite strong till I added knowledge to it.
http://www.chess.hylogic.de
http://www.chess.hylogic.de
-
- Posts: 27808
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: New Time Controls for WB
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?
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?
-
- Posts: 6401
- Joined: Thu Mar 09, 2006 8:30 pm
- Location: Chicago, Illinois, USA
Re: New Time Controls for WB
==> 2hgm wrote: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?
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
-
- Posts: 3245
- Joined: Thu Mar 09, 2006 9:10 am
Re: New Time Controls for WB
I like level MPS1 TC1 INC1 MSP2 TC2 INC2 ...
My engine was quite strong till I added knowledge to it.
http://www.chess.hylogic.de
http://www.chess.hylogic.de
-
- Posts: 5106
- Joined: Tue Apr 29, 2008 4:27 pm
Re: New Time Controls for WB
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.hgm wrote: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?
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.)
-
- Posts: 27808
- Joined: Fri Mar 10, 2006 10:06 am
- Location: Amsterdam
- Full name: H G Muller
Re: New Time Controls for WB
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.
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.
-
- Posts: 6401
- Joined: Thu Mar 09, 2006 8:30 pm
- Location: Chicago, Illinois, USA
Re: New Time Controls for WB
This is one of the threads in which this was discussed.Don wrote: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.hgm wrote: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?
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.)
-
- Posts: 5106
- Joined: Tue Apr 29, 2008 4:27 pm
Re: New Time Controls for WB
I wondered if there would be a compatibility issue. Could the session number be placed at the end?hgm wrote: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.
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.)
-
- Posts: 20943
- Joined: Mon Feb 27, 2006 7:30 pm
- Location: Birmingham, AL
Re: New Time Controls for WB
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...Don wrote:I wondered if there would be a compatibility issue. Could the session number be placed at the end?hgm wrote: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.
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.)