On 3/7/07, Paul Pogonyshev <[EMAIL PROTECTED]> wrote:
Gunnar Farneback wrote:
> Example 3: Like example 2, but abort command comes too late.
...
Maybe it should then read
?2 not in progress
It also makes sense to forbid an async_genmove (or simple genmove for
that matter) until the previous genmove/async_genmove has finished.
The engine should just fail with a predefined error string; I think
it is really cumbersome for the engine to try synchronization here and
serves little purpose.
Paul
Although Gunnar specifies async_genmove to return zero or one
responses, I believe that it may be more useful to allow it to return
any number. This allows the possibility for the controller to update
a "current best" display while it has still not accepted a single
definitive response. From the controller's point of view, the command
could still be in effect until a response to the abort_async_genmove
has been received. (although perhaps end_async_genmove would be more
appropriate name in this case.) I don't feel strongly either way on
this, but I thought that I should mention the possibility.
Does it also make sense to forbid commands that modify the engine's
state? If the board state changes before async_genmove generates a
response, to which board does the response apply?
Weston
_______________________________________________
computer-go mailing list
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/
