Re: computer-go: Sharing Go modules

[Don Dailey <drd@xxxxxxxxxxxxxxxxxxxxx>]

I use unit numbers too, but I do have 2 color  bits, one for white and
one for white, only  as an extra  convienence.  I'm happy to  see some
empirical evidence (the fact that a good programmer also uses it) that
the way I chose to represent my board is reasonable.

I am interested in what information  you keep per  unit.  I don't keep
much  right  now,  but  my list  has changed  from  time to  time with
different  versions.  But I'm focused  mainly  on very primitive basic
facts per unit:

     1.  Number of stones in unit.
     2.  A representive stone location. (can be any stone in unit)
     3.  Number of liberties for this unit.
     4.  Unit color
    
I'm only interested in  things that  can be incrementally  maintained,
otherwise I just compute from scratch when  I need it.   I feel that I
need more primitives in my unit structure.


Don




   Date: Thu, 17 May 2001 08:50:41 -0700
   From: David Fotland <fotland@xxxxxxxxxxxxxxxxx>

   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