Fun with Numbers: The Pan-Prime-Digit Cube Hypothesis

[Claudio L.]

(08-23-2017 03:20 AM)DavidM Wrote:  

(08-23-2017 12:03 AM)Claudio L. Wrote:  ...
Has anyone tried the opposite way? Look at numbers with the correct digits, discard all the ones that cannot be perfect cubes (by the sum of their digits), and simply take the cube root of the ones left?
...

I had given some thought to this initially, but got hung up when thinking about how to generate all of the potential cubes that only contained the proper digits. Your idea about starting with a base 4 iteration and mapping the result to the proper digits is a nice way to achieve that. I also didn't realize until your mention of it that cubes have a characteristic "sum of digits" result (1, 8, or 9 apparently).

I'd still like to try to get something going on a 50g that will find the first known base within a reasonable (couple days?) time. I'd already been planning on a strategy involving the "only check numbers with good suffixes" approach. Perhaps I'll experiment with this one instead when I can get enough focused time to play with it!

Forget my idea. Seemed as a good starting point but then I realized that:

\((n+1)^3 = n^3 + (3n^2 + 3n +1)\)

In other words, the distance between one perfect cube and the next is \(3n^2 + 3n +1\). We are talking n around 12 to 16 digits, the distance for n=1e12 is 3e24, versus counting in base-4 across many, many numbers in that 3e24 range.
So my idea of going backwards would be orders of magnitude slower for large numbers, even if perhaps quick in the low range. There's no point in using it for large numbers.

One thing I see is the need for a command to extract individual digits from a number, so I added a DIGITS command to newRPL, where you provide the start and end range (in powers of 10, 0=unity, 1=tens, 2=hundreds, -1=tenths, etc.) and it extracts the digits, without having to go the string route.