[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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.