Polyglot now supports the UCI protocol:-)

[H.G.Muller]

Actually I have a more general idea.

Why not add commands showoptions and setoption to the WB protocol. After "showoptions" the engine would respond with a list of its runtime settable options in UCI style

option <name> type <type> [default <default>] [max <max>] [min <min>] [var <var>]

These can be presented to the user in a dialog box.

If the user changes an option it can be send to the engine in UCI style

setoption name <name> value <value>

Michel

Some time ago we did discuss this possibility in another thread. The discussion did not come to a full conclusion yet. Considering what has been said there, my current preference is to use the WB feature command to send the option to the GUI as a text string, as

feature option="text string"

where the only thing special compared to other features woud be that this feature can be sent multiple times and will then all be remembered (in stead of just the one that was sent last. This way of doing it does not break compatibility with older GUIs; they would simply reject the feature.

The text string describing the option would then define the name of the option, the type (supporting all UCI types, e.g. check, spin), and additional information depending on the type. The UCI syntax seems too silly to use, though. Why require keywords to specify a name or type is following, if a name and type have to be lways present? The order in which they come can identify them more efficiently. And if keywords would be needed, I think it would be better if they were recognizable, e.g. by all starting with '-'. That philosophy would result in a syntax

"name -type additional info"

where '-type' would be one of '-check', '-spin', '-combo' etc. Calling them 'type spin', 'type combo' etc. as UCI does just seems redundant: you need a reserved word anyway (type), so you might as well reserve spin and combo directly. The leading '-' plus the fact that there are only 5 types makes the type easy to recognize by the parser, and everything before it can automatically be identified as option name (in case it contans spaces).

As for the 'additional info': I was told that for type spin in UCI the min, max and default parameters are mandatory. That makes the min, max and default keywords totally redundant in this option. What could follow is simply 3 numbers. Similarly, type check needs only a default, and could be followed by a single number 0 or 1. For type string everything that follows (except the frirst space) can be nothing else but default value. Type button does not seem to need additional information at all (unless I misunderstand what it does). Only for type combo there seems an issue: this has a variable number of text arguments, which could be space-containing. So the text that follows has to be parsed into individual values. This coud be done by preceding each of them with 'var', as UCI does, but it would seem much more natural to me to separate them with a single reserved character unlikely to occur in the arguments. But I guess there is something to be said for a multi-character separator, as it reduces the likelihood you would want this separater to occur as (part of an) argument. Using 'var' as separator seems a very bad choice; '-var' would already give a much better readability, but IMO '///' would be much clearer.

So you would get

feature option="EGTB cache size -spin 0 8 4"
feature option="style -combo patzer /// very good /// world champion -default very good"
feature option="book -string C:\books\big.bin"
feature option="resign -check 1"
feature option="clear hash now -button"

WinBoard would then use these options (when the user triggered this from a menu) by sending:

option EGTB cache size 6
option style world champion
option book .\book.dat
option resign 0
option clear hash now

The only thing I have doubts about is the -default in the -combo control. It seems stupid (and a source of error) to have to repeat a value that was already given in the list before. IMO it would be better to somehow mark the default value, e.g. by preceding it with an asterisk:

feature option="style -combo patzer /// *very good /// world champion"

[Alex Guerrero]

What do you mean exactly? An adaptor "WB protocol=>WB protocol" that allows you to use polyglot books? I have been thinking about that. It should not be hard.

Yes.

But I think it more urgent to have an open source version of Wb2UCI.

Of course.

You can use PG books in Winboard engines with the new Winboard/Xboard 4.3.15.

I would like to use Polyglot Books in Chessmaster and others GUI too for winboard engines.

Best.

[Michel]

I would like to use Polyglot Books in Chessmaster and others GUI too for winboard engines.

Ok I understand!

I'll see what I can do (but now I have to catch up with work),

Regards,
Michel

[Michel]

What I would very much like to see (hoping that you or Fonzy can quickly implement this) is that Polyglot would translate the new WinBoard commands memory, cores and egtPath nalimov, and pass them to the UCI engines.

The way I do "cores" in ucibench is to have a hardcoded list of all known UCI options that affect this.

Code: Select all

char * thread_options[]={
  "number of threads",        // toga
  "number threads",           // Deep Learning Toga
  "threads",                  // glaurung, zappa, cyclone, grapefruit
  "core threads",             // HIARCS
  "max cpus",                 // rybka
  NULL
};

(isn't it amazing that the toga people could not even agree among themselves for such a simple thing...).

Unfortunately I have no idea what the "Shredder syntax" is. Googling didn't turn up anyting.

Instead of hardcoding this perhaps the options could be read from a file. If PG does not find a relevant option for the engine it could fall back on the "Shredder syntax", whatever it may be.

What do you think?

Michel

[Marc Lacrosse]

Unfortunately I have no idea what the "Shredder syntax" is. Googling didn't turn up anyting.

A few other ones :

Deep Shredder 11 : option name Threads
Deep Junior 10.1 : option name Threads
Deep Sjeng WC2008 : option name CPUs
Fruit 2.3.5m : option name CPUs

Marc

[Marc Lacrosse]

Naum 4 : option name MaxThreads

[Michel]

Thanks a lot!

Michel

[H.G.Muller]

What do you think?

I think the proper strategy here is to encourage standardization, as the diversity serves no purpose and is in fact very undesirable. So the best approach seem to me to support 'Threads' only. (This despite the fact that I like "max CPUs" best. UCI is SMK's protocol.) Engine authors will have to adapt, or live with the fact that the users of their engines must set this parameter in a cumbersome way when they run it under Polyglot.

Supporting multiple possibilities will only aggrevate the problem, as new SMP engines will randomly pick one, or even invent a new one under the assumption that we will start supporting that too.

Better take a firm stance.

[Michel]

Engine authors will have to adapt, or live with the fact that the users of their engines must set this parameter in a cumbersome way when they run it under Polyglot.

So you think you can convince the authors of commercial chess engines to adapt their programs to make them compatible with an obscure (in their view) open source program "Polyglot" which is necessary to make their engine run under "Winboard"? Given that all they care about are their own GUIs (ChessBase, Shredder etc).

I am all for standardization and it will happen eventually. But I think we are not in a position to impose it.

SInce the name of the "thread" UCI option is shown in the GUI it is not an arbitrary choice. There was a recent discussion on TC about this and it did not come to any conclusion (with for example Robert Hyat being very vocal saying that "Threads" is absolutely the wrong choice for the name of the option).

Open source project fall too often into the trap of trying to impose standards when they are not in a position to do so.

Given that keeping a (small) community maintained list of thread options is very easy I am strongly in favor of doing it that way. After all our mission is to serve the users, not the developers.

Michel

[H.G.Muller]

Basically you point out that we should look what GUIs do, not what engines do. Engine authors of commercial engines that do not also provide a GUI are likely to follow standards, as they like their engine to function under existing GUIs. Problem is that other GUIs apparently do nothing yet. But I think it is extremely likely that once the Shredder GUI will decide to implement a GUI option for nr of CPUs (as opposed to an engine option), it will follow the Shredder engine. Chessbase have their own native format, and do not care much about UCI; they only support it because of popular demand. So they will likely follow whatever others finally agree on.

I am afraid that supporting everything that is around will only slow down the natural process of convergence. How about this then:

I suppose Polyglot is aware of what engine is playing. You could make it such that Polyglot recognizes the important commercial engines by name, and for each engine defines a list of egnine-specific UCI options that we would like to be a GUI-wide option, and substitutes the name for it that we consider standard for that option. Engines that are not know to Polyglot would have to use the standard if they do not want to be treated as engine-specific options.

This prevents that the World will divide up into camps of Rybka followers, Shredder followers, etc., before the important GUI writers decide on a standard.

You should consider all this just as suggestions: I do not really care about UCI protocol at all, and recognizing every soption under the sun that contains words like cpus, threads, processors or cores would also be fine with me.

[Denis P. Mendoza]

(isn't it amazing that the toga people could not even agree among themselves for such a simple thing...).

I thought we we're amongst a few to notice it. Aren't you also a Toga (TDDB) member pal ? Your inputs are much appreciated...thanks!

So you think you can convince the authors of commercial chess engines to adapt their programs to make them compatible with an obscure (in their view) open source program "Polyglot" which is necessary to make their engine run under "Winboard"? Given that all they care about are their own GUIs (ChessBase, Shredder etc).

Convincing commercial authors is another story...not to mention standardization. But there's always a time to try/start with something good. And I agree, this is strongly in favor to serve the users of Winboard and Polyglot.

[Michel]

Polyglot1.4w10UCIb2 is here

http://alpha.uhasselt.be/Research/Algebra/Toga/

Some bug fixes and support for the "cores N" and "memory N" commands.

The "cores N" command requires that the engine can change the number of threads
at arbitrary times, not just in the initialization faze.

The current versions of Toga can not do this (except Cyclone).

An experimental version of Toga 1.4.1SE that can do this can be found at

http://alpha.uhasselt.be/Research/Algeb ... x_versions

For an explanation of the changes necessary for a generic Toga see here

http://alpha.uhasselt.be/Research/Algeb ... reads.html


Michel

[H.G.Muller]

Great! I will experiment with it a little!

I must admit that the current WB release I am preparing does not yet send intra-game cores commands, because they can only be generated from the menu, and previous versions did not have a menu for the nr of cores at all. But I certainly want to add that to future versions, so I had to put the requirement in the protocol description.

[Michel]

must admit that the current WB release I am preparing does not yet send intra-game cores commands

Unfortunately that does not help for Toga. The initialization sequence of PG is as follows.

Send "uci"
Record options
Wait for "uciok"
Send PG options from the Engine section
Send "isready"
Wait for "readyok" (roughly)
Process commands from GUI

The versions I know of Toga (except cyclone) create the threads at the "isready" command and you cannot change their number afterwards. So to make "cores N" work for Toga PG would have to delay the "isready" command and there is no well defined moment to send it afterwards.

[H.G.Muller]

Would it help if I would let xboard send the cores command before the first new command, so that you could delay sending the isready to the first new command? I guess the same should hold for the memory command; I could imagine that some engines would have trouble changing their hash-table size after isready, or even would object against receiving a second hash-size option in the first place.

In the current way of doing it (memory and cores after new), you could wait for the first ping, which is basically the WB equivalent of isready. WB sends it after the memory and cores commands. But the protocol does not prescribe when the pings should come, (or, indeed, that it should come at all) so other GUIs might do this differently. But there is always guaranteed to be a new. The ponder-control commands hard and easy are send after the new, though.

You could start reading the polyglot.ini only after the new comes in.

[Michel]

If "new" is guaranteed to be sent by winboard the protocol it could be a good moment to send "isready" to the engine, allowing winboard to do some extra stuff in the initialization faze.

[[ Although I would prefer Toga to change also. It is the only engine I know that has trouble changing the numbers of cores after initialization. This is about 20 lines of c-code and there is a sample implementation and a detailed description of how to do it. ]].

[H.G.Muller]

There cannot start any game without a new command first. WB starts sending

xboard
protover 2

and then delays some time to make sure any feature commands will be received before anything else is sent. (Because what has to be sent depends on the features.) Only after the waiting periods times out, or after reception of feature done=1, WB does proceed sending stuff to the engine. The first thing it used to send in that case was always

new
random

The trial version I posted now does send memory, cores and egtpath just before the new, in case you want to experiment with it.

[Michel]

Ok the new version (1.4wUCIb3)

http://alpha.uhasselt.be/Research/Algebra/Toga/

delays "isready" till the new command.

I have only tested it command line. I hope there are no timing issues when used in real life.

Maybe the situation for Toga is not so bad after all. It seems DLT also supports changing the # of threads outside initialization (but not GrapeFruit).

[Michel]

There is a bug with time management.

I'll post a new version later.

Michel

[Michel]

New version (1.4w10UCIb4)

http://alpha.uhasselt.be/Research/Algebra/Toga/

Michel