Define the zeroth ramp number R(0) to be 123456789. Then define the nth ramp number R(n) to be R(n-1) with a 1 prepended and a 9 appended: R(1) = 11234567899, R(2) = 1112345678999, and so on.

Likewise, the antiramp numbers R'(n) are R'(0) = 987654321, R'(1) = 99876543211, R'(2) = 9998765432111, and so on.

Then R(17), R(19), and R'(38) are (if the Python primefac library is to be believed) primes. And they are the *only* ramp/antiramp primes for a good long time. I checked up through R(1000) and R'(1000)… and just when it seemed there were no more, R'(926) turns out to be prime:

9999999999999999999999999999999999999999999999999999999999999999

9999999999999999999999999999999999999999999999999999999999999999

9999999999999999999999999999999999999999999999999999999999999999

9999999999999999999999999999999999999999999999999999999999999999

9999999999999999999999999999999999999999999999999999999999999999

9999999999999999999999999999999999999999999999999999999999999999

9999999999999999999999999999999999999999999999999999999999999999

9999999999999999999999999999999999999999999999999999999999999999

9999999999999999999999999999999999999999999999999999999999999999

9999999999999999999999999999999999999999999999999999999999999999

9999999999999999999999999999999999999999999999999999999999999999

9999999999999999999999999999999999999999999999999999999999999999

9999999999999999999999999999999999999999999999999999999999999999

9999999999999999999999999999999999999999999999999999999999999999

9999999999999999999999999999999876543211111111111111111111111111111111111111111111111

11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

11111111111111111111111111111111111111111111111111111111111111111111111111111111111111111

and my first thought was, “Let’s see, so if each destroys half of all life…”

Or am I getting my pop culture mixed up? Well. Suppose we did have a line of, say, 63 Thanoses. Thani? Thanoxen? Something. One by one they snap their fingers and each time, half of all life is destroyed. You end up with of all life surviving. About 1.1E-19. Good luck surviving that.

But wait, that’s wrong. The first Thanos snaps and half of all life is destroyed… *including half of all Thanoses*. Of the 62 who haven’t snapped yet, now there are only 31 of them. After two snaps there are 15 who haven’t snapped. After three there are 7, after four there are 3, after five there is 1. That one snaps and we’re done. The surviving fraction is . Your odds still aren’t good but they’re enormously better.

6 is ; the surviving fraction is , or for initial Thanoses.

Well, but not exactly. Presumably this is a random, probabilistic thing. On average half of all Thanoses die on each snap, but there’s some probability they all survive, and some probability they all die. If they all die on the first snap, of us survive; if they all survive every snap, of us die. The former is a lot more likely than the latter, though.

I wrote a little Python script and got this distribution of survival fractions with 64 initial Thanoses: *[edited after bug fix]*

Fraction | Number of times |
---|---|

1/4 or more | 0 |

1/8 | 671 |

1/16 | 54,214 |

1/32 | 343,104 |

1/64 | 430,491 |

1/128 | 152,643 |

1/256 | 18,035 |

1/512 | 832 |

1/1024 | 10 |

So, good news, in the worst case there still are several million people alive. Just probably not you.

]]>I talked about how, instead of checking in base 10 every number up to, say, 10^{40}, you can check only numbers with no 0 or 1 digits, that do not have both a 5 and an even digit, with digits in increasing order, and that’s a vastly smaller number to check.

Similarly for other bases, but think about base 3. The only digits you have are 0, 1, and 2, so the only numbers that do not have 0 or 1 digits are all 2s: 2_{3}, 22_{3}, 222_{3}, 2222_{3}, …

There are 343,585,013,821,340,887,357,640,753,177,080,848,468,071,681,334 numbers that have 100 digits in base 3. Out of those only one needs to be checked (if you’ve already checked the 99 other numbers consisting of fewer 2s). Which is one heck of a speedup.

In base 4, any number with more than one digit equal to 2 has maximum persistence 2, so there are only two numbers per decade worth checking (23_{4}, 33_{4}, 233_{4}, 333_{4}, 2333_{4}, 3333_{4}, …)

So if we want to check numbers up to 100 digits, there are 100 base 3 numbers and 200 base 4 numbers. For base 5, there are 176,850 numbers. 181,900 in base 6, benefiting from the factors of 6, but 96,560,645 in base 7! Still a lot less than 7^{100}, but things are slowing down pretty hard.

In base 2, as I said, every number > 1 has persistence 1. (Either it contains a 0, so goes to 0, or it’s all 1s, so goes to 1.)

In base 3, only one number in each decade (of the form 222…222_{3}) is worth looking at. From 22222_{3} on most of the digit products seem to contain zeros so the persistence is 2. 22_{3} and 2222_{3} also have persistence 2. The only numbers up to 1000 digits with larger persistence seem to be 222_{3} and 222222222222222_{3} both with persistence 3.

