Re: [gnugo-devel] Patch: life.c 1-dimensional

[Gunnar Farneback]

Inge wrote:
> > Why not use the NORTH, SOUTH etc macros?
> I find them more difficult to read than using +NS, -1, etc. 

I strongly disagree. I have tested both approaches and the compass
macros win by a large margin. I find it much faster to visualize
NORTH(pos) than pos-NS (which I find about equivalent to (i-1, j)),
especially when the expressions become more complex. For the most
complex example around, compare the implementation of dragon_escape()
in 3.1.11 and 3.1.10.

The most important difference, however, is that for unrolled loops,
the compass macros make it much easier to verify that all directions
are handled equally. Again dragon_escape() is a good example. I am
absolutely certain that 3.1.11 has an orientation independent
implementation. I have a much harder time verifying this in the 3.1.10
version, and in fact I'm not even convinced that's the case.

(Notice that in 3.1.11, the directions are consistently ordered SOUTH,
WEST, NORTH, EAST around the compass and similarly for the diagonal
directions. This helps a lot for verification of isotropy.)

> The 1D code is so new that there hasn't yet come up any definite way
> of doing things and we are currently experimenting to find out the
> best ways. I haven't made up my mind yet how to best do offsets, but
> so far I think explicit offsets are the best. Especially for more
> distant points, I think ii+2 is much more readable than
> EAST(EAST(ii)).

The EE and so on macros solve the readability problems with two-step
displacements. Three-step displacements are only used in one place,
the dragon_escape() function, and I think that code, examplified
below, is quite readable.

          if (board[NORTH(ii)] == EMPTY
              && board[EAST(ii)] == EMPTY
              && (board[NE(ii)] == color
                  || (board[NE(ii)] == color
                      && ON_BOARD(NORTH(NE(ii)))
                      && board[NORTH(NE(ii))] != other
                      && ON_BOARD(EAST(NE(ii)))
                      && board[EAST(NE(ii))] != other)))
            ENQUEUE(NE(ii));

I definitely don't find that rewriting it as

          if (board[ii-NS] == EMPTY
              && board[ii+1] == EMPTY
              && (board[ii-NS+1] == color
                  || (board[ii-NS+1] == color
                      && ON_BOARD(ii-2*NS+1)
                      && board[ii-2*NS+1] != other
                      && ON_BOARD(ii-NS+2)
                      && board[ii-NS+2] != other)))
            ENQUEUE(ii-NS+1);

would be any easier to read or visualize.

/Gunnar