Debugging strategy?

[Andrew Dalke]

Duncan Smith wrote in message <8m78ee$dds$1 at news7.svr.pol.co.uk>...
>Has anyone any idea how I might tackle this problem?  Does it
>sound characteristic of a particular type of coding error (bearing in mind
>I'm no computer scientist)?

When I was working on some graph theory code, I designed it around
a set of transformations where the results of the transformations
had certain properties, sometimes called 'invariants'.  Then in my
code I could ask at various points "does it it meet the right
invariants?"  The debugging time went up a lot, but I could use it
to figure out where the problem was and limit it to (usually) just
a short set of code paths.

> I find that either the tree has not been permuted
> correctly, or the weight has not been calculated correctly

So you have a tree and a transformation and a permuted tree, and the
new tree wasn't permuted correctly.  Can you write a test for
incorrectly permuted trees then execute it after every transformation?
If you know the final good tree, you can use that as the basis for
debugging, so you won't have to do another 20K iterations.

Once you have a good error case, try winnowing the input set down.
For example, take one of the children of the top node of the tree
and see if there's an error there.  Then try the next.  Descend until
there are no more errors, the back up one and try to do it manually,
comparing results.  Or figure out if there's anything which makes that
case unusual.

                    Andrew