WB-engine authors please note!

[bob]

Probably this subject would be more natural on the wbforum but as the thread was initiated here I'll reply here.

The main question is:

Who should save settings for an engine? Winboard/Xboard or the engine.

I think it should be the Winboard as this is what all other GUIs do but H.G. Muller thinks it should be the engine.

His main argument is that WB is not an engine manager but a tool to make two engines play with each other. A true engine manager can still supply options to engines at startup through the initString option.

Making the engine save the options entails a modification of polyglot so I would like to hear some input on this.

How can the engine _not_ save the parameters? For example, you tell Crafty to use 384M of memory for hash tables. how can it _not_ remain aware of that for the duration of the time the program sits in memory playing games? To change it, it has to first release the old hash table memory, then malloc() it again for the new size. I need to know how big the thing is so that I can address it properly by using the proper number of bits from the hash signature. I don't get rid of it between games, I hang on to it until specifically told to change it. Ditto for other parameters, many of which are done at initialization time, not between games (egtb initialization, etc.)

Of course, but they were talking about saving state between different executions of the program. And the answer is GUI!!!

That's not the discussion I was involved in. It was about what happens with the "new" command which is not "different executions"... Across executions, I depend on the crafty.rc/.craftyrc file, which is the normal way of setting default values for any program.

[Sven]

Probably this subject would be more natural on the wbforum but as the thread was initiated here I'll reply here.

The main question is:

Who should save settings for an engine? Winboard/Xboard or the engine.

I think it should be the Winboard as this is what all other GUIs do but H.G. Muller thinks it should be the engine.

His main argument is that WB is not an engine manager but a tool to make two engines play with each other. A true engine manager can still supply options to engines at startup through the initString option.

Making the engine save the options entails a modification of polyglot so I would like to hear some input on this.

How can the engine _not_ save the parameters? For example, you tell Crafty to use 384M of memory for hash tables. how can it _not_ remain aware of that for the duration of the time the program sits in memory playing games? To change it, it has to first release the old hash table memory, then malloc() it again for the new size. I need to know how big the thing is so that I can address it properly by using the proper number of bits from the hash signature. I don't get rid of it between games, I hang on to it until specifically told to change it. Ditto for other parameters, many of which are done at initialization time, not between games (egtb initialization, etc.)

Of course, but they were talking about saving state between different executions of the program. And the answer is GUI!!!

That's not the discussion I was involved in. It was about what happens with the "new" command which is not "different executions"... Across executions, I depend on the crafty.rc/.craftyrc file, which is the normal way of setting default values for any program.

Bob, your first reply in this thread was indeed directly related to the "new" command issue but your second reply was to Michel who in turn had replied to HGM (but without quoting) where a slightly different point was discussed:

I can add that I now also have a trial version of XBoard that implements the setting of engine-defined options through an XBoard menu, similar to what is possible with UCI engines. This is something I could include in a future release, if there is sufficient interest for it.

The way I implemented it is that the engine defines options at start-up through sending feature commands, like

feature option="MYOPTION -spin VALUE MIN MAX"

which would be the WB protocol equivalent of the UCI command

option name MYOPTION type spin default VALUE min MIN max MAX

(where the capitalized words should be replaced by an arbitrary text string and three integers, respectively). XBoard creates a menu popup according to the specification for the option, and whenever the user would use the menu to alter the value of an option, XBoard sends

option MYOPTION NEWVALUE

to the engine.

Would there be any interest amongst engine authors to use such a feature on their engines? My first experience is that it seems pretty useless, unless the engine remembers its option settings from one invocation to the next. Of course for playing-style options it might not be a big problem if at start-up the engine always reverts to its default style, and users would have to select the one they really want before they start playing. But on an engine with many options of a less volatile character, it would be a pain if the engine did not remember them.

Of course the engine could provide options for which of its settings to remember, and when, in the very same options menu, by defining a button 'save engine settings' there, or 'change defaults', or whatever. That would be entirely up to the engine.

