Polyglot now supports the UCI protocol:-)

[Michel]

This is a cross posting from TalkChess.

Here is a new version of Polyglot1.4w10 which makes it possible to use Polyglot books under UCI GUIs. People like Marc Lacrosse had asked for such a tool to make it easier (trivial in fact) to use PG books in ChessBase.

http://alpha.uhasselt.be/Research/Algeb ... CIb.tar.gz

See

http://alpha.uhasselt.be/Research/Algeb ... .4wUCI.TXT

for more details.

Here is a Windows executable

http://alpha.uhasselt.be/Research/Algeb ... lyglot.exe

To Fonzy Bleumers: since this version of Polyglot is fully compatible with 1.4w10 I hope you want to merge it in your tree. In that case I can explain the changes in more detail to you. If not then I will maintain it as a separate version.

[Michel]

Buglet.

PG 1.4w10UCIb does not pass on setoption commands from the GUI to the Engine.

I will put up new sources tonight, as well as a new Windows binary.

Michel

[F. Bluemers]

This is a cross posting from TalkChess.

Here is a new version of Polyglot1.4w10 which makes it possible to use Polyglot books under UCI GUIs. People like Marc Lacrosse had asked for such a tool to make it easier (trivial in fact) to use PG books in ChessBase.

http://alpha.uhasselt.be/Research/Algeb ... CIb.tar.gz

See

http://alpha.uhasselt.be/Research/Algeb ... .4wUCI.TXT

for more details.

Here is a Windows executable

http://alpha.uhasselt.be/Research/Algeb ... lyglot.exe

To Fonzy Bleumers: since this version of Polyglot is fully compatible with 1.4w10 I hope you want to merge it in your tree. In that case I can explain the changes in more detail to you. If not then I will maintain it as a separate version.

Hi Michel,
Haven't looked at it yet,but I will.
Best
Fonzy

[Alex Guerrero]

Thanks Michel.

Might you do a Polyglot for winboard engines too?

Best.

[Michel]

Might you do a Polyglot for winboard engines too?

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.

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

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

[H.G.Muller]

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. Perhaps under control of an argument that can suppresses this. This should be done in such a way that the WB commands overrule what might be in the polyglot.ini file for that same parameter. I am not sure how this works in UCI, but I sppose this is automatic if the commands triggered through WB protocol are sent later than those from the polyglot.ini file. (Or is it an error in UCI to repeat an option with another value?)

I understand that cores would be a problem, as there is no defined standard to do this in UCI. So I guess the implied standard for this is the way Shredder does it. So would it be possible to send this option in Shredder syntax to the UCI engine? We could even make the feature smp=1 that Polyglot would send to WinBoard dependent on the UCI engine announcing that it knows this option (where Polyglot would have to recognize the Shredder syntax for it).

The memory command also present a slight problem, in the sense that WB specifies the total memory, and Polyglot would have to split it into an EGTB cache and a hash size. This could be done by passing it as hash size, after subtracting the EGTB cache size + 1MB. This assumes that Polyglot is aware of the EGTB-cache-size setting of the engine, though.

The Nalimov path can simply be passed on to the engine.

[Michel]

This is all trivial to implement. But I'll wait for Fonzy to decide on my UCI changes. I think it would be bad to have multiple incompatible forks of Polyglot around.

Perhaps the best is to set up a SVN repo for Polyglot at SourceForge.

Michel

[Michel]

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

[Michel]

Bugfixed 1.4w10UCIb1 here

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

[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.