For bases 3 through 16, as far as I’ve checked in each:

Base | Max persist | Min example |

3 | 3 | 222_{3} |

4 | 3 | 333_{4} |

5 | 6 | 3344444444444444444444_{5} |

6 | 5 | 24445_{6} |

7 | 8 | 444555555555555666_{7} |

8 | 5 | 333555577_{8} |

9 | 7 | 2577777_{9} |

10 | 11 | 277777788888899_{10} |

11 | 12 | 399999aaaaaaaaaaaaaaaaaaaaaaa_{11} |

12 | 7 | 3577777799_{12} |

13 | 14 | 7777779aaaaaaaaabcccccc_{13} |

14 | 13 | 55599999999999999aaaabbbbbb_{14} |

15 | 11 | 2bbbbccccdddddde_{15} |

16 | 8 | 379bdd_{16} |

One thing that seems to be happening is that you tend to get larger maximum persistences in prime bases, smaller ones in composite bases. Presumably that’s because of the analog to the 5-and-even situation in base 10: in a prime base, the digit product cannot be a multiple of the base, while in a composite base it can, in which case the digit product ends in a zero and terminates the sequence. Notice how every prime base from 5 on up has larger maximum persistence than the subsequent base. Also, recall 12 and 16 have respectively four and three proper divisors larger than 1, and then notice how small the maximum persistence is in bases 12 and 16 compared to bases 10, 11, 13, 14, and 15.

]]>But in written words, here it is: Take a number and multiply its digits (in base 10 unless otherwise noted) together. Then the product of the digits of that number. Then the product of the digits of that number. Keep going. Eventually you will reach a single digit number (the digit product for a multi-digit number is always less than that number, so it decreases at each step until a single digit is reached), and of course the digit product of a single digit number is itself, the end.

For instance: Starting from 28, we have 2×8 = 16, then 1×6 = 6 and you get to a single digit number in two steps. We say the multiplicative persistence of 28 is 2. From 88 it goes: 88, 64, 24, 8. Persistence is 3.

You might guess there’s no upper limit on persistence, that there can be numbers with persistence of 100 or 1000 or 1,000,000 or whatever; but actually the conjecture is that no number has persistence higher than 11. The smallest number with persistence 11 is 277,777,788,888,899:

277777788888899, 4996238671872, 438939648, 4478976, 338688, 27648, 2688, 768, 336, 54, 20, 0

Obviously the persistence doesn’t depend on the order in which the digits occur, so for instance 998,888,887,777,772 also has persistence 11. So does 27,777,772,228,888,899, where an 8 has been replaced by three 2s. Or by replacing all the 8s, and all the 9s by two 3s, you get numbers like 22,222,222,222,222,222,223,333,777,777, again with persistence 11. And of course adding a 1 digit doesn’t change anything, so 111,122,222,222,222,222,222,223,333,777,777 has persistence 11 too.

But no one has ever found a number with greater persistence. Why not?

Well, there’s a zero trap. Any number > 9 with a 0 digit in it has persistence 1. Any number that has no zero in it but does have a 5 and an even digit has persistence 2, because the product of its digits ends in 0. And even if a number has no zero and either no 5 or no 2, the same must be true of the product of its digits, and of the product of the digits of that product, and so on, for eleven steps in order for there to be a twelfth step. And when you’re dealing with numbers up around 277,777,788,888,899, the likelihood of that gets vanishingly small.

But how would you check if it’s *really* vanishing? The naive thing to do is to check all numbers up through, say, 10^{40}, but that would take, ah, a while. (What’s your computer’s clock speed? The age of the Universe is 4.3 × 10^{26} nanoseconds…). Checking all the *n-*digit numbers would take around ten times longer than the *n–1-*digit ones, and that gets intractable pretty fast.

But as we just noticed, there’s no point in checking numbers containing a zero. And up around 277,777,788,888,899, a lot of numbers do. You can also skip any number containing a 5 and an even digit. Numbers containing a 1 are equivalent to a smaller number without a 1, so no point in bothering with them either. And of course, there’s no point in checking a number whose digits are a permutation of a number you’ve already checked.

In fact, suppose you don’t worry about the 5-and-even check. Then you can just look at numbers containing only digits > 1 in nondecreasing order. Like this:

2, 3, 4, 5, 6, 7, 8, 9, 22, 23, 24, 25, 26, 27, 28, 29, 33, 34, 35… , 77, 78, 79, 88, 89, 99, 222, 223, 224…

