[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
computer-go: Sharing Go modules
Some time ago Anders Kierulf asked me if he could use my life-and-death
program for his new computer-go project. Although he offered to pay for it,
I declined because I didn't see an easy way to extract and modularize from
my 'Go Project' just the life-and-death part. And I wasn't prepared to give
him the whole lot. This doesn't necessarily mean my code is not modularized
and object-oriented (ok, maybe it does, but still...) but over time a
surprising amount of dependencies have cropped up on implementation details
and dependencies between modules.
Recently I have a fair amount of spare time and I spent some of it rewriting
some of my C++ Go modules in Java in a more clean and modular way. The
reason I'm doing this is that I'm not sure I'll ever write a complete Go
program again, but I think I have some good modules that would be a pity to
let just waste away, so I'm thinking of sharing them with the rest of the
world. So far I've completed four modules: a ladder-reading module, a
loose-ladder module, an influence-calculation module and a pattern-matcher.
Inevitably I ran into the dillemma of having to make more general interfaces
and implementations that go at the cost of performance. So far I think I've
succeeded pretty well, with the exception of coordinate defintion. Obviously
the most natural way to program Go information is in 2-dimensional arrays
and use separate X and Y coordinates. For performance reasons however, my
program uses just single values to code the coordinates and 1-dimensional
arrays to store information. It's easy enough to have the modules provide
2-dimensional coordinates in the interfaces and internally convert them, but
that again has a performance drawback of doing the conversion. And it's
especially a waste when two of those modules want to communicate with each
other that the conversion happens twice.
The coordinate coding method that I use is X,Y converts to X+Y*20. The
arrays are all 421 long where all te points at 0,Y and X,0 contain special
values to make it easy to detect the edge of the board. This is a convenient
coding since it's still fairly easy to see which coordinates they represent
(for example: 63 is 3,3 and 356 is 16,17). However I do realise that every
Go programmmer has their own idea of how this should be done and that
there's little chance that I can convince everyone in the world to use this
scheme (that would be nice though <grin>) instead of using separate X and Y
coordinates.
Is this the price we have to pay? Or are there schemes that provide the best
of both worlds? How is this done in the GNU project? Do all the GNU modules
use X,Y coordinates, or did someone decree a default coding method like I
described?
The other question when sharing modules is of course the choice of
programming language. Most Go programs today are written in C or C++ so
modules written in Java are not so useful. There's also the drawback that
Java is still slower than C (almost a factor 2) but other than that I think
it provides so many advantages that it will be just a matter of time before
more Go programs will be written in Java. I wonder if the GNU project is
considering such a move.