Author: Edward Screven
Date: 12:34:51 11/28/00
Go up one level in this thread
i think your protocol has a lot to recommend it. in particular i like having search separated from play, having clock information made available as part of the "go" command, and having engine specific options exposed through the GUI. but i have one question and one objection. question: why is "position" a separate command, and not an argument to "go". as far as i can tell, there's nothing an engine is supposed to do with a position other than search it, and the engine isn't supposed to search until it receives a "go". so why not take the stateless nature of the protocol further and make the position information part of "go"? objection: i strongly dislike the way pondering is supposed to work. i don't mind having a command that says "start pondering now", but the assumptions built into the protocol - that it is always a search based on an opponent move guess computed as a side affect of a previous search - are too limiting. what about the first move out of book? what if no guess move is immediately available because the previous search ended in a fail-high? in these cases my engine does a short search to guess at the opponent move, but it doesn't do that until it is time to start pondering. i don't see how to fit this into the uci protocol. if you did make the current position an argument to go, then you could easily support pondering in a more general way too. you could just say that "go ponder <position_1>" informs the engine that the opponent is on move from the described position, and the engine is free to use the CPU any way it wishes. if the engine next receives "go <position_2>" (no ponder flag), and <position_2> was reached from <position_1> by the engine's notion of a ponder move, then the engine could simply continue the current search. - edward
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.