Author: Ingo Bauer
Date: 00:39:39 03/10/05
Go up one level in this thread
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! :-)
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.