[computer-go] another subject?

[forrest curo]

Since I signed up for this list, I've been receiving all sorts of 
material about how to test existing programs against one another.

Does this bunch ever get around to the merits of various ways of 
representing the board and arriving at moves?

For example, something I suggested the last time I was on a computer go 
list, back in the 90's: Take an array of 7 64-bit integers...

Put the top row of the board into bits 58-40 of the second integer, the 
next row into the same part of the third integer,  so-on until the 7th 
row fits into bits 38-20 of the first integer (and the 14th into bits 
19-1.) Bits 59-40 of the first integer, 18-0 of the 7th integer, are 
zeroed out (representing rows off the top and the bottom of the board, 
respectively.)

If we're showing the spaces on a vacant board, for example, that's

$00000ffffeffffe        nothing -row 7-row 14
$ffffeffffeffffe          row 1--row 8--row 15
$ffffeffffeffffe          row 2--row 9--row 16
$ffffeffffeffffe          row 3--row 10--row 17
$ffffeffffeffffe          row 4--row 11--row 18
$ffffeffffeffffe          row 5--row 12--row 19
$ffffeffffe00000        row 6--row 13--nothing

 Seven large numbers showing the presence or absence of one condition 
(in this case, an empty intersection) at each point.

Not useful? If you have an array like this, and another like it showing 
the location of all the black spaces, a few shifts and bitwise logical 
operations will give you a new array showing all the breathing spaces of 
all black chains on the board.

It takes at least two such arrays to fully represent a go position, with 
considerable redundancy at that, even more so if you use separate arrays 
for black stones, white stones, empties--but on a true 64-bit machine, 
one ought to be able to test for all sorts of local configurations 
really FAST.

Even on the plain old 32 bit pc I was using back when I actually worked 
on this, I found the representation above was good for quickly detecting 
captures (etc). These days, considering trying again, still on 32 bits, 
I'm inclined to use 19-integer arrays for the sake of keeping things 
simple & debuggable. But maybe someone else will find a use for this 
system--or suggest an arrangement I might find more useful?

Forrest Curo
San Diego