Re: [computer-go] SGF parsers

[Gunnar Farnebäck <gunnar@xxxxxxxxxxxxxx>]

Mark wrote:
> Thanks Gunnar for the code example. My own parser is actually not so far off
> from what you have.

Not very surprising. Given the file format specification there are
probably only a few natural solutions for parsing it.

> You've swept a few things under the carpet though. The interpretation of the
> node-data is in the add_property,

That's intentional. Actually my add_property() method only stores the
properties as raw name-value pairs, where the value is either a string
or a list of strings. But this is where your own data structure
preferences start coming into play.

> which is maybe the biggest part of it all if you want to support all
> the examples in the example file above.

Maybe if you're writing an sgf editor. If we're talking about loading
positions into a go program for use in testing, only a few properties
matter at all.

> Also I see you don't do anything for unnamed properties, I suppose
> you assume add_property takes care of that as well.

Do you mean repeated properties like in AB[pd][dp]? That is translated
into two calls add_property("AB", "pd") and add_property("AB", "dp").

> Technically your routine parses an SGF file, but it doesn't interpret it,
> which is where I still see some work to come in. For example: in the
> DOM-tree I'd want the move-node to be parent of the comment-node that
> belongs to it. Same for markup. But in the SGF file they can appear all
> mixed up.

Sounds like overengineering to me. I'm quite happy to have the
properties internally stored like they are in the sgf file. When I
traverse the tree I use a get_move() method to obtain the move and
get_property("C") to get the corresponding comment. (The latter can of
course be abstracted to a get_comment() method if preferred.)

/Gunnar
_______________________________________________
computer-go mailing list
computer-go@xxxxxxxxxxxxxxxxx
http://www.computer-go.org/mailman/listinfo/computer-go/