I've fixed the code - it took about three minutes to find the two bugs, and
then about three hours to run enough test cases to convince be that there were
only two bugs. [Laurent's idea with return(u-v) failed since u and v are of
type int64 and the qsort routine must return an integer, and I'd got the
program flow wrong through assuming the compiler would understand the
indenting rather than the braces]
Please download the new source or executables. If you haven't been handed a
range yet, please *rerun the 's253 TEST' command and mail me the result*, and
I'll hand you one.
If you started the project with the buggy code (I hope only Paul Leyland was
hit by this), just reissue the 's253 INIT <start> <end>' command and start
again.
If you had been running with the original slow code for a while, have a look
at your s253.results file in a text editor. It consists of lots of lines of
the shape
counter : time x y z [maybe more sets of x y z]
At some point near the end, you will notice that the 'time' field goes down
substantially and the sets of x y z vanish. Note the value of the counter at
the point the time goes down - *this may be before the first x y z vanishes*.
For example, if your file ends
9936 : 659000 0 0 21538
9937 : 705020 0 0 23561
9938 : 134070 0 0 33819
9939 : 137260
then the relevant value is 9938.
Delete all the lines from that counter value to the end of the file,
inclusive, and issue 's253 INIT <value> <end>', where <end> is the end of your
original range.
Then issue 's253 CONT' or 'start /m s253 CONT' or 'nice 19 ./s253 CONT', or
whatever command your operating system prefers, and carry on crunching ...
Sorry to muck you around; I'd incorporated a test case which I hoped would
stop me doing anything this stupid, but there was a bug in the test routine. I
had assumed the program would return the right number, albeit possibly of
wrong answers, so the test as coded returned success if the answers returned
were a subset (including an empty subset) of the correct ones.
Tom
