Polyglot now supports the UCI protocol:-)

[Michel]

If you change it while BikJump is playing, the new setting becomes effective on the next game, if you change it in between games and BikJump is first engine, it will require you to give an extra "New Game" command for it to become immediately active.

I don't really understand this. The way I wrote it the UCI engine should react immediately
to the cores command. Normally UCI is stateless.

I tested with Glaurung, Zappa and a modified Toga and it worked as it should.

I will look at BikJump to see what's wrong. Maybe it takes new settings only after the
ucinewgame command.

egtpath nalimov <path name>

Yes but not the other variants. There is no real standard for specifying say egbb bitbases.
I would want to wait a bit with that.

command, and ten rename it to Polyglot 1.5w?

I am still nervous about that. For all we know Fabien Letouzey might be working on
a new version of Polyglot. I think I will email him first to ask.

[Michel]

New version here.

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

It has been Debianized. You can now do

./configure
make deb

to produce a binary Debian/Ubuntu package for your system. This will probably fail the first
time around since you need some extra packaging tools for that. But the error messages
are quite clear.

[H.G.Muller]

Don't waste your time on it, I don't think it is a BikJump problem. If anything is wrong it is WinBoard! It only sends the memory command at the beginning of a new game. But for the first engine, it already starts the new game (by sending a new command) pre-emptively after te ending of the previous game. So if you change the value of the hash size in the menu, it is to late to ride with the new command for the upcoming game.

I don't want to automatically start a new game for every time the user used the Options->New Settings (Options -> UCI) menu, because he might very well do this during a game, and you don't inadvertantly want to kill that game.

Indeed only the nalimov case should be tranlated.

Although it is unlikely that Fabien is doing this, I think it is indeed a good idea to mail him.

[Michel]

Well I looked at BitJump v2.01 and apparently it has a harmless bug. It reports
the Hash option twice! (This has nothing to do with what we are discussing).

Indeed only the nalimov case should be tranlated.

Ok that's easy.

[H.G.Muller]

OK, I now fixed it in xboard such that when OK-ing the Engine Settings menu dialog, it triggers another New-Game event if no moves have been done yet in the current game. This will then make the first engine aware of the changes made in any settings. If a game is in progress, only the cores and ponder commands will be sent (if they were changed), ad changes in any other parameters (memory size, nalimov path, opening book) will only become effective after the game has finished.

This version sticks to the order I now prescribe for the new commands: cores is the last command before new, and egtpath is sent between memory and cores. The egtpath sent for Nalimov is now in the first place that specified in the -defaultPathEGTB parameter (which can be changed through the menu) if it is non-null and -egtFormats also specifies a Nalimov path. The latter parameter has to be non-null, though, for egtpath commands to be sent at all.

This is likely the final version, which will be released as 4.3.15; Source is uploaded to the usual place.

[Michel]

Once more a new version

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

This implement the egtpath nalimov command.

cores N, memory N, and egtpath nalimov <path> can be issued at any time.

If issued during a search then

PG stops the search;
sends the appropriate UCI commands to the engine;
sends isready;
waits for readyok;
computes the new remaining time for the engine
reissues a new search command with reduced engine time.

If issued before the first new command PG only sends the UCI commands to the engine.

EDIT: I have emailed Fabien Letouzey to ask for his permission to call this PG 1.5....

[H.G.Muller]

OK, I have compiled it, included it in the WinBoard Gold Pack, and will now release it.

I noted that CPW did not react to the memory command, but CPW seems buggy. (It also uses 99% of my CPU time before it starts playing, when ponder is off!) BikJump reacts instantly now.

[Michel]

I noted that CPW did not react to the memory command,

Ok that is easily explained. CPW does not support the Hash option....

I thought all UCI engines supported the Hash option so I automatically report

feature memory=1

I will change it right now.

[H.G.Muller]

No reason to change that. I think this is a CPW error,as the UCI specs clearly state that every engine should have it. It would not solve anything anyway if you would send memory=0: CPW would still not be able to change its hash size.

For the next WB version, when I will have added the option feature to allow WB to display the menu of engine-specific options for UCI engines, we will need a dialog like that, though.

[Michel]

Ok b9 at

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

I spotted an additional small bug (egt enabled smp automatically!).

The windows executable is up to date. It was compiled with

Code: Select all

gcc -O2 -mno-cygwin -D_WIN32 *.cpp -opolyglot

It also uses 99% of my CPU time before it starts playing, when ponder is off!

Yes this is strange. It does not happen in a terminal on windows. But it does happen
if you start the engine in Arena or under Wine.

[Guenther Simon]

OK, I have compiled it, included it in the WinBoard Gold Pack, and will now release it.

I noted that CPW did not react to the memory command, but CPW seems buggy. (It also uses 99% of my CPU time before it starts playing, when ponder is off!) BikJump reacts instantly now.

From a bug report here in the forum 11/2008

I found that the newest version of CPW 050908JA here uses 50% of the
opponents CPU under WB with ponder off on my P4!

http://www.open-aurec.com/wbforum/viewtopic.php?t=49646&highlight=cpw

Guenther

