Page 1 of 1

UCI, ownbooks, and a potential problem

Posted: Mon Jun 16, 2014 4:36 pm
by michiguel
Gaviota checks when is out of book, and if it was out of book 20 plies earlier, never checks again to see if it is "back on book" to improve efficiency (it is sillly to check if it is in book in the endgame, for instace). The problem is that in UCI, all moves are fed from the beginning, so Gaviota "feels" it was out of book since move one, and by move 10, stops checking. In winboard, I have a "scoresheet" structure that keeps information of the whole game (moves, when it was out book etc.). In UCI, of course this is recreated every single move.

This is a consequence that Gaviota was born as winboard, and in the translation, some of this "cultural differences" were overlooked. Fixing this will require a counter reset with ucinewgame or something like that. Arggh.

Maybe some other people have a similar issue.

Miguel
PS: Found in Luca's tournament. Thanks! I always use Gaviota in winboard mode and most other people never uses ownbooks, so this issue remained untested for a looong time. To make things more difficult to catch, Gaviota uses the book, but it is out of it earlier. Only by watching the games live you start to be suspicious something is funny.

Re: UCI, ownbooks, and a potential problem

Posted: Mon Jun 16, 2014 10:15 pm
by tpetzke
In iCE I load the book into the transposition table when a ucinewgame command is received. This works pretty well. Also if iCE is out of book and a transposition happens back into a book position it is picked up.

As long as iCE is in the book no real search is done and the entries in the table are maintained as there is nothing that could overwrite them. When later the real entries hit the table the book entries will then fade away.

... until the next ucinewgame command is received

Re: UCI, ownbooks, and a potential problem

Posted: Tue Jun 17, 2014 5:07 am
by Ferdy
tpetzke wrote:In iCE I load the book into the transposition table when a ucinewgame command is received. This works pretty well. Also if iCE is out of book and a transposition happens back into a book position it is picked up.

As long as iCE is in the book no real search is done and the entries in the table are maintained as there is nothing that could overwrite them. When later the real entries hit the table the book entries will then fade away.

... until the next ucinewgame command is received
While working on uci conversion, found out that Fritz 13 does not send ucinewgame. I don't know about the latest Fritz 14 though.

Re: UCI, ownbooks, and a potential problem

Posted: Tue Jun 17, 2014 7:56 am
by tpetzke
Yes. Geert Maeckelbergh in his country tournament told me that iCE is not using its book in the Fritz GUI. After I told him that iCE expects a ucinewgame to load the book he was able to fix that.

I think he added a custom option that the GUI sends a command to the engine and let this command be "ucinewgame".

I found this in the Immortal Chess forum
http://immortalchess.net/forum/showthre ... 0&langid=1
The origin of the problem is that, contrary to the UCI protocol specification, the Fritz GUI never sends a “ucinewgame” command when a new game begins, it just sends a “Clear Hash” instruction. For Houdini it is as if the complete match is a single game in which it occasionally switches sides. This messes up some of the time management, especially in ponder mode.

Note that any Houdini match results obtained in the Fritz GUI could have been affected by this issue. This applies to every single Houdini version that has been released so far.

Re: UCI, ownbooks, and a potential problem

Posted: Tue Jun 17, 2014 8:48 am
by Ferdy
I have written an email to CB requesting to support ucinewgame in their interface, also included to look into the issue on CB12 cloud analysis feature.

Re: UCI, ownbooks, and a potential problem

Posted: Tue Jun 17, 2014 3:50 pm
by jdart
This is one of the many reasons I don't like UCI. I don't have your book issue but UCI screwed up some of my learning code for similar reasons.

However, I really don't think checking for book moves "always" should be too inefficient.

I used to use memory-mapped files to access the book, which avoided re-loading disk pages, but now I just access the book on disk (it is basically a persistent hashtable) and that is fast enough. The way it is stored, all moves for a given position are in the same disk block.

--Jon