Re: [gtp] Re: computer-go: gnugoclient 2.0

[jeffg <jeffg@xxxxxxxxxxxxxxx>]

You might look at OpenGo which is under a new license ( you can see it on a test
instance of the site: http://www.inventivity.com/OpenGo/x

It is made to interface to different go engines.... as such, it has a protocol
which we've connected to GMP (and gnugo), and to some other programs like wally.

It is implemented by subclassing a C++ class called "player" and a class called
"referee" which mediates between two players.

One would like to be able to parameterize an engine, in terms of its
capabilities, so that one could play correct and reasonable games between them.
In terms of machine learning, there might be a whole slew of parameters of
interest.   The set you've got is pretty much what we've got too, including
undo.

jeff

Phil wrote:

> I agree there should be an "undo", or as I call it, a "takeback" command. At
> worse, the GTP (server) can respond with an "not implemented" error message.
>
> Also, we need a way to determine if a command is implemented. I was thinking
> that a command prefixed by a question mark, like "[id] ?[command]" would
> return either a successful response "=" if implemented, otherwise a "?" if
> not.
>
> I also think it would be valuable to define a way to pass back error and
> status codes, and not just a success or failure and an results or error
> messages. We could implement this as an optional field; a number before the
> result or error message, prefixed with a colon. I was thinking the the
> response format could be: "=[id] [status code]: [result]" or "?[id] [error
> code]: [error message]". I have not put too much thought into this, so
> feedback would be helpful.
>
> Phil
>
> ----- Original Message -----
> From: "Heikki Levanto" <heikki@xxxxxxxxxxxxxxxxx>
> To: <computer-go@xxxxxxxxxxxxxxxxx>
> Sent: Friday, August 03, 2001 10:18 PM
> Subject: Re: computer-go: gnugoclient 2.0
>
> > On Fri, Aug 03, 2001 at 05:03:14PM -0400, Don Dailey wrote:
> > > Whether a program has "undo"  or not isn't really  a big deal.  But in
> > > my  opinion  the  real  issue  is  getting   this very  basic  feature
> > > documented right away.
> >
> > A standard is complete not when there is nothing to add, but when there is
> > nothing to remove!
> >
> > I do agree that it is important to specify the behaviour of the undo
> command
> > now, to avoid different implementations. But I also agree that the command
> > is of limited use, probably only in human-computer games, which is but one
> > use for the protocol. Thus I do not agree that "undo" must belong to the
> > minimal set of commands all programs must implement.
> >
> > Therefore I propose to add another set of commands, that are recommended
> but
> > not required. Currently this command would contain the undo command only,
> > but I can imagine we might want to add stuff later, for example time
> > controls, ruleset details, and what not.
> >
> >
> > Other recommendations for the standard. Discuss and discard at will.
> >   - Three possible error responses:
> >       - Unknown command
> >       - Not implemented  (like undo above)
> >       - Parameter error  (like playing outside the board)
> >   - Naming convention for commands that are specific for debugging one
> >     program, for example prefix by program name or abbreviation
> >     (gg_owl_defend). Should we keep an "official" list of those prefixes?
> >
> >
> > Heikki
> >   leaving for off-line vacation for a week
> >
> > --
> > Heikki Levanto  LSD - Levanto Software Development   <heikki@xxxxxxxxxxxxxxxxx>
> >
>
> _______________________________________________
> gtp mailing list
> gtp@xxxxxxxxxxxxxxxxx
> http://lists.lysator.liu.se/mailman/listinfo/gtp