[computer-go] Remarks on the Indigo-Paper

[Darren Cook]

>>1) Making a good development environment. E.g. a
>>good GUI, a database to 
>>store test positions, a set of testcases, a well
>>defined procedure to test 
>>the versions, Coding standards.
> 
> 1) is nice for other people to understand what
> you're doing, but it doesn't say much about the
> strength of the internal algorithms/ideas
> involved, which will always be the limiting
> feature of a go program, wouldn't you agree?

I don't worry too much about a GUI (I use ascii print-outs and my Board
class can read ascii diagrams) but I've found a test system very useful.

However I do have two problems with classical unit testing applied to go:

1. Getting the unit tests to pass is sometimes too hard. E.g. fixing an
algorithm to help it solve one life and death problem sometimes breaks
another. Is this a regression that should be reverted, or is it an
improvement. So it turns into measuring pass/fail rate across a large
test suite, but then it is harder to see genuine regressions due to
introducing a bug; it is also slower (see problem 2)

2. Unit tests are supposed to run in seconds; some of mine take minutes,
and I usually disable those that take even longer, defeating the purpose
of having them.

Darren