[Michel]

No reason to change that. I think this is a CPW error,as the UCI specs clearly state that every engine should have it.

Well maybe it's a bug, but not sending "feature memory=1" is a good idea anyway since it alerts the user that there is something strange about the engine (otherwise he might think Polyglot is buggy).

I found that the newest version of CPW 050908JA here uses 50% of the
opponents CPU under WB with ponder off on my P4!

I am not sure if it is actually pondering. Maybe it is just stuck in some polling loop.

[Michel]

I found that the newest version of CPW 050908JA here uses 50% of the
opponents CPU under WB with ponder off on my P4!

I think I understand it. CPW detects if its reading from a pipe and in that case it seems to use PeekNamePipe in a busy loop to detect input.

I have not actually verified this theory since I don't like compiling on WIndows.

Putting a small delay in the busy loop would solve the problem.

Incidentally this is exactly the strategy PG uses on Windows. I think it might be better to use WaitForMultipleObjects. This is the windows analogue of select. In this way the Linux and Windows version could share more code.

[Guenther Simon]

No reason to change that. I think this is a CPW error,as the UCI specs clearly state that every engine should have it.

Well maybe it's a bug, but not sending "feature memory=1" is a good idea anyway since it alerts the user that there is something strange about the engine (otherwise he might think Polyglot is buggy).

I found that the newest version of CPW 050908JA here uses 50% of the
opponents CPU under WB with ponder off on my P4!

I am not sure if it is actually pondering. Maybe it is just stuck in some polling loop.

Well, I did not write it ponders when it shouldn't. I just wrote it still uses
50% of the cpu when it shouldn't...it is not relevant if actually ponders or
simply doesn't release threads, because the effect is still the same for
tests in rating games under ponder off conditions.

Guenther

[Michel]

b10 here

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

The most notable addition is that the "epd-test" option has been documented.
This was a hidden gem in Polyglot. I have also made the output of epd-test somewhat
more readable.

Code: Select all

$ ./polyglot epd-test -epd Mats.epd
PolyGlot 1.4W10UCIb10 by Fabien Letouzey

EngineName=BikJump v2.01 (32-bit)

[Search parameters: MaxDepth=63   MaxTime=5.0   DepthDelta=3   MinDepth=8   MinTime=1.0]

 1: MATS001         OK    1 [at: depth= 7 time=  1.02 nodes=   329898] score= +0.86 pv=d6 Rxc3 Nxf6+ Kf8 dxe7+ Kg7 e8=N+ Kf8 bxc3 h5
 2: MATS002         OK    2 [at: depth= 6 time=  0.96 nodes=   355243] score= +0.34 pv=e4 Ng6 e5 Nxe5 dxe5 Qxe5 O-O c5
 3: MATS003         OK    3 [at: depth= 1 time=  0.00 nodes=       94] score= +1.12 pv=Qg4 Qb5 Qc4 Qd7 Qc7 Qb5 Rxe8+ Rxe8 Rxe8+ Qxe8
 4: MATS004         --    3 [at: depth= 1 time=  0.00 nodes=       20] score= +1.48 pv=Bxe4+ Nxe4 Qxh2+ Qxh2 Nxh2 Rfc1 Ng4 Nd6 Rxc1+ Rxc1
 5: MATS005         --    3 [at: depth= 1 time=  0.00 nodes=       32] score= -0.21 pv=Rd1+ Kf2 Rd2+ Kf1 Rd1+ Ke2 Rh1 h3 Ra1 a3
 6: MATS006         OK    4 [at: depth= 1 time=  0.00 nodes=       80] score= +0.60 pv=d6 Rc6 h5 Rxc1 Rxc1 Nf8 Rc7 Qe6 Qc2
 7: MATS007         OK    5 [at: depth= 1 time=  0.00 nodes=       11] score= +0.04 pv=b4 g4 Kc7 Ke3 Kb7 Bc2 Nc4+ Ke2 Nb6 h5
 8: MATS008         --    5 [at: depth= 7 time=  0.37 nodes=   144773] score= +0.17 pv=f5 Bb7 fxe6 fxe6 Ne2 a5 Nd4 b4 Bh3 Rxf1+
 9: MATS009         OK    6 [at: depth= 6 time=  0.14 nodes=    37187] score= +0.36 pv=Rc5 bxc6 b4 f5 a4 Ke7 b5 axb5 axb5 Kd6
