Marco Scheurer wrote:
makes me wonder if other optional commands would not be better: start_thinking stop_thinking best_move
I agree: once we allow "asynchronous" processing of commands, this wil be as easy as the abort-feature. It could have been the interface to the engine. At the moment, it is not. To allow simple implementations to talk GTP, we need the protocol to be "one line at a time" and blocking. The "abort" feature is an exception. It is optional, but we still should try to agree on it's semantics.
BTW it is not forbidden to think in the opponebt's time. As long as it responds to the GTP dialog, the program may do anything it chooses to, given it maintains the necessary board state between moves/commands.
Implementing start_thinking/stop_thinking/best_move in terms of genmove, abort, report_post_abortum_move is left as an exercise to the reader ... (hint: maybe built-in aliases/macro's would help :-) AvK
On Monday, November 4, 2002, at 02:48 PM, A van Kessel wrote:
Implementing start_thinking/stop_thinking/best_move in terms of genmove, abort, report_post_abortum_move is left as an exercise to the reader ... (hint: maybe built-in aliases/macro's would help :-)
I know it is not fundamentally different, since I wrote:
It's not that different from genmove, abort, report_post_abortum_move, but I think the semantics is clearer.
However, if we decide that abort is useful only for genmove, then implementing stop_thinking/start_thinking instead can make it much easier: start_thinking, unlike the current genmove, does not have to block until a move is found, and can return it's response immediatly.
Marco Scheurer Sen:te, Lausanne, Switzerland http://www.sente.ch