There are 8 valid single digit numbers. For 2-digit numbers there are 8 valid first digits, but the second digit must not be less than the first, so there are 8 numbers starting with 2, 7 starting with 3, 6 starting with 4, and so on: 8+7+6+5+4+3+2+1 = 36. That’s the 8th triangular number. For three digits, the number of valid numbers is similarly the 8th tetrahedral number, and generally for *n* digits, the 8th *n*-simplex number:

That increases pretty slowly with *n*. You have to check 8 out of 10 1-digit numbers, but only 36 out of 90 2-digit numbers and 120 out of 900 3-digit numbers, and by the time you’re up to 40-digit numbers, you only have to check 62,891,499 of them! If you do skip over numbers with a 5 and an even digit, that drops even further to only 9,378,299 numbers. For 41 digits the number is 10,749,914, so instead of ten times as many numbers to check in that decade, there’s only about 15% more. A Python script can blow pretty easily through 50 or more digits in a fairly short time.

What you find is this: For valid (nondecreasing, all digits > 1) 15 digit numbers only one, 277,777,788,888,899, has persistence 11. For 16 digits, there’s only 2,247,777,778,888,899. For 17 digits there are two: 22,227,777,778,888,899 and 27,777,789,999,999,999. The first of these is a trivial modification of the 15-digit number, with the same digit product; the second has a different digit product, but the digit product of its digit product is the same as for the 15-digit number; it goes 27777789999999999, 937638166841712, 438939648, 4478976, 338688, 27648, 2688, 768, 336, 54, 20, 0.

Up to 29 digits there are only two valid numbers per decade with persistence 11, based on those two 17 digit numbers. The longest valid variant of 277,777,788,888,899 is 22,222,222,222,222,222,223,333,777,777 as noted above, and the other also has variants up to 29 digits. From 30 digits on up the maximum persistence is 10, with variants of a single number that peter out at 36 digits. For 37 through 42 digits maximum persistence is 8; for 43 through 44, 6: for 45 through 58, 5, and that’s all I’ve got so far.

The sequence of the persistences of the counting numbers is A031346 in OEIS, and the smallest number with persistence *n* is A003001. Per comments there, Martin Gardner wrote about the subject (of course), and there are results implying there are no numbers with persistence greater than 11 through 10^{20585}.

That’s in base 10. In binary, every number > 1 has persistence 1. I’ll leave the other bases to you.

]]>I keep feeling like there should be a simpler and more obvious proof but this is the best I’ve come up with:

So

But

and QED.

]]>- ???
- ???

That prompts a few questions: Are there solutions for 4 and 5? Are there solutions for *all* integers? Or for an infinite number of integers?

The answers to the first two questions are, no and no. Start by observing that the cube of any multiple of 3, , is divisible by 9 (in fact 27). For numbers equal to 1 mod 3, so is equal to 1 mod 9, and for numbers equal to -1 mod 3, so is equal to -1 mod 9. So all cubes are equal to 0 or ±1 mod 9. From this you can figure out all sums of three cubes are equal to 0, 1, 2, or 3 mod 9. But 4 and 5 equal -4 and +4 mod 9. So they cannot be written as sums of three cubes; nor can 13, 14, 22, 23, 31, 32, ….

As for the third question, it’s conjectured all other integers can be expressed as sums of three cubes. But it’s not proved.

The integers up through 11 are easy. In fact you might realize 10 can be done another way: . For that matter, and so on for an infinite number of solutions.

But 12 might take you a little longer: . Worse, . Things are pretty easy up through 29, and then 30 is hard. *Very* hard.

Good luck coming up with the simplest known answer:

.

Yikes!

So it goes. Lots of easy ones

interspersed with slightly tougher ones

But as of a few days ago, there were solutions known for all but two numbers less than 100 (other than the ±4 mod 9 impossibilities).

That was then. Andrew R. Booker has just published this result for the smallest hitherto-unsolved case:

I hardly need add that this was not found with a Python script during Booker’s lunch hour. The paper goes into the number theoretic gymnastics involved in his computer search, which, he reports, “used approximately 15 core-years over three weeks of real time.”

So that’s 33 solved. We’re down to one remaining unsolved number under 100. And I’m ready to give it to you. Now.

Though I don’t think that you’re going to like it.

All right.

You’re really not going to like it.

All right. The smallest for which no expression as the sum of three cubes is known is…

is…

Forty-two.

]]>Check out this grafting number, the second biggest I’ve got at the moment:

There’s some structure to understand here. This is generated using , , and . You can read those values off the numbers above, though. There are 22 digits in the integer on the left, and that’s . On the right, those 22 digits recur starting 7 digits left of the decimal point; that’s . Before them are the digits , which is .

Likewise, examine this one:

You can see and , so , and .

Though here’s an evil one:

Here and , so , and . Or… wait, is it? If you write the integer on the left as then and so and . Or should you write it as and conclude and so and ? Turns out all three interpretations are valid; they lead to three different equations yielding the same grafting number.

