Re: Sums of cubes (was Re: histrionics)

[Wes Groleau <wwgrol@ftw.rsc.raytheon.com>]

"Robert I. Eachus" wrote:
> 
> Wes Groleau wrote:
> >               when Constraint_Error =>
> >                 null;  -- If the sum gets a constraint error
> >                        -- and the number didn't, it's not a match.
> >                        -- In a block because we don't want an
> >                        -- error on 9,999 to prevent checking 10,000
> >                        -- (I think Robert missed this detail.)
> 
>    Nope, the sum of cubes of 999 is 3*729 = 2187, the sum of cubes for
> 9999 is
> 2916, etc.  If you were going for something like the tenth power it
> would be an issue.

Or if the package is instantiated with 0..1000 (for example).  Without
the handler for constraint_error, my version would stop at 99.
(I should have used 99 in the comment.)  Since Robert's version used
non-generic integers, it did not have that problem.  
(i.e., I apologize for my false accusation.)

Robert's version is undoubtedly more efficient, but mine is simpler.
However, if you're doing five digits or less, either version will take
longer to compile than to run.  Six digits runs in ten seconds
on a slow SPARC.  Seven digits is runs under 2.5 minutes.  So up to
seven digits, the optimizing analysis takes longer than a very
UNoptimized computation.

But Robert's fact about 9999:2916 made me think:

The largest possible sum-of-cubes for six digits is 6 * 9**3 = 4374
The smallest possible six-digit number is bigger than that.
So it's pointless to go beyond five digits.  Or is my math wrong?

Took less than a minute to show with a spreadsheet that

with power of      you can stop at
2                       3 digits
3                       5 digits
4                       5 digits
5                       6 digits
6                       7 digits
7                       8 digits
8                       9 digits
9                      10 digits