That looks like a good web-site, thanks for the pointer. It will surely come
in handy at some point in time. The XML parser I've come across so far have
been flaky at best.
I already have an XML to DOM parser that works. But I still need to convert
the DOM into actual objects, which is where the main work comes in.
The XML parser that I used before (from IBM I think) forced me to include a
library of 500Kb. A quick glance at the Xerces library tells me it's of
similar size. Maybe not outrageous for todays standards, but I wrote a very
simple one that only takes a few kilobytes. It's not a full fledged parser,
but it does the job for the simple stuff I use. And the API is the same as
the IBM one so I can plug whichever I feel like using.
A GoML discussion would definitely be a good idea. But I think most
programmers use the SGF format and they might be difficult to persuade to
use anything else. In the past I've always used the Ishi-Press format but
I'm not sure anyone use it nowadays.
> -----Original Message-----
> From: owner-computer-go@xxxxxxxxxxxxxxxxx
> [mailto:owner-computer-go@xxxxxxxxxxxxxxxxx]On Behalf Of Jed
> Anderson/MIN/OTI
> Sent: Thursday, May 17, 2001 9:09 PM
> To: computer-go@xxxxxxxxxxxxxxxxx
> Subject: RE: computer-go: Sharing Go modules + XML
>
>
>
> I have had a lot of luck using the apache xerces parser and XML. It makes
> parsing the
> XML much easier (http://xml.apache.org/xerces-j/).
>
> This forum appears to be the perfect place for a GoML discussion
> is anybody
> else
> interested in creating such a language?
>
> jkca
>
>
>
>
> "Mark Boon"
>
> <tesuji@xxxxxxxxxxxxxxxxx> To:
> <computer-go@xxxxxxxxxxxxxxxxx>
> Sent by: cc:
>
> owner-computer-go@lists.u Subject:
> RE: computer-go: Sharing Go modules + XML
> oregon.edu
>
>
>
>
>
> 05/17/2001 01:54 PM
>
> Please respond to
>
> computer-go
>
>
>
>
>
>
>
>
> Below are some comments on Davids post. As someone else commented however,
> the discussion has gone a bit astray. I think it's interesting to discuss
> implementation details to see what other people have come up with, but I'm
> actually more interested in the original question of how to set up
> communication between separate modules.
>
> My gut feeling says that sooner or later people will want the
> interfaces to
> the modules to support 2-dimensional coordinates. For the moment however
> I've decided to (mainly) stick to the 1-dimensional approach a little
> longer, especially since quite a few people use exactly the same method.
> Instead I made some utility methods to do the conversion back and
> forth for
> those who wish to interface it with a module that uses 2-dimensional
> coordinates as follows:
>
> int xy = toXY(x,y);
> int x = getX(xy);
> int y = getY(xy);
>
> That still leaves the problem when exchanging arrays with board-data, but
> I'm brooding over some possible elegant solution that can support both
> ways.
> I had hoped to see some feedback from people who work on the GNU team to
> see
> how they have organised these issues, but unfortunately no response from
> any
> of them yet.
>
> Another issue that starts to come up is reading and writing data to file.
> At
> the moment, for the few things I write to file I use the automatic
> serialization that Java offers. It's by far the easiest way to
> quickly read
> and write complex objects. But obviously that's not a very practical
> solution for the long term, especially when sharing modules. I've grown
> into
> the habit of always adding a toXML() method to my classes that return the
> data of the object in XML. Writing code that parses the XML and
> reconstructs
> the original object from it is always some work, but I think it's by far
> the
> most flexible solution. Which leads to the problem of course of defining
> standard XML for commonly stored data. So I'm looking for input
> on standard
> XML for game-records, diagrams, joseki, patterns, etc, etc,
> etc.... Anyone?
>
> Mark
>
> > -----Original Message-----
> > From: owner-computer-go@xxxxxxxxxxxxxxxxx
> > [mailto:owner-computer-go@xxxxxxxxxxxxxxxxx]On Behalf Of David Fotland
> > Sent: Thursday, May 17, 2001 6:17 PM
> > To: computer-go@xxxxxxxxxxxxxxxxx
> > Subject: RE: computer-go: Sharing Go modules
> >
> >
> > At 12:56 PM 5/17/2001 +0200, you wrote:
> >
> > >I also have an array with the distance to the edge of each point
> > in it. But
> > >my program has a lot of code that does something like:
> > >
> > > if (board[left(xy)] == board[xy])
> > > doSomething(left(xy));
> >
> > One more follow-up. I checked, and my code has 825 uses of the edge[]
> > array, and
> > 268 of them compare the value to 1. But I imagine in your case
> > that there are
> > times when you check if(left(xy) == OFF_EDGE).
> >
> > What does your code look like for iterating the neighbors of a point? I
> > imagine
> > something like:
> >
> > int ofs[4] = { -1, 1, 20, -20 };
> >
> > int xy; /* center point */
> > int nbr; /* adjacent point */
> > for(int i = 0; i < 4; ++i){
> > nbr = xy + ofs[i];
>
> Indeed this is what I do.
> However the test on OFF_EDGE doesn't happen very often.
> It's more usual to have something like:
>
> value = board[nbr];
> if (value==myColor)
> {
> /*do something */
> }
> else if (value==otherColor)
> {
> /* do something else */
> }
>
> So the edge gets avoided automatically. But it does have to retrieve
> board[nbr] and compare it even when it's off the board. I'm sure that
> occasionally I will check for the edge, but in the modules I have
> converted
> to Java so far I couldn't find a single one.
>
> > if(board[nbr] == OFF_EDGE)continue;
> > /* do something */
> > }
> >
> > I have a larger offset array, with 52 entries, and an array with 361
> > entries that gives
> > the starting offset index for each point, and an array of 52
> entries that
> > gives the ending index (+1)
> > for each starting index, so my loop is:
> >
> > int ldtmp;
> > int i = fdir[xy];
> > for(ldtmp = ldir[i]; i < ldtmp; ++i){ /* look at neighbors */
> > nbr = xy + ofs[i];
> > /* do something */
> > }
> >
> > This avoids the test for off-board inside the loop at the cost of
> > two array
> > lookups outside the loop, and is
> > probably faster.
> >
>
> This is an interesting idea. So you visit less neighbours at the edge. It
> seems to me this is faster at the edge, but usually slower in the center
> than my approach. Hard to say which is more efficient overall, but
> definitely a good solution if you want to do away with storing edges.
>
>
>
>
>
>
>