What about this miserable attempt at a grafting number?

Well, and , so , um, ? And ? Those give (with the sign in the quadratic formula, unlike all normal grafting numbers, because the sign gives ) and the equation or . Yes, that sort of fits the profile, but in an ugly way.

Likewise, and have similarly pathological analyses. Those I think really do need to be counted as grafting numbers, but not normal ones.

Two things I have not figured out yet is why it’s always the ceiling, not the floor, that gives the grafting number, and why and gives grafting numbers for, apparently, all values of while other values of and don’t. I suspect these are related. Observe

(with braces denoting fractional part) which is, to first order

and is whatever it is, but it’s in and for an approximate result we can take so

.

By taking the square root of the ceiling of a number instead of itself, we add approximately to the square root. By the same token, using floor subtracts about .

That’s sort of an average, though, and in the case of grafting numbers, it’s often an overestimate. For instance, for , , we get . Then with we end up with grafting number . Clearly the ceiling in this case changes the number by several orders of magnitude less than . But why don’t numbers looking hypothetically like work out?

]]>We could use other values for the coefficient of , though. Any power of 10 in fact. (For grafting numbers in base 10. If you want grafting numbers in another base, use powers of that base.) We have . Solutions are . Real solutions are obtained up to but we want . You can figure out this means .

For instance, with , we can use . With , . Now = 2 (), 103, 10206, 1020515, 102051444… not one of which, sorry to report, is a grafting number. With , though, and , we get and that is a grafting number, though not very impressive. and gives us . Yes! That’s what I’m talking about! And with gives , , and .

And on it goes. Those two I started off the first post with, 60,755,907 and 63,826,090,875, arise from , , and and , , and , respectively. Here’s another: , ~~and that’s the only one I’ve found so far using floor instead of ceil.~~ *Edit:* This does not use floor; I must have been fooled by a rounding error. This comes from , , and . Then , and when rounded *up*. In fact I’ve found no cases where floor gives the grafting number, and exactly one case where both ceil and 1+ceil work: , , and giving grafting numbers 764 and 765. Otherwise it’s always ceil. Which suggests other questions to ask. Sometime.

A grafting number is a counting number whose digits appear (consecutively, and in order) in its square root, starting at or to the left of the decimal point.

Matt Parker excludes cases where the digits appear further to the right of the decimal point, which may seem an arbitrary restriction, but it makes sense if you think about it. We don’t know that square roots of nonsquare counting numbers are normal numbers, but it does seem plausible. A normal number is an irrational number in which every finite string of digits occurs with equal density to every other digit string of the same length. If square roots are normal then including numbers whose digits appear *anywhere* in their square root as grafting numbers would mean *every* nonsquare number is a grafting number! For instance:

That would be a bore, so we just allow numbers whose digits appear beginning at or to the left of the decimal point in their square roots.

The above definition allows and , for instance, and it probably shouldn’t, but let’s leave it as is for now.

We came up with a grafting number by first finding , then multiplying both sides by 100, and then rounding up the number under the radical sign to an integer.

100 was an arbitrary choice, though. What if we used ? That is, candidate grafting numbers would be .

Let’s check:

Seems to work every time. Notice the floor function *doesn’t* work, though: doesn’t match that last digit, for instance. It’s not obvious why the ceiling function works and the floor function doesn’t. One might think both could work, or floor but not ceiling, or neither. For that matter there’s the… superceil? The second integer higher? That works in one case: . There’s stuff to dig into here. But let’s set it aside.

We have here a series of grafting numbers, none of which is 60755907 or 63826090875 so clearly there’s more exploration to be done.

We got the above by considering , where . What about other values of , though? Expanding gives and so . Then when one solution is . (We want solutions in , so the other solution is discarded.)

So which looks promising. Let’s check:

- — nope.
- — nope.
- — nope.
- — nope.
- — finally!

And no, the floor function doesn’t work where the ceiling fails here (or where it succeeds). Looks like we have a way of generating *candidate* grafting numbers, but not necessarily good ones.

That was and . For , and there are no real solutions. So that’s that.

Except we can vary the right hand side of . The coefficient of can be any power of 10: . We’ll do that next time.

The grafting numbers less than a million (excluding the dubious 1, 100, and 10000) are:

n | sqrt(n) | |
---|---|---|

8 | 2.8284… | |

77 | 8.77496… | |

98 | 9.8994… | |

99 | 9.9498… | |

764 | 27.64054… | |

765 | 27.65863… | |

5711 | 75.5711585… | |

5736 | 75.736384… | |

9797 | 98.9797959… | |

9998 | 99.98999… | |

9999 | 99.99499… | |

76394 | 276.394645… | |

997997 | 998.997997995… | |

999998 | 999.998999… | |

999999 | 999.999499… |