WB-engine authors please note!

Michel · Post by **Michel** » Tue Jan 06, 2009 5:05 pm

But if the idea is to run Polyglot without using any ini file, just based on its command-line options, all UCI options would remain at their defaults, (until they are changed by the GUI through WB protocol), and altering the engine name would be hardly useful.

The engine name is what polyglot sends as "feature myname". I guess it is not necessary
to change it (it would have been useful if PG were to restore/save its own settings).

hgm · Post by **hgm** » Tue Jan 06, 2009 5:19 pm

I think it would be definitely useful to have such options for inifile-less running of Polyglot. In fact, if there is no ini file to be read, Polyglot does not really care which directory it is running in. So even the -engineDir option would not be needed, as the GUI could change to the engine directory before invoking Polyglot. So

polyglot -engineCommand "engine.exe engine command-line options"

(or perhaps polyglot -cp "..." for short) would be sufficient to use polyglot as an adapter to a GUI that could set all the options through WB protocol. PSWBTM could simply prefix the 'polyglot -cp ' to the engine name when it discovers the engine is UCI, and store any changes the user makes to the default option settings with the PSWBTM engine-configure menu incorporated in an InitString it stores for this engine in its engine database.

Michel · Post by **Michel** » Tue Jan 06, 2009 6:25 pm

Yes the EngineDirectory does not have to be set. That is a good point.

I think I would go for something

polyglot gui-mode -cp "<engine command>"

to be consistent with the other modes of invoking polyglot.

hgm · Post by **hgm** » Tue Jan 06, 2009 6:49 pm

First time I see a mode argument on Polyglot!

Isn't gui-mode the default mode? Remember: shorter = better! People somehow have to cram this in the input fields of PSWBTM, and the engine command can be long enough.

Michel · Post by **Michel** » Tue Jan 06, 2009 7:56 pm

The syntax of polyglot is

polyglot [configfile] [mode] [options]

The following come with stock polyglot.

Code: Select all

polyglot &#91;configfile&#93;
polyglot make-book &#91;-pgn inputfile&#93; &#91;-bin outputfile&#93; &#91;-max-ply ply&#93; &#91;-min-game games&#93; &#91;-min-score score&#93; &#91;-only-white&#93; &#91;-only-black&#93; &#91;-uniform&#93;
polyglot merge-book -in1 inputfile1 -in2 inputfile2 &#91;-out outputfile&#93;
polyglot &#91;configfile&#93; epd-test &#91;-epd inputfile&#93; &#91;-min-depth depth&#93; &#91;-max-depth depth&#93; &#91;-max-time time&#93; &#91;-depth-delta delta&#93;

I also plan to add perft. This is currently in the source but not exposed.

Remember: shorter = better!

This command is not supposed to be entered by a human but by a GUI or TM. So I don't
really see why the command should be short. xboard itself has very long options.

bob · Post by **bob** » Wed Jan 07, 2009 2:22 am

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

Zach Wegner · Post by **Zach Wegner** » Wed Jan 07, 2009 2:31 am

bob wrote:
Michel wrote: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!!!

hgm · Post by **hgm** » Wed Jan 07, 2009 11:36 am

There are many programs that do store their settings (hash size, but sometimes even piece values and eval parameters) on .ini files that they read themselves. I don't think it would be a totally crazy idea if such engines could also write these .ini files themselves, when some of the parameters have been changes through the interface. But it is upto the engines to provide this service, and to decide to which parameters it extends.

Sven · Post by **Sven** » Wed Jan 07, 2009 5:11 pm

hgm wrote:There are many programs that do store their settings (hash size, but sometimes even piece values and eval parameters) on .ini files that they read themselves. I don't think it would be a totally crazy idea if such engines could also write these .ini files themselves, when some of the parameters have been changes through the interface. But it is upto the engines to provide this service, and to decide to which parameters it extends.

I think the engine's own .ini files are not relevant here since there is no doubt that no other instance than an engine itself knows exactly about the intended contents, format and possibly consistency rules of its own .ini file, if there is one. So if there were really a situation where *that* engine.ini file should be updated somehow (I doubt there will in most cases) then only the engine could do that job. *BUT* these engine.ini files are most probably not meant here.

"Saving engine settings between two invocations" in this context I would understand as either updating the engine specific part of winboard.ini, or (when PolyGlot is used) polyglot.ini.

Regarding tournament managers and their role, I propose not to expect the existence and/or proper setup of a TM when designing changes to the WB protocol and/or WinBoard implementation. A TM is a really nice application but it is on top of both the WinBoard GUI and any engines, and we should in general not expect it is there when we are "on the WB level".

The latter means that for me it is not an option to say that "the TM" should care about storing any engine-specific settings. If we only want to express that neither the engine, nor WinBoard, nor an adapter like PolyGlot shall be responsible for storing engine-specific settings then I would prefer to say "the user" in this case, instead of "the TM", where "the user" could of course let a TM do this work for him.

Sven

hgm · Post by **hgm** » Wed Jan 07, 2009 5:24 pm

These ini files are exactly the ones that were meant here.

OK, so the TM can be the user. As long as it is not WB, WB does not care.

The WinBoard-specific part of the winboard.ini is an idea. (Except of course that there is no such thing as an xboard.ini, so any solution based on this would not work on XBoard.) This is a bit more general than just engine options: it would be logical if WinBoard had a menu command to add the current engine with the current settings to the start-up dialog combo boxes. It would only include WinBoard options with it that are not saved in the winboard.ini, and are currently different from their defaults.

WB-engine authors please note!

Re: WB-engine authors please note!

Re: WB-engine authors please note!

Re: WB-engine authors please note!

Re: WB-engine authors please note!

Re: WB-engine authors please note!

Re: WB-engine authors please note!

Re: WB-engine authors please note!

Re: WB-engine authors please note!

Re: WB-engine authors please note!

Re: WB-engine authors please note!