I like GTP and I champion it. However, there are some weaknesses
and they are not easily fixed without a major paridigm change.
1. There is no way to STOP a program from thinking. This is
needed for a high quality user interface.
2. There is no natuaral way to get useful information from the
go program, such as it's thinking process. A quality user
interface should be able to show the user the thinking process
of the program, when it changes it's mind about the move choice,
it's current opinion of the score, etc.
This can be implemented with "polling" by adding a GTP command
to request information from the engine every second or two, but
this feels like a hack.
Thinking on the opponents time (pondering) is supported naturally by
the UCI protocol. Actually, the engine doesn't need to know much
about this, the controller simply tells the engine to start thinking
on a given move and so the engine doesn't even know it's thinking on
the opponents time. However, the engine does communicate to the
controller what the ponder move is.
This could ALMOST be implemented directly in GTP, except for the fact
that you cannot stop the engine from searching once it begins. If
I'm pondering, but the opponent doesn't play the ponder move, there
is not way in GTP to say, STOP searching NOW because the move is not
relevant!
So GTP could not easily be used to build a high quality user interface,
say
for a commercial program. At least not one that had the better
features,
even given that you can extend the command set with additional commands.
It COULD be done, just not easily. You would have to do it all with
polling. You could even implement stop search by having a GTP command
to do searching in tiny time slices. The contoller would send
commands such as "continue_search" which must return in a fraction of
second, possibly with a move. This would be truly awkward but
possible.
- Don
On Thu, 2007-03-01 at 17:10 -0700, Markus Enzenberger wrote:
> On Thu March 1 2007 05:22, Łukasz Lew wrote:
> > The most important thing is controller - engine architecture.
> > There are situations that engine would like to have the control. For
>
> these requests come up once in a while, but IMO the clear separation between
> who is the controller and the engine is a big advantage of GTP. It makes both
> the implementation of engines and controllers much easier.
>
> Can you do simple, single-threaded controller scripts with UCI? Is it used
> for
> as many use cases as GTP is, ranging from regression testing to any kind of
> automated experiments with Go engines?
>
> The Go server protocols are designed for humans and asynchronous sending of
> messages between them at any time, but does it make sense for a computer
> engine to allow it to start chatting, whenever it feels like it?
>
> I think that GTP should not be extended in a way that makes the
> implementation
> of engines or controllers more complicated.
>
> > In gogui this is solved by using stderr to send those commands, but:
> > - stderr is not network transparent
>
> Remi Coulom convinced me that it is more convenient for the engine to write
> to
> standard error and he was right. Typically the GTP interface is only one of
> several interfaces to lower level Go engine code and you don't want to make
> lower level code aware of this.
>
> One idea I had in mind to address this was to allow the engine to send
> comment
> lines before the actual response. Then you could tunnel the standard error
> output through a network connection in these comment lines, maybe starting
> with a special keyword.
>
> It would need only a minor modification to existing controllers to ignore all
> text before the response. Alternatively, one could extend the tools GtpServer
> and NetGtp in the GoGui package to internally transmit standard error text in
> such a way, that would be transparent for the engine and controller on
> different hosts.
>
> > 6. Position setup. I had conversation with Marcus about setup in GoGui.
> > And we concluded that there should be a separate command for that.
>
> The coming version 1.0 of GoGui will support a setup command. It is a
> simplified version of a suggestion I made a while ago to the GTP list and
> uses a syntax like:
>
> gogui-setup b A1 b B2 w C3
>
> Originally I had an undoable setup command in mind to incrementally follow
> setup stones in SGF trees, but it is much easier for engine programmers to
> handle only full position setup on empty boards, so GoGui will follow the SGF
> properties incrementally and translate setup nodes into clear_board /
> gogui-setup sequences.
>
> - Markus
> _______________________________________________
> computer-go mailing list
> [email protected]
> http://www.computer-go.org/mailman/listinfo/computer-go/
_______________________________________________
computer-go mailing list
[email protected]
http://www.computer-go.org/mailman/listinfo/computer-go/