Feedback welcome! Send me a PM if you want to have a trial version of XBoard that implements this. (Not available in WinBoard yet, as I don't know how to make dynamically formatted dialofgs in Windows; in WinBoard all menus are statically defined.)

EDIT: I wrote the following below (now quoted) but then saw that I misunderstood the concept since it is *not* about command line parameters. Sorry, I have to rethink again ...

So here we are talking about HGM's idea about a very specific kind of settings that shall be remembered somewhere: command line parameters which WB/XBoard shall pass on (next) invocation of an engine on request of the engine (by "feature option=..."), and which may also be altered interactively.

If this feature would really make sense (I'm not sure yet if it does but it may be) then I would keep this away from the engine's own .ini files since these are for engine defaults while command line parameters that the GUI user can edit are something that *overrides* engine defaults. So it should be remembered by the GUI somehow.

Sven

[Sven]

Now that I'm beginning to understand what HGM's proposal is all about (sorry that the last two paragraphs of my previous post were initially based on my misunderstanding of the concept) I'd like to provide my thoughts about it, i.e. how it should be designed *if* it is decided to be done.

1. An engine declares user-changeable options by sending one "feature option=..." message to WB/XBoard (I call it WB here for brevity) per such option.

2. WB "somehow" is able to remember for each engine:
- all such options that the engine has declared up to now,
- with their type, default value, min and max values,
- and their current value (which can deviate from the default).

3. When WB receives a "feature option=" declaration it checks whether it already knows that option or not.

a) If WB already knows it then it also knows its current value (which is either the unchanged default or the most recent value set by a user), so it reports that value back to the engine with an "option ..." message at an appropriate time.

b) If the option is new for WB then it adds its declaration to its list of known option declarations and sets its value to the specified default value. There is no need to send back the value to the engine.

4. When a user alters an option's value WB shall store this new value in its list and also report it to the engine.

By this mechanism, the usual and expected hierarchy of overriding settings keeps intact, which is something like this:
- compiled-in values of the "server" (here the engine executable)
- are overridden by defaults from a config file of the "server" (here the engine.ini)
- are in turn overridden by saved values a user has specified last time
- are overridden by command line options at invocation time
- are overridden by current values a user sets interactively in the GUI.

Open issues for me are at least:
- How get option declarations ever removed from the GUI's list?
- A concept to allow to a user a clean "reset to defaults".

Sven

[hgm]

This is a pretty good summary of how a scheme might work, except that having both an engine.ini and compiled-in defaults might be over-doing it. But it is of course up to the engine how to handle that: an engine could define a 'Reset to defaults' option that would store the compiled-in values back into the .ini, after a previous 'Save' option would have changed the values there to what the user had altered through the WB interface.

WB would actually keep two lists (in volatile memory), namely the options the user specified (on the WB command line), and the options the engine specified (through features). The latter would be sent only at start-up of the engine (as all features are). WB would look in the user-supplied option list for a match, and if there is one, use it in stead of the value the engine reported in the feature. (Not caring if this was an engine default or a remembered altered value.) It would sent the altered value then back to the engine, with an option command.

For the remainder of the session, WB would hold the list of engine-defined options and their values, the latter being changeable by a human user through the menu. It would not need the command-line defined settings anymore; these would never be stored in the winboard.ini file, and might even contain non-valid options (unknown to the engine), which were ignored. The only thing WB remembers are the engine-defined options, their initial value, and their current value. But, not being WB command-line options, these would not go into the winboard.ini file when WB saved its settings.

