New Time Controls for WB

Discussion of chess software programming and technical issues.

Moderators: hgm, Harvey Williamson, bob

Forum rules
This textbox is used to restore diagrams posted with the [d] tag before the upgrade.
User avatar
Matthias Gemuh
Posts: 3234
Joined: Thu Mar 09, 2006 8:10 am
Contact:

New Time Controls for WB

Post by Matthias Gemuh » Mon Aug 30, 2010 7:20 pm

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.
My engine was quite strong till I added knowledge to it.
http://www.chess.hylogic.de

User avatar
Matthias Gemuh
Posts: 3234
Joined: Thu Mar 09, 2006 8:10 am
Contact:

Re: New Time Controls for WB

Post by Matthias Gemuh » Mon Aug 30, 2010 7:48 pm

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

User avatar
hgm
Posts: 22327
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: New Time Controls for WB

Post by hgm » Mon Aug 30, 2010 9:38 pm

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?

User avatar
michiguel
Posts: 6269
Joined: Thu Mar 09, 2006 7:30 pm
Location: Chicago, Illinois, USA
Contact:

Re: New Time Controls for WB

Post by michiguel » Mon Aug 30, 2010 9:54 pm

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?
==> 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

User avatar
Matthias Gemuh
Posts: 3234
Joined: Thu Mar 09, 2006 8:10 am
Contact:

Re: New Time Controls for WB

Post by Matthias Gemuh » Mon Aug 30, 2010 9:54 pm

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

User avatar
Don
Posts: 5106
Joined: Tue Apr 29, 2008 2:27 pm

Re: New Time Controls for WB

Post by Don » Thu Sep 02, 2010 9:13 pm

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

User avatar
hgm
Posts: 22327
Joined: Fri Mar 10, 2006 9:06 am
Location: Amsterdam
Full name: H G Muller
Contact:

Re: New Time Controls for WB

Post by hgm » Thu Sep 02, 2010 9:36 pm

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.

User avatar
michiguel
Posts: 6269
Joined: Thu Mar 09, 2006 7:30 pm
Location: Chicago, Illinois, USA
Contact:

Re: New Time Controls for WB

Post by michiguel » Thu Sep 02, 2010 9:37 pm

Don wrote:
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?
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.)

User avatar
Don
Posts: 5106
Joined: Tue Apr 29, 2008 2:27 pm

Re: New Time Controls for WB

Post by Don » Thu Sep 02, 2010 10:04 pm

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.
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
Posts: 20347
Joined: Mon Feb 27, 2006 6:30 pm
Location: Birmingham, AL

Re: New Time Controls for WB

Post by bob » Fri Sep 03, 2010 2:03 am

Don wrote:
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.
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...

Post Reply