[computer-go] GTPv3
Don Dailey
drd at mit.edu
Mon Mar 5 08:18:00 PST 2007
I don't think it should work that way either. I was just suggesting
that it's
possible to do everything required without any anynchronous changes to
GTP,
but I certainly don't recommend this method.
- Don
On Mon, 2007-03-05 at 10:07 -0600, Nick Apperson wrote:
> I do not think that genmove should work that way. It makes more sense
> for you to have a genmove command and an async_endsearch command or
> somethinglike that. The program is allowed to keep searching as long
> as it doesn't receive that command. genmove doesn't need to have an
> async mode really. You could have async_genmove return the programs
> best guess at the moment, but it wouldn't be considered final until
> genmove returns.
>
> On 3/5/07, Don Dailey <drd at mit.edu> wrote:
> Yes, it's possible to do all of this with GTP as is and
> the addition of a few commands that stay blocking, nothing
> but pure GTP extensions and no asyncronous communication.
>
> I already mentioned this as polling. Instead of genmove,
> you send inc_genmove, which is designed to return very
> quickly and does only a partial search. The controller
> continues to send a long series of consecutive inc_genmove
> until the engine makes a move. And the controller can
> stop sending inc_genmove if it wants to abort. In fact
> it doesn't even need to tell the engine to abort.
>
> I think this is really rather ugly however. You are
> adding a LOT of extra communication and things will
> be sluggish if you don't send these at least 3 or 4
> times per second.
>
> - Don
>
>
> On Mon, 2007-03-05 at 09:50 -0300, Eduardo Sabbatella wrote:
> > Actually gen_move blocks because every engine uses the
> > same thread for both the engine and the comm link.
> >
> > you can have a couple of sub commands for get_move
> > like: get_complete_percent, get_current_best_move,
> > chat, etc.
> >
> > If the engine doesn't support "realtime" gtp, they
> > will be answer after the gen_move response. one at a
> > time.
> >
> > I don't know, perhaps I'm pushing too much the gtp
> > protocol... I don't think so, but perhaps....
> >
> >
> > --- Nick Apperson <apperson at gmail.com> escribió:
> >
> > > I think you are mostly correct. But, the problem is
> > > that GTP was designed
> > > to block on the genmove command. This is a problem
> > > because genmove is
> > > usually not quick to return. Therefore, there is no
> > > way with the current
> > > scheme to be able to issue commands while an engine
> > > is thinking. It would
> > > require a redesign perhaps using polling instead if
> > > GTP is to remain
> > > blocking.
> > >
> > > On 3/5/07, Eduardo Sabbatella
> > > <eduardo_sabbatella at yahoo.com.ar> wrote:
> > > >
> > > > Don,
> > > >
> > > > Perhaps I'm completelly wrong, but pondering is up
> > > to
> > > > the engine, the controller, nobody outside the
> > > engine
> > > > will know / have to know if the engine is
> > > pondering.
> > > >
> > > > I think in the threads we are confusing the fact
> > > that
> > > > the engine and the gtp line controller could be in
> > > two
> > > > different process threads.
> > > >
> > > > GTP line could 'answer' questions like: cpu usage,
> > > > current best move, at realtime comunicating with
> > > the
> > > > engine thread. Also, the engine could publish
> > > stats
> > > > info sending that to the gtp line thread.
> > > >
> > > > That is not related to the protocol at all. Adding
> > > a
> > > > couple of new commands will be enough. (and
> > > processing
> > > > them on realtime from another thread).
> > > >
> > > > If the engine doesnt supports 'abort'
> > > > the controller after a couple of seconds will
> > > receive
> > > > 'move blah blah' 'command don't understood'.
> > > >
> > > >
> > > >
> > > > --- Don Dailey <drd at mit.edu> escribió:
> > > >
> > > > > 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
> > >
> > === message truncated ===>
> > _______________________________________________
> > > computer-go mailing list
> > > computer-go at computer-go.org
> > >
> > http://www.computer-go.org/mailman/listinfo/computer-go/
> >
> >
> >
> >
> >
> >
> >
> > __________________________________________________
> > Preguntá. Respondé. Descubrí.
> > Todo lo que querías saber, y lo que ni imaginabas,
> > está en Yahoo! Respuestas (Beta).
> > ¡Probalo ya!
> > http://www.yahoo.com.ar/respuestas
> >
> > _______________________________________________
> > computer-go mailing list
> > computer-go at computer-go.org
> > http://www.computer-go.org/mailman/listinfo/computer-go/
>
> _______________________________________________
> computer-go mailing list
> computer-go at computer-go.org
> http://www.computer-go.org/mailman/listinfo/computer-go/
>
More information about the computer-go
mailing list