Nice Numbers

I'm looking for numbers that have a special property: square-cube pandigitals. There's no particular reason; they're not the key to unlocking some proof or formula. We call them “nice numbers” but that's not an official term. There's no Wikipedia page for “nice numbers”. But math isn't about why, it's about why not! So bring out the lemons and let's get cracking.

A number is nice if and contain every possible digit exactly once.

Let's take, say, 68. The square of 68 is 4624. The cube is 314,432. Between them you can find the digit 1 once, and the digit 2 twice. 3 is also in there twice, and 4 is there four times. Meanwhile we're missing 5, 7, 8, 9, and 0. This number is not nice.

But if we go up to 69, then our square and cube are 4671 and 328,509. There's exactly one of each digit from 0-9, so we found it! The one and only known nice number. This is funny for obvious reasons.

69 is the only nice number

Here, I'll give you the controls. Try it out and find another nice number.

Choose a number:
The number has a square of and a cube of .
There are /10 unique digits and duplicates in the square-cube set.
This leaves /10 in the set exactly once.

It's not that hard to check exhaustively, you can write a script to do that in a couple minutes. For every number, get the square and the cube and see if there are any missing or repeated digits.

At a certain point the square and cube have so many digits it's impossible to avoid repeats. If there are less than 10 digits in the set, there aren't enough to get one of each digit. If there are too many there's at least one guaranteed duplicate.

So we're done then?

Well, only if we limit ourselves to base 10.

Other bases

You may be familiar with binary, using 0s and 1s to represent numbers. That's base 2, since it uses two digits to represent possible values. We typically use base 10, which uses 10 digits (0-9). So when we were checking to see if all possible digits were present, we were checking against these 10 values. But there’s nothing in the rules that says we have to use base 10.

Revision 1: A number is nice in base if and , as represented in base , contain every digit of exactly once.

Now there's so much more room for activities to search! Pick a number and a base and I'll do the same thing as before, except this time I'll convert the square and cube into your selected base before plotting the result.

Choose a number:
Choose a base:
The number has a square of and a cube of .
These are converted into the sets and .
There are / unique digits and duplicates in the square-cube set.
This leaves / in the set exactly once.

...

Wait, you couldn’t find any? Are you sure you looked everywhere?

Let's plot the number of unique digits for a whole bunch of numbers in a whole bunch of bases:

You're right, even with all of these options there doesn't seem to be any other nice numbers. Plus my wrists hurt from converting all of those numbers to the other bases.

Getting smart

Okay, it doesn’t seem feasible to check every single number in every single base. That would take literally forever. We have to make some optimizations.

First, We’re going to be talking about “ and , as represented in base " a lot, so I’m going to call that set the sqube.

Second, let's look at that plot again, but this time at the total number of digits in the sqube.

Remember if there are too many (or not enough) digits in the sqube, it's impossible to get exactly one of each digit. Let's highlight the spots where the sqube has the correct number of digits.

That just eliminated the vast majority of possibilities! Now we only have to search those green lines, where there's just the right number of digits to be possible.

Another thing: notice how there are no green dots in base 6 or 11? We won't have to search those because there's no chance of a nice number in those bases at all.

We just took this problem from "stupid and literally impossible" to "stupid and very difficult". Progress!

A brief aside

I should probably calrify some things. I did not come up with this problem, nor most of the clever tricks in this post. Most of this came from the exceptional Jacob Cohen, AKA Conflux, and you can read his account of the search for nice numbers over on his blog. I am but your humble guide on this safari into the savannah of pointless math, and I beg you indulge me for just a few minutes more.

Also for any pedants: I'm only counting real, positive integers here. That should technically be in the definition, so here you go:

Revision 2: A number in is nice in base if and , as represented in base , contain every digit of exactly once.

The search

Let's take a look at what we know so far:

So now when we look at a number, first we'll check if it's in any of those magic ranges for the bases. If it's not, we can toss it right out. If it is, we check which range it's in and work in that base. Those ranges end up being:

Base Start End
10 47 100
11 - -
12 144 329
13 398 609
14 734 1138
15 1369 3375
16 - -
17 4913 12632
18 15285 24743
19 29898 48838
20 58945 160000

These continue on infinitely, but our search doesn't.

