# 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.

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.

The number

There are

This leaves

**in the set exactly once.** /10

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.

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 base:

The number

These are converted into the sets

There are

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 “**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:

# The search

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

- For most bases there is a single continuous range of numbers where the sqube has the right number of digits to possibly be nice.
- In the remaining bases (6, 11, and more) there are no possible nice numbers.
- The ranges of possible numbers in each base do not overlap.
- Each number is valid in at most one base.

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:

- The server breaks up each base into "fields" of at most a billion numbers each.
- The client requests a field and waits for a response.
- The server picks the next available field and reserves it for the client.
- The client searches the range and sends back any results.
- The server checks the results and saves them for analysis.
- ???
- 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:

- How large is our search range?
- 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

Since there are

Therefore, the probability of a number in base

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

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.