10: MATS010         --    6 [at: depth= 8 time=  1.21 nodes=   419280] score= +0.02 pv=Rac1 Ne6 b4 f6 a4 Rg6 Nf5 Qc7 b5 Ng5
11: MATS011         --    6 [at: depth= 8 time=  4.84 nodes=  2073725] score= +0.13 pv=Qf3 h6 Bh4 Rc8 Rc1 Qb6 Rxc8 Rxc8 Qd1
12: MATS012         --    6 [at: depth= 1 time=  0.00 nodes=      134] score= +2.19 pv=Qxe2 Ra3 Rf8 Bf3 Qe3+ Rf2 Bxa5 Rxa5 Qxd3 Re5+
13: MATS013         OK    7 [at: depth= 4 time=  0.09 nodes=    12136] score= +0.78 pv=Nxf5 Bxc3 Nxd6 Qb8 Nxe4 Bd4 Ng5 a6 e4 Qe8
14: MATS014         --    7 [at: depth=10 time=  4.93 nodes=  2043238] score= -0.01 pv=Re7 c3 c6 Bc2 a5 Rf3 Rb7 Bd3 g5 Be2
15: MATS015         OK    8 [at: depth= 2 time=  0.01 nodes=     3024] score= +1.12 pv=Qh4 Be3 Bb4 Nc3 Nxe5 Qd4 Ng4 Bf4
16: MATS016         OK    9 [at: depth= 3 time=  0.00 nodes=     2029] score= +0.12 pv=hxg4 fxg4 f5 gxf5 gxf5 exf5 Nxd5 Be1 Bf4 h5
17: MATS017         --    9 [at: depth= 8 time=  0.24 nodes=    75841] score= -0.45 pv=Ke8 a3 Bg1 Bc7 Ke7 Kg2 Ba7 Kf3 Bc5 b4
18: MATS018         --    9 [at: depth= 8 time=  2.02 nodes=   770916] score= +0.44 pv=Rd8 h4 Kf8 Rb1 Rb8 a3 Ba4 Re1 a6 Nb3
19: MATS019         --    9 [at: depth= 4 time=  0.00 nodes=     1493] score= +1.06 pv=Bf5 Bb5 Re4 Bd3 Rxd4 Bxf5 gxf5 Rb1 b5 Rxb5
20: MATS020         OK   10 [at: depth= 8 time=  0.77 nodes=   292387] score= -0.53 pv=h5 R1d3 Rh6 Rc3 Rg6 g3 e5 Rxg6 fxg6 h3
21: MATS021         --   10 [at: depth= 6 time=  0.43 nodes=   131731] score= +0.30 pv=Qh5+ g6 Qf3 Qxf3 Nxf3 Nxb3 axb3 h6 Bf4 Bc5
22: MATS022         --   10 [at: depth= 1 time=  0.00 nodes=      267] score= -0.06 pv=Bc5+ Kh1 d4 Ne4 Bb4 Kg1 Qh7 Qf2 Rhf8 Ba4
23: MATS023         --   10 [at: depth= 1 time=  0.00 nodes=       35] score= +1.53 pv=Bxf8 Qxf8 Rb1 Bc3+ Kf1 Be6 Kg1 Rd8 Qc1 h6
24: MATS024         --   10 [at: depth= 1 time=  0.00 nodes=       52] score= +0.19 pv=O-O-O Nc3 f6 Qe2 Nb6 O-O-O Qd7 h4 Bc5

score=10/24 [averages on correct positions: depth=3.9 time=0.30 nodes=103209]


EDIT: It is now also possible to do

./configure
make rpm

to make a binary for Fedora/Suse etc...

[abik]

It reports
the Hash option twice! (This has nothing to do with what we are discussing).

What are the odds!!

When I released v2.01 to provide a quick bug fix, I was actually working on the SMP version and had just copied and pasted this line in order to add a "Processor" option later (see CCC for a fruitless attempt to standardize this single keyword). I found the "Hash" duplication right after I released v2.01. Since I estimated the probability someone would notice this astronomically small, I decided to simply fix this silently in a follow-up version. You just proved me wrong

In the next version the duplicated line will actually read what I truly intended:

Code: Select all

id name BikJump v2.1P (64-bit)
id author Aart J.C. Bik
option name Hash type spin default 32 min 1 max 65536
option name NalimovPath type string default
option name NalimovCache type spin default 8 min 1 max 2048
option name Ponder type check default true
option name Processors type spin default 1 min 1 max 4
uciok


[Zach Wegner]

When I released v2.01 to provide a quick bug fix, I was actually working on the SMP version and had just copied and pasted this line in order to add a "Processor" option later (see CCC for a fruitless attempt to standardize this single keyword).

Don't worry about it, you eventually picked the correct name.

[H.G.Muller]

Don't worry about it, you eventually picked the correct name.

That remains to be seen:

Polyglot will not regognize everything you pick as the equivalent to the standard option to set the number of SMP CPUs, and if you picked an option name that is not recognized by Polyglot, I would definitely say you picked a wrong name, no matter what it is.

[Michel]

option name Processors type spin default 1 min 1 max 4

These are the UCI options PG currently recognizes as setting the
number of threads.

Code: Select all

const char * thread_options[]={
  "number of threads",        // toga
  "number threads",           // Deep Learning Toga
  "threads",                  // glaurung, zappa, cyclone, grapefruit,
                              // Deep Shredder, Deep Junior
  "core threads",             // HIARCS
  "max cpus",                 // rybka
  "cpus",                     // Deep Sjeng, Fruit2.3.5
  "maxthreads",               // Naum
  NULL
};

While it is trivial to add yet another one, it would be nice if there was some
convergence.

[H.G.Muller]

So indeed the choice of "Processors" leads to a broken implementation. That makes the assertion that it is "the correct choice" rather dubious.