WB-engine authors please note!

[Michel]

Maybe a "screenshot" is in order...

Code: Select all

polyglot-1.4w10UCIb16$ polyglot -ec ./rybka.exe 
PolyGlot 1.4W10UCIb16 by Fabien Letouzey
protover 2
feature done=0
feature analyze=1
feature colors=0
feature draw=1
feature ics=1
feature myname="Rybka 2.2n2 mp 32-bit"
feature name=1
feature pause=0
feature ping=1
feature playother=1
feature reuse=1
feature san=0
feature setboard=1
feature sigint=0
feature sigterm=0
feature time=1
feature usermove=1
feature memory=1
feature smp=1
feature egt="nalimov"
feature variants="normal"
feature option="Hash -spin 32 2 4096"
feature option="Max CPUs -spin 2048 1 2048"
feature option="Display Draw Scores -check 0"
feature option="Engine Priority -combo Normal /// *NormalAndLow /// Low"
feature option="Display PV Tips -check 0"
feature option="CPU Usage -spin 100 1 100"
feature option="Win Percentage to Hash Usage -check 0"
feature option="Display Current Move -check 1"
feature option="Compensate Lost Time -check 1"
feature option="NalimovPath -string <empty>"
feature option="NalimovCache -spin 1 1 256"
feature option="NalimovUsage -combo Frequently /// Normally /// Rarely /// *Never"
feature option="Preserve Analysis -check 0"
feature option="Clear Hash -button"
feature option="Ponder -check 1"
feature option="MultiPV -spin 1 1 100"
feature option="UCI_ShowRefutations -check 0"
feature option="UCI_LimitStrength -check 0"
feature option="UCI_Elo -spin 1200 1200 2400"
feature option="Server Buffer -check 0"
feature option="UCI_AnalyseMode -check 0"
feature option="UCI_Opponent -string <empty>"
feature option="UCI_EngineAbout -string www.rybkachess.com"
feature option="Outlook -combo Very Pessimistic /// Slightly Pessimistic /// *Neutral /// Slightly Optimistic /// Very Optimistic /// Ultra Optimistic"
feature option="Rate Of Play -combo Ultraslow /// Slow /// *Normal /// Fast /// Ultrafast"
feature option="Time Usage -combo Constant /// *Varied"
feature option="Emergency Time Buffer -combo Small /// *Medium /// Large"
feature done=1

[hgm]

OK, looks good, except for the following:

The standard options Hash, NalimovCache, MaxCPUs should probably not be sent as feature option="..." command, because they already have been sent as as feature memory=1 egt=1 smp=1. And it is probably not a good idea to send them in duplicate.

I am not sure what the UCI option Ponder is supposed to do, but it sounds that this option is also already controlled through the hard / easy WB-protocol commands, and does not need an extra control in the engine-specific menu of a GUI.

Another issue:

From having a peek at the Polyglot source I can imagine why you rather have a reserved keyword as separator between the option and its value. This seems specific for Polyglot, though, and I don't blieve that in general parsing of the WB option command would be more difficult without such a separator: it is just a matter of looping through all option names and testing if they occur as a substring starting at position 7 in the input string that started with "option ". This is not more difficult than scanning the input for the substring "value" and then isolating what was before it, and string-comparing it to all option names. Except that in Polyglot you already happened to have a routine that did the latter.

I think the appearence of the -value keyword in every option command is a bit ugly and redundant; it merely trades one possible source of ambiguity during parsing (having two option names that could be made identical by giving the shortest a value that begines as the longest ends) for another one (confusion if someone uses the keyword as part of the option name).

For Polyglot, (and in fact in general for people that prefer one kind of ambiguity over another) I would recommend that it actually defines the separator between argument and value in all its options, as a single ":" character behind the UCI option name. The ":" would be displayed in the engine-options dialog before the control, which is fact could be considered a bonus.

[Michel]

I am not sure what the UCI option Ponder is supposed to do, but it sounds that this option is also already controlled through the hard / easy WB-protocol commands, and does not need an extra control in the engine-specific menu of a GUI.

I think "ponder" is to enable/disable pondering. The GUI still needs to send the appropriate commands to actually initiate pondering (which PG does of course).

I am not sure why you find

option NAME -value VALUE

ugly. A human would never see this no?

[hgm]

Ideally humans would not see it, but considering the enormous opposition I am getting elsewhere against implementing Tim Mann's multi-session level command, on the basis that it is not very readable to humans, it seems there are a great many people whose main hobby is to read winboard.debug files...

I guess it is also partly personal taste.

Is there anything against using:

option NAME: VALUE

in stead of

option NAME -value VALUE

?

As to the Ponder option, the UCI protocol specs say this:

Code: Select all

	The GUI should parse this and build a dialog for the user to change the settings.
	Note that not every option needs to appear in this dialog as some options like
	"Ponder", "UCI_AnalyseMode", etc. are better handled elsewhere or are set automatically.

This seems an explicit recommendation against having a Ponder control in the engine-specific options menu, and thus against Polyglot sending it as an option feature. XBoard is not really interested to know if an engine is able to ponder or not; it sends a hard command if an engine is allowed to ponder, and the engine can decide what to do with that.

I guess having a separate control that overrules the GUI ponder setting by disabling pondering in some hidden menu will in practice only invite mistakes by the user.

It seems the UCI_AnalyseMode should similarly only be used as a translation of the WB-protocol analyze command. For options that are set automatically the engine-options dialog would not work correctly anyway, as XBoard is supposed to keep track of the current option settings, for display to the user, as well as for only sending a new setting to the engine if they really change. But for options that are automatically changed on other ocasions, it would lose track of the current settings.

[Michel]

