Author: Robert Hyatt
Date: 08:45:29 03/10/05
Go up one level in this thread
On March 10, 2005 at 03:39:39, Ingo Bauer wrote: >Hello > >>-uci: >> >>engine can't decide when to ponder, what to ponder, how much time to use, etc. >>The GUI is an "interface". Not a "director". UCI misses that point. Of course >>the GUI should not be handling the opening book, book learning, endgame >>tablebase probes when the starting position is a table position (for example, >>crafty's "swindle mode"). > >Please have a look at the UCI specification. The points you are mentioning here >is not mandatory to use, in fact most engines dont use it. > >Here are the relevant points regarding your critics: > >1. In UCI you can ponder whatever you want > >* ponder >... The engine can do what it wants to do, but after a "ponderhit" command it >should execute the suggested move to ponder on. This means that the ponder move >sent by the GUI can be interpreted as a recommendation about which move to >ponder. However, if the engine decides to ponder on a different move, it should >not display any mainlines as they are likely to be misinterpreted by the GUI >because the GUI expects the engine to ponder on the suggested move. > >Remark: If the GUI is implemented well, sending ponder informations with the >"wrong" pondermove are no problem. > > >2. In UCI you can use 100% of the time you have left! > > * wtime <x> > white has x msec left on the clock > * btime <x> > black has x msec left on the clock > * winc <x> > white increment per move in mseconds if x > 0 > * binc <x> > black increment per move in mseconds if x > 0 > >You can use of course all of "x" if you want! > > >3. In UCI you can handle your own book! > >option * <id> = OwnBook, type checkthis means that the engine has its own book >which is accessed by the engine itself. If this is set, the engine takes care of >the opening book and the GUI will never execute a move out of its book for the >engine. If this is set to false by the GUI, the engine should not access its own >book. > > >4. In UCI it is on you to implement a book learning in your engine! > >* ucinewgame >this is sent to the engine when the next search (started with "position" and >"go") will be from a different game. This can be a new game the engine should >play or a new game it should analyse but also the next position from a testsuite >with positions only. If the GUI hasn't sent a "ucinewgame" before the first >"position" command, the engine shouldn't expect any further ucinewgame commands >as the GUI is probably not supporting the ucinewgame command. So the engine >should not rely on this command even though all new GUIs should support it. As >the engine's reaction to "ucinewgame" can take some time the GUI should always >send "isready" after "ucinewgame" to wait for the engine to finish its >operation. > > >5. In UCI the engine is responsible for tablebases and you can use any "swindle" >mode if you like. > >The UCI-engine Shredder 8/9 is doing something similar in a tablebase position >as your craftys swindle mode. In the Shredder classic GUI you can switch of >tablebase access for the GUI. The Chessbase GUI is a bit tricky but it is >possible to restrict the tbs access as well. In short there is nothing in the >UCI protocoll that forces the tbs acces of a GUI! > >Points 1 and 4 where changed a bit in 2004 because of some criticism. So you >WHERE partly right. > >Bye >Ingo > >PS: If these are you points I now hope for a UCI Crafty again! :-) Don't hold your breath. The "ponder changes" are serious modifications to crafty. It always ponders, it doesn't wait for the GUI to tell it to "ponder". I don't see how "ponderhit" can possibly work if the engine doesn't ponder the move the GUI told it to ponder. If I am pondering something different, then "ponderhit" is meaningless and wrong...
This page took 0 seconds to execute
Last modified: Thu, 15 Apr 21 08:11:13 -0700
Current Computer Chess Club Forums at Talkchess. This site by Sean Mintz.