Ramp primes

I have no idea who’s gotten to this before me, nothing turns up in Google…

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

Advertisements

Thanoseses

I saw this tweet:

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 1/2^{63} 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 1/2^{6} \approx 1.6\%. Your odds still aren’t good but they’re enormously better.

6 is \log_2(63+1); the surviving fraction is 1/2^{\log_2(64)} = 1/64, or 1/2^{\log_2(n+1)} = 1/(n+1) for n 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, 1/2 of us survive; if they all survive every snap, 1/2^n 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]

FractionNumber of times
1/4 or more0
1/8671
1/1654,214
1/32343,104
1/64430,491
1/128152,643
1/25618,035
1/512832
1/102410

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

Limited persistence (part 3)

By the way:

I talked about how, instead of checking in base 10 every number up to, say, 1040, 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: 23, 223, 2223, 22223, …

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 (234, 334, 2334, 3334, 23334, 33334, …)

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 7100, but things are slowing down pretty hard.

Limited persistence (part 2)

I lied about leaving the other bases to you.

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…2223) is worth looking at. From 222223 on most of the digit products seem to contain zeros so the persistence is 2. 223 and 22223 also have persistence 2. The only numbers up to 1000 digits with larger persistence seem to be 2223 and 2222222222222223 both with persistence 3.

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

BaseMax persistMin example
332223
4
33334
5633444444444444444444445
65244456
784445555555555556667
853335555778
9725777779
10
1127777778888889910
1112399999aaaaaaaaaaaaaaaaaaaaaaa11
127357777779912
13147777779aaaaaaaaabcccccc13
141355599999999999999aaaabbbbbb14
15112bbbbccccdddddde15
168379bdd16

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.

Limited persistence

There’s a numberphile video about the number 277,777,788,888,899:

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, 1040, but that would take, ah, a while. (What’s your computer’s clock speed? The age of the Universe is 4.3 × 1026 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:

N(n) = \frac{(7+n)!}{7!n!}

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

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

Crafting grafting, part 4

(I’ve gone back and revised my notation. a becomes j and b becomes 10^m.)

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

\sqrt{8578201027979935320056}=92618578201.027979935320056863...

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

Likewise, examine this one:

\sqrt{4110105646} = 64110.105646457...

You can see 2n+m = 10 and n = 4, so m = 2, and j = 6.

Though here’s an evil one:

\sqrt{576276646} = 24005.76276646922...

Here 2n+m = 9 and n = 1, so m = 7, and j = 2400. Or… wait, is it? If you write the integer on the left as 0576276646 then 2n+m = 10 and n = 2 so m = 6 and j = 240. Or should you write it as 00576276646 and conclude 2n+m = 11 and n = 3 so m = 5 and j = 24? 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?

\sqrt{100} = 10.000...

Well, 2n+m = 3 and n = 2, so m = , um, -1? And j = 0? Those give x = 0.1000... (with the + sign in the quadratic formula, unlike all normal grafting numbers, because the - sign gives x=0) and the equation 10^2(0+0.1) = \sqrt{10^4(10^{-1}(0.1))} or 10 = \sqrt{100}. Yes, that sort of fits the profile, but in an ugly way.

Likewise, \sqrt{98} = 9.8995... and \sqrt{99} = 9.9498... 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 j = 2 and m = 1 gives grafting numbers for, apparently, all values of n while other values of j and m don’t. I suspect these are related. Observe

\sqrt{\lceil y \rceil}  = \sqrt{y-\{y\}+1} = \sqrt{y}\sqrt{1-\frac{\{y\}-1}{y}}

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

\sqrt{y}\left (1-\frac{\{y\}-1}{2y} \right ) = \sqrt{y} - \frac{\{y\}-1}{2\sqrt{y}}

and \{y\} is whatever it is, but it’s in 0<\{y\}<1 and for an approximate result we can take \{y\}\approx1/2 so

\sqrt{\lceil y \rceil}  \approx \sqrt{y} + \frac{1}{4\sqrt{y}}.

By taking the square root of the ceiling of a number y instead of y itself, we add approximately 1/(4\sqrt{y}) to the square root. By the same token, using floor subtracts about 1/(4\sqrt{y}).

That’s sort of an average, though, and in the case of grafting numbers, it’s often an overestimate. For instance, for n = 3, j = 8079, we get x=49991903-\sqrt{2499190300000000}=6557202816420999992418.... Then with m = 8 we end up with grafting number \lceil 65572028164209.99992418... \rceil. Clearly the ceiling in this case changes the number by several orders of magnitude less than \approx 1/2. But why don’t numbers looking hypothetically like \lfloor 65572028164209.00002418... \rfloor work out?

Crafting grafting, part 3

In the first two parts we found some grafting numbers using the equation (j+x)^2=10x with j=1~{\mathrm or~}2. Real solutions 0 < x < 1 can be turned into integer grafting number candidates \lceil 10^{2n+1}x\rceil. Or potentially \lfloor 10^{2n+1}x\rfloor but we haven’t found a case where that works.

We could use other values for the coefficient of x, 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 (j+x)^2=10^mx. Solutions are x = ((10^m-2j)\pm\sqrt{10^{2m}-4\times 10^mj})/2. Real solutions are obtained up to j=10^m/4 but we want 0 < x < 1. You can figure out this means j < \sqrt{10^m}-1.

For instance, with m=2, we can use 0 < j < 9. With j=1, x = 0.0102051443.... Now \lceil 10^{2n}(100x)\rceil = 2 (n=0), 103, 10206, 1020515, 102051444… not one of which, sorry to report, is a grafting number. With j=8, though, and n = 0, we get \sqrt{77} = 8.77496... and that is a grafting number, though not very impressive. j=6 and n = 4 gives us \sqrt{4110105646} = 64110.105646457.... Yes! That’s what I’m talking about! And j=7 with n = 1, 3, 5 gives \sqrt{5736} = 75.73638..., \sqrt{57359313} = 7573.5931366..., and \sqrt{57359312880715} = 7573593.1288071582....

And on it goes. Those two I started off the first post with, 60,755,907 and 63,826,090,875, arise from j=7794, m=8, and n=0 and j=252, m=5, and n=3, respectively. Here’s another: \sqrt{44144658239614} = 6644144.658239614216..., 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 j=66, m=4, and n=5. Then x = 0.4414465823961399708..., and 10^{14}x = 44144658239614 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: j=2, m=1, and n=1 giving grafting numbers 764 and 765. Otherwise it’s always ceil. Which suggests other questions to ask. Sometime.