Distributed computing

You can build a pretty sweet gaming PC for a few thousand bucks. My desktop computer can chew through these numbers pretty fast, calculating bases and squbes and unique numbers faster than it can print them out on the screen. But we're talking about searching trillions of numbers here, so we'll need more than my desktop.

There's a reason that "supercomputers" aren't just built like one huge gaming PC: they're designed to break up big tasks into hundreds of smaller ones and run them across dozens of machines. If you're a researcher, you can queue up jobs on your friendly local cluster that will eventually run on a random node and get your results back within 3-5 business days. If you're a rnadom guy looking for nice numbers, you can hack together an API server to break up the infinite search field into chunks and connect all of the spare computers you have around the house to it and get results immediately.

The plan is:

  1. The server breaks up each base into "fields" of at most a billion numbers each.
  2. The client requests a field and waits for a response.
  3. The server picks the next available field and reserves it for the client.
  4. The client searches the range and sends back any results.
  5. The server checks the results and saves them for analysis.
  6. ???
  7. Profit!

Instead of one PC running the search script, now we have a dozen computers running at full blast without stepping on each other's toes. Surely we'll find something in no time at all!

How long is this thing, anyways?

How far are we going to have to search before we find another nice number? In order to figure that out we need two pieces of information:

  1. How large is our search range?
  2. How frequent are nice numbers are in that range?

We know the first bit, so let's focus on the second.

We don't care what order the unique digits are in, so for a hypothetical nice number in base , there are valid (nice) ways the digits can be arranged.

Since there are digits in possible positions, there are possible combinations of digits.

Therefore, the probability of a number in base being nice is .

Let's plot it to see these probabilities! Here's the chance that any specific valid number happens to be nice:

Well that doesn't look too good.

Never tell me the odds

You might think we're at a dead end. The probability of a nice number anywhere past base 16 is zero! There's nothing for us to find!

Thankfully for us, it's not actually zero. It's just so incredibly small that every calculator in the world will round down. (Aren't we having fun yet?)

For completeness's sake, let's show the other half of our equation: the size of each base range.

And then we multiply them to get the probability for there to be any nice number in the range:

Exponential scaling to the rescue! These ranges are unbelievably massive, and they more than balance out the incredibly small chance that any one number is nice. According to this, there's a very high chance of a nice number past base 120, and maybe even infinitely many out past base 140!

The downside

Now we know how far to search before we think we'll find a nice number, and we've got a whole swarm of computers searching to get there.

Let's see how long it'll take to get to those endless fields of nice numbers...

Base Total Range Chance of a Nice Number Time to Search
to 30 8.31e+08 ~0% 72 seconds
to 45 8.70e+14 ~0% 2.4 years
to 65 4.27e+23 1% 130 years
to 85 7.29e+32 3% 1.1 million years
to 100 1.16e+40 10% 3.18e25 years
to 110 9.41e+44 50% 2.58e30 years
to 120 9.18e+49 100% 2.52e35 years

(Maybe exponential scaling isn't all that great.)

Unbowed, unbent, unbroken, we carry on. This problem is tuly a giant, but if we keep hacking away then there's a (technically) non-zero chance we'll find something! And won't it be funny if the next nice number was something like 69^420?

What we have so far

So far we've exhaustively searched through base 48, and we have detailed analytics into base 42. We've found no nice numbers, though we did find one number that was surprisingly close (4,134,931,983,708). We've found no specific patterns in digit distribution or niceness, but that doesn't mean we've come away empty-handed.

One metric we gather of each base range is the "niceness", or the ratio of uniques to the base (if the niceness of any number is 1, it's a perfectly nice number). This could be useful to see if there's a pattern of specific bases being "nicer" than others. The niceness of each base range seems to be narrowing down on 0.632, which is the value of (and what one would expect if the digit distributions are indeed psuedorandom).

The charts below are reproduced with a bit more color and updated more often at https://nicenumbers.net.

Here we have a plot of all the "almost nice" numbers, mostly numbers that are off by one or two. You can see an arc of each, which increases as the bases get higher.

And here we have a plot of the average niceness of each field. The bounding box horizontally contains the search range, which is compressed on the right due to the log plot. The vertical bounds are centered on the niceness mean and extend one standard deviation up and down.