RE: [computer-go] SGF parsers

["Jim O'Flaherty, Jr." <jim_oflaherty_jr@xxxxxxxxx>]

Mark,

I agree with you.  There seems to be a plenty of focus on local optimizations.  I like your
staying focused on optimizing constraint(s)/bottlenecks only.  It is way better use of the most
scarce resource, your time.

A couple points:

A) XML is human readable which generates more edit options
B) XML is computer languate neutral - very valuable given all the different implementaion types
C) XML is very flexible in making additions, given one designs the structure flxexibly
D) XML is just one way to represent information, if one needs a higher priority on efficiency,
there are many options:
  1) Produce a binary representation that is hand-bit-encoded to maximize storage space. Consider
this to be an "interim" formate for cache efficiency purposes only.  Always originate this cache
from the XML data store any time the XML data store is modified.  There are plenty of efficiency
opportunities here.
  2) Input/Output the XML to a compressed (ex: .zip) file.
  3) Produce a binary representation that is optimized for memory layout.
  4) etc.
E) Consider you can have more than one XML layout, and can select them with an attribute at the
base tag of the document:
  1) You can lay it out such that every successor move is a child of the move preceeding it.  This
is where you have the hundreds of close tags at the end.  So what?  Use alternative
representations in memory and even on disk if you have other needs.
  2) You can lay it out such that there is a primary path of moves through the file (ex: the main
game path) and then have variations come off the primary path.  This will generate less of the
nesting I think you express concern about.  However, it is not as "pure" as 1 from a data
structure perspective.
  3) Use an existing XML format.  The guy that wrote Jago (which is FOSS/GPLed) has one.  Go here
to see his stuff: http://www.rene-grothmann.de/jago/

As to converting SGF to XML, that is a one off command line tool (with a library interface to use
with automation code).  If I had the time, I would whip something off as I am definitely going to
be using XML as my external data storage mechanism.  And if I do get some time to do that, I would
likely look at lifting the code out of Jago and getting that to work as a command line/library
interface as opposed to rewriting it, regardless of how much more "efficient" I could make it.

SGF is based on very old UNIX style efficiency.  I don't have any reason to need that at present
time.  In fact, it is more fragile in nature than I am comfortable with.  XML is "inefficient",
but really only in one or two ways.  However, the other values seem to more than make up for the
inefficiency.

My time is way more important than trying to eek out performance on things that are not part of
the constraint, i.e. slowing down my system.  My time is best spent designing, implementing and
ONLY THEN optimizing whatever the constraint is.  I ASSUME I have plenty of CPU and plenty of
memory, and will buy more.  Optimizing to fit in 64K is long past for me.  I am totally fine with
multi-megabyte exes that take MB to function.


Jim O'Flaherty


--- Mark Boon <tesuji@xxxxxxxxxxxxxxxxx> wrote:

> 
> 
> > -----Original Message-----
> > From: computer-go-bounces@xxxxxxxxxxxxxxxxx
> > [mailto:computer-go-bounces@xxxxxxxxxxxxxxxxx]On Behalf Of Paul Pogonyshev
> > Sent: Tuesday, December 14, 2004 14:03
> > To: tesujisoftware@xxxxxxxxxxxxxxxxx; computer-go
> > Subject: Re: [computer-go] SGF parsers
> >
> >
> > Mark Boon wrote:
> > > I just realise now how impractical that would be in relation to
> > XML though.
> > > If the next move is a child of the current move, then the XML
> > is going to
> > > have the closing tag of this move after the closing tag of the
> > next move.
> > > So a 300 move sequence would end in 300 </move> closing tags.
> > So I'll have
> > > to think of something else...
> >
> > I don't see how this is particularly impractical.  Basically, using XML is
> > impractical on its own unless you either want to use an existing
> > parser (not
> > critical since there are SGF parsers available) or want to make
> > data available
> > in generally-understood format (personally, I don't see much
> > advantage of XML
> > here, I can't think of a useful task that a general XML program
> > can perform
> > with go game records.)  300 closing tags is just a side-effect of
> > using XML.
> >
> 
> Maybe I'm being a bit of a purist here. First of all I think it's
> impractical because it destroys human readability. Second, I think the
> children of a move-node should be data related to this node, like comments
> and board-marks. Variations will need to be indicated differently then, as
> it means the tree-structure of the DOM-tree cannot easily be used to store
> variations. You'll probably need something like a <variation> tag to
> indicate a variation on the previous move or so.
> 
> You say SGF parser are available. So why is it then that just about everyone
> on this list seems to have built his own?
> 
> As to performance and memory considerations: since SGF isn't going to be
> used while playing or other computer-Go related tasks, I don't care much. If
> parsing a 100Mb file is going to take an hour, then that's fine too as I
> don't see why you'd need to do it more than once ever, after which you stuff
> the data in a database. I don't consider SGF as a proper data-storage
> medium, more as a data-transfer format.
> 
> _______________________________________________
> computer-go mailing list
> computer-go@xxxxxxxxxxxxxxxxx
> http://www.computer-go.org/mailman/listinfo/computer-go/
> 

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