[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: computer-go: Sharing Go modules


Actually, dealing with the edge of the board does put many special cases in the code, so I
often have code like if(edge[p] > 1 && board[p-1] == board[p]), so your approach is more efficient.
I didn't use it originally, because of memory limitations. All data had to fit in about 100 KB for DOS.
And once I had a lot of code written, it was way too hard to go back and change to your scheme.

For examining the points near a point, I have a set of offset indexes that depend on the source point,
so there is little overhead when iterating over the 4 (or sometimes 3 or 2) adjacent points. But it does
make my code a little more complex.

If I was starting over, I would do it your way.

Also, my board array doesn't store colors. It just stores unit numbers. The color is a feature of a
unit. I like Handtalk's scheme of storing unit numbers on the board, and forcing black unit numbers to be even and
white unit numbers to be odd. So you can check the color of a unit by just a bit-masking operation.

As for board points, it is not so bad. When I am debugging, I always have a second copy of the position
showing in another instance, so I can see what is on the board while I look at the code. If I count
down the main diagonal of the board, the index increments by 20, so I can quickly find the index of
any point.

I wanted to use positive numbers for colors so I can use the colors directly as indexes to arrays.
I picked 0 for black because black plays first.

David

At 12:56 PM 5/17/2001 +0200, you wrote:
The color-coding scheme seems to be different for everyone. Before I used 1
for Black and -1 for White so that I do otherColor = -color. However with
any of these schemes you get problems when your code starts to rely on the
particular coding scheme, so I've decided to make constant definitions for
Black, White, Empty etc... and a function (macro in C) invertColor(color)
that does the inversion. Other than that I don't think about it and the
actual values are free to change.

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));

and I don't want to have to check all the time for the edge to make sure it
doesn't wrap to the other side. Or worse, go out of bounds. However it
depends a lot on how your program is organised, so for the ManyFaces program
it may be more efficient not to have any boundaries.

And I wouldn't be surprised if after all these years David knows by heart of
all the coordinates where they're on the board :-)

    Mark


> -----Original Message-----
> From: owner-computer-go@xxxxxxxxxxxxxxxxx
> [mailto:owner-computer-go@xxxxxxxxxxxxxxxxx]On Behalf Of David Fotland
> Sent: Thursday, May 17, 2001 4:09 AM
> To: computer-go@xxxxxxxxxxxxxxxxx
> Subject: Re: computer-go: Sharing Go modules
>
>
>
> Many Faces uses 0 for Black, 1 for White, 2 for Empty.
>
> I use single dimension arrays.  0-360 are points (x+y*19), 361 is
> PASS, 362
> is NO_POINT.
>
> I have a separate array edge[363], which contains
> the distance to the nearest edge, that I use for edge detection.
>
> At 08:38 PM 5/16/2001 +0200, you wrote:
> > > I agree it's a good scheme. It's the same one that NNGS uses.
> > > Being able to address the neighbours of point pos as
> > > pos-Vdiff, pos-1, pos+1, and pos+Vdiff is quite a bit more convenient
> > > than dealing with (-1,0), (0,-1), (0,1), (1,0) vectors. Is it
> > > similarly standard to use 0 for EMPTY, 1 for BLACK, 2 for WHITE, and 3
> > > for EDGE ?
> >
> >If BLACK is 0 and WHITE is 1 is easy to write code like
> >
> >procedure DoSomething(p: boardoffset; color: boardcolor);
> >begin
> >   othercolor := 1-color;
> >   ...
> >end;
> >
> >since one rarely want to deal with the colors explicetely. But this is
> >of course a rather minor point. It does not matter for the
> >performance because you only make this transformation once in
> >every procedure.
> >
> >Magnus Persson
>
> David Fotland
>
>

David Fotland