(08-23-2017 11:53 PM)Claudio L. Wrote: [ -> ]This matches what Werner described, actually he mentioned 4880 for K=6, which I have not checked but have no reason to doubt either. That's why I think this is his algorithm.

That is part of it, yes. But soon you'll realise that this is too slow once the numbers get bigger and bigger.

I still use Free42 for now, and I precomputed all 20'031'232 12-digit numbers that have the trailing 12 digits of their cube in {2,3,5,7}, in ascending order (that is important, read on)

Then I started to narrow down the number of cubes to verify, by generating all prefixes with P numbers. We know the cubes must all be 2's, 3's, 5's and 7's, so all cubes must start with (P=1) 2,3,5, or 7 or (P=2) 22, 23, 25, 27, 32, 33 ... and so on. If you take P=6 we have 4^6 = 4096 prefixes, and I loop over them.

For each prefix <pf>, then, we know the cubes must be between

<pf>2222222.. and <pf>7777777... and so

(<pf>22222..)^(1/3) < x < (<pf>77777...)^(1/3)

Each additional order of P you generate will roughly halve the number of x's to verify.

For each x, then, I look up the next trailing 12 digits in my precomputed table (well it's REGS really) by a dichotomic search, and then verify each y

y := x-MOD(x,1e12) + REGS(i)

until y is larger than the upper limit (possibly going beyond the end of REGS and continuing at the beginning with x+1e12)

My current program (that is not finished yet ;-) will use this technique (with P=10) and a few other optimisations for 1e17 < x < 1e22.

I can use Free42 for x<1e34, but I'm afraid things will bog down even so.

BTW I'm pretty sure my technique can be used on a real 50g to find the first solution quite fast. I was planning on doing that to prove Joe wrong ("no current HP programmable calculator is fast enough to find the number in a reasonable amount of time")

;-))

Cheers, Werner