Yep, still using brute force with some speed up techniques.

If I pre-sort the arrays I can make massive improvements in speed, but with a huge overhead in code.

If I convert to integer I can probably make similar improvements, again with code overhead.

At the moment I just want it to run to completion so I can check that the algorithm is OK before optimising.

Run times aren't too bad. Latest run (still active) is:
code:
Loop #1 started @ 09:00:28
CD #1 @ 09:00:28
CD #2 @ 09:02:18
CD #3 @ 09:02:20
CD #4 @ 09:02:25
CD #5 @ 09:02:34
CD #6 @ 09:02:37
CD #7 @ 09:02:37
CD #8 @ 09:02:44
CD #9 @ 09:05:32
CD #10 @ 10:07:56
CD #11 @ 10:08:01

CD#9 is the hardest so far at just over the hour.

I think I may be having rounding problems with the floating point which are causing some comparison problems. For instance, one of my checks halts processing down a tree when the gap become negative (too many tracks).

This is a problem when the values get buggered up internally, so instead of "1" you have "0.99999976234". Substract "1" from it and you will get a negative value which will cause the sequence to be deemed invalid.

Maybe I will have to switch to integer sooner rather than later...