Well the specification of "ponder" seems to be sufficiently ambiguous that the engines
seem to consider it as a noop. For example toga2 reports ponder=false but can
ponder anyway. Glaurung reports ponder=true and setting this to false seems to have
strictly no effect.

Could you provide me with a list of options you would want PG to filter out?

On the other hand one thing I want to do is to include (some of) the options
of the PG config file. I would prefix their name by "Polyglot". For example when in UCI mode PG reports an option

option name Polyglot BookFile type string default <value>

which is very convenient because then people can set the PG book in the GUI.
I want to do this in xboard mode as well.

Is there anything against using:

option NAME: VALUE

in stead of

option NAME -value VALUE

Well the opposite question is just as valid.

I prefer keyword argument. One of the reasons why for example scripting languages
like Python are so nice is that they allow keywords arguments to functions.
This makes the functions self documenting.

Anyway in this case the use of keywords is nicely symmetrical with the use of keywords
in the feature option="..." string.

[Michel]

Maybe

option NAME = VALUE ?

This looks better than option NAME: VALUE.

For buttons nothing would change.

[Michel]

* = Ponder, type check
this means that the engine is able to ponder.
The GUI will send this whenever pondering is possible or not.
Note: The engine should not start pondering on its own if this is enabled, this option is only
needed because the engine might change its time management algorithm when pondering is allowed.

Ok I understand. You are right. It seems that there is no need to send ponder as it is strictly part of "hard".

So it seems the options that have to be filtered out are

UCI_AnalyseMode
Ponder
Hash
Thread
NalimovPath

[hgm]

option NAME = VALUE indeed also looks good. But why not leave it up to the engine? it can define the option through

feature option="NAME = -string VALUE"

or

feature option="NAME: -string VALUE"

or

feature option="NAME -string VALUE"

as it pleases.

[Michel]

option NAME = VALUE indeed also looks good. But why not leave it up to the engine? it can define the option through

There seems to be a misunderstanding. I am talking about the commands the
GUI sends to the Engine.

Not the sytax of the "feature" command (this is sent by the Engine to the GUI). This is fine as it is and I don't see any reason to change it.

[Michel]

Ok I posted a new version of b16 here.

http://alpha.uhasselt.be/Research/Algeb ... ot-release

This version is entirely config file less. All options from the [PolyGlot] section are exported
and settable through the GUI. The Polyglot options have their name prefixed by
"Polyglot" so the GUI can filter these easily.

Screenshot:

Code: Select all

polyglot-1.4w10UCIb16$ polyglot -ec ./rybka.exe 
PolyGlot 1.4W10UCIb16 by Fabien Letouzey
protover 2
feature done=0
feature analyze=1
feature colors=0
feature draw=1
feature ics=1
feature myname="Rybka 2.2n2 mp 32-bit"
feature name=1
feature pause=0
feature ping=1
feature playother=1
feature reuse=1
feature san=0
feature setboard=1
feature sigint=0
feature sigterm=0
feature time=1
feature usermove=1
feature memory=1
feature smp=1
feature egt="nalimov"
feature variants="normal"
feature option="Display Draw Scores -check 0"
feature option="Engine Priority -combo Normal /// *NormalAndLow /// Low"
feature option="Display PV Tips -check 0"
feature option="CPU Usage -spin 100 1 100"
feature option="Win Percentage to Hash Usage -check 0"
feature option="Display Current Move -check 1"
feature option="Compensate Lost Time -check 1"
feature option="NalimovCache -spin 1 1 256"
feature option="NalimovUsage -combo Frequently /// Normally /// Rarely /// *Never"
feature option="Preserve Analysis -check 0"
feature option="Clear Hash -button"
feature option="MultiPV -spin 1 1 100"
feature option="UCI_ShowRefutations -check 0"
feature option="UCI_LimitStrength -check 0"
feature option="UCI_Elo -spin 1200 1200 2400"
feature option="Server Buffer -check 0"
feature option="UCI_Opponent -string <empty>"
feature option="UCI_EngineAbout -string www.rybkachess.com"
feature option="Outlook -combo Very Pessimistic /// Slightly Pessimistic /// *Neutral /// Slightly Optimistic /// Very Optimistic /// Ultra Optimistic"
feature option="Rate Of Play -combo Ultraslow /// Slow /// *Normal /// Fast /// Ultrafast"
feature option="Time Usage -combo Constant /// *Varied"
feature option="Emergency Time Buffer -combo Small /// *Medium /// Large"
feature option="Polyglot Log -check 0"
feature option="Polyglot LogFile -string polyglot.log"
feature option="Polyglot UseNice -check 0"
feature option="Polyglot NiceValue -spin 5 0 20"
feature option="Polyglot Chess960 -check 0"
feature option="Polyglot Resign -check 0"
feature option="Polyglot ResignMoves -spin 3 0 10000"
feature option="Polyglot ResignScore -spin 600 0 10000"
feature option="Polyglot MateScore -spin 10000 0 1000000"
feature option="Polyglot Book -check 0"
feature option="Polyglot BookFile -string book.bin"
feature option="Polyglot BookRandom -check 1"
feature option="Polyglot BookLearn -check 0"
feature option="Polyglot KibitzMove -check 0"
feature option="Polyglot KibitzPV -check 0"
feature option="Polyglot KibitzCommand -string tellall"
feature option="Polyglot KibitzDelay -check 0"
feature option="Polyglot ShowPonder -check 0"
feature option="Polyglot UCIVersion -spin 2 1 2"
feature option="Polyglot CanPonder -check 0"
feature option="Polyglot SyncStop -check 0"
feature option="Polyglot RepeatPV -check 0"
feature option="Polyglot PromoteWorkAround -check 0"
feature done=1