Yeah, doing a binary search on 5 numbers is bound to be faster than generating all the combinations and determining the product, but I still don't get anywhere near the 17+ seconds you see

You didn't read the output carefully did you :)

My point was that for the number '100000000000000000000000000000000000000000000000000000000001', both your code and tall_man's ran for 17.578 seconds.

Similarly, for '100000000000000000000000000000000000000000000000000000001' both ran for 3.265 seconds.

And for '10000000000000000000000000000000000000000000000000000000001' both ran for under 1/5th of a second.

The reason for moving to such big numbers was to try and find values that made the algorithm work very hard, so as to benchmark the algorithm rather than the implementation.

The conclusion that I was attempting to draw was that whilst your code wasn't displaying the correct final result, that both programs were taking nearly identical times to run--longer when the task was harder, shorter when simpler; and always within a few fractions of a second--and that your code was probably doing all the right work and just failing display the final result correctly.

Which is all the more impressive as your program is doing the work in Perl rather than C as with tall_man's code.

In other words, I was trying to pay you a complement.

Update: As it turns out, all of the time taken is to calculate the prime factors, with almost nothing to determine the nearest factor. Oh well!