A menu item could be provided to add the current engine, plus all non-default option settings (not only of engine options, but also of volatile WB optionas like -fd, -fUCI, or -variant, to the list of pre-defined engines in the winboard.ini. It might be debatable if this would have to automatically remove the entry for the same engine executable from this list or not. Perhaps WB should prompt the user for making this decision. When a user decided to save the engine this way, he could re-start it with all the same settings from the WB start-up dialog by simply selecting the entry.

This all applies only to WinBoard, as XBoard does not have a .ini file, nor a start-up dialog...

[bob]

This is a pretty good summary of how a scheme might work, except that having both an engine.ini and compiled-in defaults might be over-doing it. But it is of course up to the engine how to handle that: an engine could define a 'Reset to defaults' option that would store the compiled-in values back into the .ini, after a previous 'Save' option would have changed the values there to what the user had altered through the WB interface.

WB would actually keep two lists (in volatile memory), namely the options the user specified (on the WB command line), and the options the engine specified (through features). The latter would be sent only at start-up of the engine (as all features are). WB would look in the user-supplied option list for a match, and if there is one, use it in stead of the value the engine reported in the feature. (Not caring if this was an engine default or a remembered altered value.) It would sent the altered value then back to the engine, with an option command.

For the remainder of the session, WB would hold the list of engine-defined options and their values, the latter being changeable by a human user through the menu. It would not need the command-line defined settings anymore; these would never be stored in the winboard.ini file, and might even contain non-valid options (unknown to the engine), which were ignored. The only thing WB remembers are the engine-defined options, their initial value, and their current value. But, not being WB command-line options, these would not go into the winboard.ini file when WB saved its settings.

A menu item could be provided to add the current engine, plus all non-default option settings (not only of engine options, but also of volatile WB optionas like -fd, -fUCI, or -variant, to the list of pre-defined engines in the winboard.ini. It might be debatable if this would have to automatically remove the entry for the same engine executable from this list or not. Perhaps WB should prompt the user for making this decision. When a user decided to save the engine this way, he could re-start it with all the same settings from the WB start-up dialog by simply selecting the entry.

This all applies only to WinBoard, as XBoard does not have a .ini file, nor a start-up dialog...

I think it is still a difficult challenge. Programs indicate hash sizes in different ways. I have seen some use bytes, some use entries, at least one that used the power of 2 of the hash size (log2(hashsize) so that 24 would be 16mb) and so forth. I have seen one that uses 50% more than you tell it so that it can allocate two tables, one 1/2 as big as the other. Then there is pawn hash and egtb cache, and in my case split block cache, and such...

I think it is difficult to standardize until we really standardize. For example, xboard started with "easy/hard" to mean "ponder off" or "ponder on". Others used terminology like "permanent brain on" (where that came from I have no clue as it makes no sense to me). Every program is like a unique programming language when you look at the user interface. Many copied much of what is in Crafty, because most of the winboard protocol was defined as Tim and I worked together in the early 90's to add the features I thought important for playing on ICC. So we have some sort of standardization, but it is far from complete since winboard has never defined concepts such as how many processors, how much hash memory, how much egtb cache, etc...

[hgm]

Welll, of course we are talking only about compliant engines, that set their parameters in the way the protocol specifies. This applies to standard options common to all engines, globally set in the GUI, such as memory usage, nr of CPUs and EGT paths.

And the advantage of the engine-specific options is that they never would be changed other than through user intervention, and humans are a lot more clever in interpreting the wording with which the engines describe their options than an automated GUI could. The GUI really never would have to understand what these options mean.

[Michel]

- compiled-in values of the "server" (here the engine executable)
- are overridden by defaults from a config file of the "server" (here the engine.ini)
- are in turn overridden by saved values a user has specified last time
- are overridden by command line options at invocation time
- are overridden by current values a user sets interactively in the GUI.

Ok there seems to be some agreement.

Now what about personalities? What if you want to use the same engine with different
settings. Who should provide that service? The GUI or the engine.

I think being able to tweak a parameter and play against an untweaked version of an an engine is very important.

I'll repeat my proposal from another thread (which didn't get any feedback).

xboard would get new options -firstChessProgramPersonality -secondChessProgramPersonality

(short: -fp, -sp)

xboard would use these personalities for persistence of options. If these options were not supplied xboard would use the default engine name.

A typical command line would be

xboard -fcp fruit -scp fruit -sp enhancedkingsafety

[hgm]

I would think that multiple personalities would be a matter best handled by the engine manager / tournament manager. I would like to see such personalities as different entries in the list I can draw engines from to put them in a tournament. In many cases the modified versions would be separate compiles, sitting in a different directory, and they would need another engine command. In other cases they might require another engine command line (e.g. to run Fairy-Max with an alternative fmax.ini file). Some installs have different WinBoard options (e.g. time-handicapped versions, carrying a -%sTimeOdds N option, %s = first or second).

For engines which allow setting of their parameters through the protocol, I think an argument -%sOptions "style Karpov,Curse in Russian,blunder rate 0" would be sufficient for relaying a personality from TM to WinBoard. There would be no reason to first put it in a file, and then send the file name as a -%sPersonality option.

Of course engines are free to maintain their own database of personalities. They could define their own option feature option="Personality -string default", and react to the sending of option personality filename by loading parameters from the mentioned file, and resending all read option settings to the GUI. And an option feature option="Create Personality -string ", for saving the current settings on a newly created file. Such engines could be configured by passing WinBoard the single option -%sOptions="Personality Karpov.ini".

[Michel]

Ok, so WB/XB will remember one set of settings for an engine but not more.

Fair enough if that is what people think is the best.

Something else. How do you tell the engine to return to its factory setting? If the engine
remembers its previous settings the factory settings would be lost forever.

EDIT: I can guess your reply It up to the engine to provide a button "Return to factory settings".

[hgm]

Indeed. If an engine supplies an opton to change its settings, I would expect it to also have an option 'restore defaults'. Even my BIOS has that.

But it is not an obligation for an engine to have this.

The regular way of doing things, which I would design XBoard for, is that it is totally without memory, and simply does what the user tells it to do through command-line options or menus. For simple interactive tasks, (human-engine or human-ICS, or perhaps even zippy mode) the menus might do. nd if the menus are too cumbersoem, the user can use a script to do it through command-line options.

But the rcomended way to do it would be through the use of a TM. If you want to play Toga in 'Claudius personality', just start the TM, click 'Toga-Claudius' and 'Launch engine', and it will pop-up XBoard with the engine in the desired personality. Quit XBoard, and the TM window behind it will be revealed, so you can click another engine.