On Mon, May 16, 2011 at 11:11 AM, Petr Baudis <[email protected]> wrote:
> On Mon, May 16, 2011 at 03:39:08PM +0100, Willemien wrote:
> > There is allready GTP see
> > - http://senseis.xmp.net/?GoTextProtocol
> > - http://www.lysator.liu.se/~gunnar/gtp/
> >
> > Maybe it is best to find something that extents the gtp protocol.
> > (but keeping most of it)
>
> I think basing this on GTP would be a mistake. It is synchronous in
> nature and is not as easy to parse as something JSONish.
GTP was designed to be easy to parse and I have to challenge your statement.
JSON is easy to parse, but much more difficult in comparison.
You have a valid point with the fact that it's synchronous, however that
has its advantages too, specifically the fact that you can pipe a command
file directly to the engine.
One of the goals of this type of protocol is that it has to be dead simple
to implement. Getting all enthused about wonderful features and
enhancements is going to make this a dead protocol and unappealing. The
point for programmers is that they should be able to focus on the engine and
not the protocol or interface. Most go programmers do not want to build
user interfaces or be burdened with a complex protocol.
Also, a lot of programmer do not want to include external libraries in their
engine code. In computer chess some programs such as stockfish have NO
external dependencies and there is a lot of benefits of that. My point is
that I don't want to build a JSON parser nor do I want to make an external
one another dependency. I am anal that way but so are a lot of other games
programmers. I don't mind parsing tokens delimited by spaces - that's
easy.
> Also, it makes
> assumptions about one side being a go robot.
That is not an assumption, it's what it's designed for. That is like
saying your vehicle is designed with the assumption that a human being is
going to drive it. Yes of course it is, that's who it is designed for.
Don
> Of course, it makes a lot
> of sense to reuse the concepts behind but I think the commonalities
> won't amount to too much in the end.
>
> > A questions where stands JSON for?
>
> Google it out. ;-) It's a generic protocol syntax that is trivial to
> parse on the client side.
>
> > A suggestion, lets start a page on sensei's about it
>
> I think this thread stems from a previous conversation between me and
> Jonathan about making information about progressive reading of a program
> more easy to parse by something external that visualizes them on board
> (and incidentally, that something will be web-based). My proposed
> example of how information "packet" that could be easily generated by
> some MCTS Go Program (i.e. Pachi) would look like:
>
> { "playouts": 10000, "best": { "move": "F6", "value": 0.580823 },
> "can": [ { "move": "F6", "value": 0.581 }, { "move": "F7", "value": 0.553 },
> { "move": "F8", "value": 0.614 }, { "move": "G7", "value": 0.528 } ], "seq":
> [ "F6", "C6", "C7", "D7" ], "owner_stats": [ { "move": "A1", "value": 0.31
> }, ... ], "laddered_groups": [ "C3", "G5", ... ], ... }
>
> Originally I assumed this would just go by a different channel than all
> the genmoves, but maybe Jonathan wants to conceptually shift this
> upwards.
>
> --
> Petr "Pasky" Baudis
> UNIX is user friendly, it's just picky about who its friends are.
> _______________________________________________
> Computer-go mailing list
> [email protected]
> http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
>
_______________________________________________
Computer-go mailing list
[email protected]
http://dvandva.org/cgi-bin/mailman/listinfo/computer-go
