Power Trip

Here are the first few powers of 2:

2 = 1 * 2
4 = 2 * 2
8 = 4 * 2
16 = 8 * 2
32 = 16 * 2
64 = 32 * 2
128 = 64 * 2
256 = 128 * 2
512 = 256 * 2
1024 = 512 * 2
2048 = 1024 * 2
4096 = 2048 * 2
8192 = 4096 * 2
16384 = 8192 * 2
32768 = 16384 * 2
65536 = 32768 * 2
131072 = 65536 * 2
262144 = 131072 * 2
524288 = 262144 * 2
1048576 = 524288 * 2
2097152 = 1048576 * 2
4194304 = 2097152 * 2
8388608 = 4194304 * 2
16777216 = 8388608 * 2
33554432 = 16777216 * 2
67108864 = 33554432 * 2…

As you can see, it’s a one-way power-trip: the numbers simply get larger. But what happens if you delete the digit 0 whenever it appears in a result? For example, 512 * 2 = 1024, which becomes 124. If you apply this rule, the sequence looks like this:

2 * 2 = 4
4 * 2 = 8
8 * 2 = 16
16 * 2 = 32
32 * 2 = 64
64 * 2 = 128
128 * 2 = 256
256 * 2 = 512
512 * 2 = 1024 → 124
124 * 2 = 248
248 * 2 = 496
496 * 2 = 992
992 * 2 = 1984
1984 * 2 = 3968
3968 * 2 = 7936
7936 * 2 = 15872
15872 * 2 = 31744
31744 * 2 = 63488
63488 * 2 = 126976
126976 * 2 = 253952
253952 * 2 = 507904 → 5794
5794 * 2 = 11588
11588 * 2 = 23176
23176 * 2 = 46352
46352 * 2 = 92704 → 9274…

Is this a power-trip? Not quite: it’s a return trip, because the numbers can never grow beyond a certain size and the sequence falls into a loop. If the result 2n contains a zero, then zerodelete(2n) < n, so the sequence has an upper limit and a number will eventually occur twice. This happens at step 526 with 366784, which matches 366784 at step 490.

The rate at which we delete zeros can obviously be varied. Call it 1:z. The sequence above sets z = 1, so 1:z = 1:1. But what if z = 2, so that 1:z = 1:2? In other words, the procedure deletes every second zero. The first zero occurs when 1024 = 2 * 512, so 1024 is left as it is. The second zero occurs when 2 * 1024 = 2048, so 2048 becomes 248. When z = 2 and every second zero is deleted, the sequence begins like this:

1 * 2 = 2
2 * 2 = 4
4 * 2 = 8
8 * 2 = 16
16 * 2 = 32
32 * 2 = 64
64 * 2 = 128
128 * 2 = 256
256 * 2 = 512
512 * 2 = 1024 → 1024
1024 * 2 = 2048 → 248
248 * 2 = 496
496 * 2 = 992
992 * 2 = 1984
1984 * 2 = 3968
3968 * 2 = 7936
7936 * 2 = 15872
15872 * 2 = 31744
31744 * 2 = 63488
63488 * 2 = 126976
126976 * 2 = 253952
253952 * 2 = 507904 → 50794
50794 * 2 = 101588 → 101588
101588 * 2 = 203176 → 23176
23176 * 2 = 46352
46352 * 2 = 92704 → 92704
92704 * 2 = 185408 → 18548

This sequence also has a ceiling and repeats at step 9134 with 5458864, which matches 5458864 at step 4166. And what about the sequence in which z = 3 and every third zero is deleted? Does this have a ceiling or does the act of multiplying by 2 compensate for the slower removal of zeros?

In fact, it can’t do so. The larger 2n becomes, the more zeros it will tend to contain. If 2n is large enough to contain 3 zeros on average, the deletion of zeros will overpower multiplication by 2 and the sequence will not rise any higher. Therefore the sequence that deletes every third zero will eventually repeat, although I haven’t been able to discover the relevant number.

But this reasoning applies to any rate, 1:z, of zero-deletion. If z = 100 and every hundredth zero is deleted, numbers in the sequence will rise to the point at which 2n contains sufficient zeros on average to counteract multiplication by 2. The sequence will have a ceiling and will eventually repeat. If z = 10^100 or z = 10^(10^100) and every googolth or googolplexth zero is deleted, the same is true. For any rate, 1:z, at which zeros are deleted, the sequence n = zerodelete(2n,z) has an upper limit and will eventually repeat.


Update (30×21)

Six years later, I’ve found the answer for z = 3. And uncovered a serious error in this article. See:

Power Trap

Block n Rule

One of my favourite integer sequences uses the formula n(i) = n(i-1) + digsum(n(i-1)), where digsum(n) sums the digits of n. In base 10, it goes like this:

1, 2, 4, 8, 16, 23, 28, 38, 49, 62, 70, 77, 91, 101, 103, 107, 115, 122, 127, 137, 148, 161, 169, 185, 199, 218, 229, 242, 250, 257, 271, 281, 292, 305, 313, 320, 325, 335, 346, 359, 376, 392, 406, 416, 427, 440, 448, 464, 478, 497, 517, 530, 538, 554, 568, 587, 607, 620, 628, 644, 658, 677, 697, 719, 736, 752, 766, 785, 805, 818, 835, 851, 865, 884, 904, 917, 934, 950, 964, 983, 1003…

Another interesting sequence uses the formula n(i) = n(i-1) + digprod(n(i-1)), where digprod(n) multiplies the digits of n (excluding 0). In base 10, it goes like this:

1, 2, 4, 8, 16, 22, 26, 38, 62, 74, 102, 104, 108, 116, 122, 126, 138, 162, 174, 202, 206, 218, 234, 258, 338, 410, 414, 430, 442, 474, 586, 826, 922, 958, 1318, 1342, 1366, 1474, 1586, 1826, 1922, 1958, 2318, 2366, 2582, 2742, 2854, 3174, 3258, 3498, 4362, 4506, 4626, 4914, 5058, 5258, 5658, 6858, 8778, 11914, 11950, 11995…

You can apply these formulae in other bases and it’s trivially obvious that the sequences rise most slowly in base 2, because you’re never summing or multiplying anything but the digit 1. However, there is a sequence for which base 2 is by far the best performer. It has the formula n(i) = n(i-1) + blockmult(n(i-1)), where blockmult(n) counts the lengths of distinct blocks of the same digit, including 0, then multiplies those lengths together. For example:

blockmult(3,b=2) = blockmult(11) = 2
blockmult(28,b=2) = blockmult(11100) = 3 * 2 = 6
blockmult(51,b=2) = blockmult(110011) = 2 * 2 * 2 = 8
blockmult(140,b=2) = blockmult(10001100) = 1 * 3 * 2 * 2 = 12
blockmult(202867,b=2) = blockmult(110001100001110011) = 2 * 3 * 2 * 4 * 3 * 2 * 2 = 576

The full sequence begins like this (numbers are represented in base 10, but the formula is being applied to their representations in binary):

1, 2, 3, 5, 6, 8, 11, 13, 15, 19, 23, 26, 28, 34, 37, 39, 45, 47, 51, 59, 65, 70, 76, 84, 86, 88, 94, 98, 104, 110, 116, 122, 126, 132, 140, 152, 164, 168, 171, 173, 175, 179, 187, 193, 203, 211, 219, 227, 245, 249, 259, 271, 287, 302, 308, 316, 332, 340, 342, 344, 350, 354, 360, 366, 372, 378, 382, 388, 404, 412, 436, 444, 460, 484, 500, 510, 518, 530, 538, 546, 555, 561, 579, 595, 603, 611, 635, 651, 657, 663, 669, 675, 681…

In higher bases, it rises much more slowly. This is base 3:

1, 2, 3, 4, 6, 7, 8, 10, 11, 12, 14, 16, 17, 19, 20, 21, 22, 24, 26, 29, 31, 33, 34, 35, 37, 39, 42, 44, 48, 49, 51, 53, 56, 58, 60, 61, 62, 64, 65, 66, 68, 70, 71, 73, 75, 77, 79, 82, 85, 89, 93, 95, 97, 98, 100, 101, 102, 103, 105, 107, 110, 114, 116, 120, 124, 127, 129, 131, 133, 137, 139, 141, 142, 143, 145, 146, 147, 149, 151, 152, 154, 156, 158, 160, 163…

And this is base 10:

1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 90…

Note how, in bases 3 and 10, blockmult(n) often equals 1. In base 3, the sequence contains [141, 142, 143, 145]:

blockmult(141,b=3) = blockmult(12020) = 1 * 1 * 1 * 1 = 1
blockmult(142,b=3) = blockmult(12021) = 1 * 1 * 1 * 1 = 1
blockmult(143,b=3) = blockmult(12022) = 1 * 1 * 1 * 2 = 2

The formula also returns 1 much further along the sequence in base 3. For example, the 573809th number in the sequence, or n(573809), is 5775037 and blockmult(5775037) = blockmult(101212101212021) = 1^15 = 1. But in base 2, blockmult(n) = 1 is very rare. It happens three times at the beginning of the sequence:

1, 2, 3, 5, 6, 8, 11…

After that, I haven’t found any more examples of blockmult(n) = 1, although blockmult(n) = 2 occurs regularly. For example,

blockmult(n(100723)) = blockmult(44739241) = blockmult(10101010101010101010101001) = 2
blockmult(n(100724)) = blockmult(44739243) = blockmult(10101010101010101010101011) = 2
blockmult(n(100725)) = blockmult(44739245) = blockmult(10101010101010101010101101) = 2

Does the sequence in base 2 return another example of blockmult(n) = 1? The odds seem against it. For any given number of digits in base 2, there is only one number for which blockmult(n) = 1. For example: 1, 10, 101, 1010, 10101, 101010, 1010101… As the sequence increases, the percentage of these numbers becomes smaller and smaller. But the sequence is infinite, so who knows what happens in the end? Perhaps blockmult(n) = 1 occurs infinitely often.

Over Again

In Boldly Breaking the Boundaries, I looked at the use of squares in what I called over-fractals, or fractals whose sub-divisions reproduce the original shape but appear beyond its boundaries. Now I want to look at over-fractals using triangles. They’re less varied than those involving squares, but still include some interesting shapes. This is the space in which sub-triangles can appear, with the central seeding triangle coloured gray: triangle
Here are some over-fractals based on the pattern above: overtri1
overtri1_static


overtri2
overtri2_static


overtri3

overtri3_static


overtri4
overtri4_static


overtri5
overtri5_static


overtri6
overtri6_static


overtri7
overtri7_static


overtri8
overtri8_static


overtri9
overtri9_static


overtri10
overtri10_static


overtri11
overtri11_static


overtri12
overtri12_static


overtri13

overtri13_static


Boldly Breaking the Boundaries

In “M.I.P. Trip”, I looked at fractals like this, in which a square is divided repeatedly into a pattern of smaller squares:
2x2inner

2x2inner_static


3x3innera

3x3innera_static


3x3innerb

3x3innerb_static


As you can see, the sub-squares appear within the bounds of the original square. But what if some of the sub-squares appear beyond the bounds of the original square? Then a new family of fractals is born, the over-fractals:

fractal2x2a

fractal2x2a_static


fractal2x2b

fractal2x2b_static


fractal2x2c

fractal2x2c_static


fractal2x2d

fractal2x2d_static


fractal2x2e

fractal2x2e_static


fractal3x3a

fractal3x3a_static


fractal3x3b

fractal3x3b_static


fractal3x3c

fractal3x3c_static


fractal3x3d


fractal3x3e


fractal3x3f


fractal3x3g


fractal3x3h


fractal3x3i


fractal3x3j


fractal3x3k


fractal3x3l


fractal3x3m


fractal3x3n


fractal4x4a


fractal4x4c


fractal4x4b

Lette’s Roll

A roulette is a little wheel or little roller, but it’s much more than a game in a casino. It can also be one of a family of curves created by tracing the path of a point on a rotating circle. Suppose a circle rolls around another circle of the same size. This is the resultant roulette:
roulette1

roulette1static
The shape is called a cardioid, because it looks like a heart (kardia in Greek). Now here’s a circle with radius r rolling around a circle with radius 2r:
roulette2

roulette2static

That shape is a nephroid, because it looks like a kidney (nephros in Greek).

This is a circle with radius r rolling around a circle with radius 3r:
roulette3

roulette3static
And this is r and 4r:
roulette4

roulette4static
The shapes above might be called outer roulettes. But what if a circle rolls inside another circle? Here’s an inner roulette whose radius is three-fifths (0.6) x the radius of its rollee:
roulette5

roulette5static
The same roulette appears inverted when the inner circle has a radius two-fifths (0.4) x the radius of the rollee:
roulette5a
But what happens when the circle rolling “inside” is larger than the rollee? That is, when the rolling circle is effectively swinging around the rollee, like a bunch of keys being twirled on an index finger? If the rolling radius is 1.5 times larger, the roulette looks like this:
roulette6
If the rolling radius is 2 times larger, the roulette looks like this:
roulette2over

Here are more outer, inner and over-sized roulettes:

roulette_outer

roulette_inner

roulette_over

And you can have circles rolling inside circles inside circles:

roulette7

roulette0616

roulette0616all

And here’s another circle-in-a-circle in a circle:

roulette07c015c

Playing the Double Base

Here’s some mathematical nonsense:

10 > 12
100 > 122
1000 > 1222

How can 1000 > 1222? Well, it makes perfect sense in what you might call a double base. In this base, every number is identified by a unique string of digits, but the strings don’t behave as they do in a standard base.

To see how this double base works, first look at 9 in standard base 2. To generate the binary digits from right to left, you follow the procedure x mod 2 and x = x div 2, where (x mod 2) returns the remainder when x is divided by 2 and (x div 2) divides x by 2 and discards the remainder:

9 mod 2 = 1 → ...1
9 div 2 = 4
4 mod 2 = 0 → ..01
4 div 2 = 2
2 mod 2 = 0 → .001
2 div 2 = 1
1 mod 2 = 1 → 1001

So 9[b=10] = 1001[b=2]. To adapt the procedure to base 3, simply use x mod 3 and x = x div 3:

32 mod 3 = 2 → ...2
32 div 3 = 10
10 mod 3 = 1 → ..12
10 div 3 = 3
3 mod 3 = 0 → .012
3 div 3 = 1
1 mod 3 = 1 → 1012

So 32[b=10] = 1012[b=3].

But what happens if you mix bases and use (x mod 3) and (x div 2), like this?:

2 mod 3 = 2 → .2
2 div 2 = 1
1 mod 3 = 1 → 12

3 mod 3 = 0 → .0
3 div 2 = 1
1 mod 3 = 1 → 10

So 10 > 12, i.e. 10[b=3,2] > 12[b=3,2].

5 mod 3 = 2 → ..2
5 div 2 = 2
2 mod 3 = 2 → .22
2 div 2 = 1
1 mod 3 = 1 → 122

6 mod 3 = 0 → ..0
6 div 2 = 3
3 mod 3 = 0 → .00
3 div 2 = 1
1 mod 3 = 1 → 100

So 100 > 122.

11 mod 3 = 2 → ...2
11 div 2 = 5
5 mod 3 = 2 → ..22
5 div 2 = 2
2 mod 3 = 2 → .222
2 div 2 = 1
1 mod 3 = 1 → 1222

12 mod 3 = 0 → …0
12 div 2 = 6
6 mod 3 = 0 → ..00
6 div 2 = 3
3 mod 3 = 0 → .000
3 div 2 = 1
1 mod 3 = 1 → 1000

And 1000 > 1222. Here are numbers 1 to 32 in this double base:

1 = 1
12 = 2
10 = 3
121 = 4
122 = 5
100 = 6
101 = 7
1212 = 8
1210 = 9
1221 = 10
1222 = 11
1000 = 12
1001 = 13
1012 = 14
1010 = 15
12121 = 16
12122 = 17
12100 = 18
12101 = 19
12212 = 20
12210 = 21
12221 = 22
12222 = 23
10000 = 24
10001 = 25
10012 = 26
10010 = 27
10121 = 28
10122 = 29
10100 = 30
10101 = 31
121212 = 32

Given a number represented in this mixed base, how do you extract the underlying n? Suppose the number takes the form n = (digit[1]..digit[di]), where digit[1] is the first and leftmost digit and digit[di] the final and rightmost digit. Then this algorithm will extract n:

n = 1
for i = 2 to di
..n = n * 2
..while n mod 3 ≠ digit[i]
....n = n + 1
..endwhile
next i
print n

For example, suppose n = 12212[b=3,2]. Then di = 5 and the algorithm will work like this:

n = 1
n = n * 2 = 2.
2 mod 3 = 2 = digit[2]
2 * 2 = 4
4 mod 3 = 1 ≠ digit[3]
5 mod 3 = 2 = digit[3]
5 * 2 = 10
10 mod 3 = 1 = digit[4]
10 * 2 = 20
20 mod 3 = 2 = digit[5]

Therefore 12212[b=3,2] = 20[b=10].

Now try some more mathematical nonsense:

21 > 100
111 > 1,000
1,001 > 10,000
10,001 > 100,000

How can numbers with d digits be greater than numbers with d+1 digits? Easily. In this incremental base, the base adjusts itself as the digits are generated, like this:

5 mod 2 = 1 → .1
5 div 2 = 2
2 mod (2 + 1) = 2 mod 3 = 2 → 21

The first digit generated is 1, so the base increases to (2 + 1) = 3 for the second digit. Compare the procedure when n = 4:

4 mod 2 = 0 → ..0
4 div 2 = 2
2 mod 2 = 0 → .00
2 div 2 = 1
1 mod 2 = 1 → 100

So 21 > 100, because 4 is a power of 2 and all the digits generated by (x mod 2) are 0 except the final and leftmost. 2 + 0 = 2. Now try n = 33:

33 mod 2 = 1 → ...1
33 div 2 = 16
16 mod (2+1) = 16 mod 3 = 1 → ..11
16 div 3 = 5
5 mod (3+1) = 5 mod 4 = 1 → .111
5 div 4 = 1
1 mod (4+1) = 1 mod 5 = 1.

33[b=10] = 1111[b=2,3,4,5].

Here are numbers 1 to 60 in this incremental base (note how 21 > 100, 111 > 1000, 1001 > 10000 and 10001 > 100000):

1 = 1
10 = 2
11 = 3
100 = 4*
21 = 5*
110 = 6
101 = 7
1000 = 8*
111 = 9*
210 = 10
121 = 11
1100 = 12
201 = 13
1010 = 14
211 = 15
10000 = 16*
221 = 17
1110 = 18
1001 = 19*
2100 = 20
311 = 21
1210 = 22
321 = 23
11000 = 24
1101 = 25
2010 = 26
1011 = 27
10100 = 28
421 = 29
2110 = 30
1201 = 31
100000 = 32*
1111 = 33
2210 = 34
1021 = 35
11100 = 36
2001 = 37
10010 = 38
1211 = 39
21000 = 40
1121 = 41
3110 = 42
2101 = 43
12100 = 44
1311 = 45
3210 = 46
1221 = 47
110000 = 48
2201 = 49
11010 = 50
2011 = 51
20100 = 52
1321 = 53
10110 = 54
10001 = 55*
101000 = 56
2111 = 57
4210 = 58
1421 = 59
21100 = 60

And here are numbers 256 to 270 (Note how 8,421 > 202,100 > 100,000,000):

100000000 = 256*
11221 = 257
101110 = 258
32101 = 259
202100 = 260*
13311 = 261
41210 = 262
10321 = 263
1111000 = 264
24201 = 265
131010 = 266
23011 = 267
320100 = 268
8421 = 269*
52110 = 270

Extracting n from a number represented in this incremental base is trickier than for the double base using (x mod 3) and (x div 2). To see how to do it, examine 11221[b=incremental]. The fifth and rightmost digit is 1, so the base increases to (2 + 1) = 3 for the fourth digit, which is 2. The base increases to (3 + 2) = 5 for the third digit, which is 2 again. The base increases to (5 + 2) = 7 for the second digit, 1. But the first and rightmost digit, 1, represents (x div 7) mod (7 + 1 = 8). So n can be extracted like this:

digit[1] * 7 = 1 * 7 = 7
7 mod 7 = 0 ≠ digit[2]
8 mod 7 = 1 = digit[2]
8 * 5 = 40
40 mod 5 = 0 ≠ digit[3]
41 mod 5 = 1 ≠ digit[3]
42 mod 5 = 2 = digit[3]
42 * 3 = 126
126 mod 3 = 0 ≠ digit[4]
127 mod 3 = 1 ≠ digit[4]
128 mod 3 = 2 = digit[4]
128 * 2 = 256
256 mod 2 = 0 ≠ digit[5]
257 mod 2 = 1 = digit[5]

So 11221[b=8,7,5,3,2] = 257[b=10].

Now try 8421[b=incremental]. The fourth and rightmost digit is 1, so the base increases to (2 + 1) = 3 for the third digit, which is 2. The base increases to (3 + 2) = 5 for the second digit, 4. But the first and rightmost digit, 8, represents (x div 5) mod (5 + 4 = 9). So n can be extracted like this:

digit[1] * 5 = 8 * 5 = 40
40 mod 5 = 0 ≠ digit[2]
41 mod 5 = 1 ≠ digit[2]
42 mod 5 = 2 ≠ digit[2]
43 mod 5 = 3 ≠ digit[2]
44 mod 5 = 4 = digit[2]
44 * 3 = 132
132 mod 3 = 0 ≠ digit[3]
133 mod 3 = 1 ≠ digit[3]
134 mod 3 = 2 = digit[3]
134 * 2 = 268
268 mod 2 = 0 ≠ digit[4]
269 mod 2 = 1 = digit[4]

So 8421[b=9,5,3,2] = 269[b=10].

Narcischism

What have bits to do with splits? A lot. Suppose you take the digits 12345, split them in all possible ways, then sum the results, like this:

12345 → (1234 + 5) + (123 + 45) + (123 + 4 + 5) + (12 + 345) + (12 + 34 + 5) + (12 + 3 + 45) + (12 + 3 + 4 + 5) + (1 + 2345) + (1 + 234 + 5) + (1 + 23 + 45) + (1 + 23 + 4 + 5) + (1 + 2 + 345) + (1 + 2 + 34 + 5) + (1 + 2 + 3 + 45) + (1 + 2 + 3 + 4 + 5) = 5175.

That’s a sum in base 10, but base 2 is at work below the surface, because each set of numbers is the answer to a series of binary questions: split or not? There are four possible places to split the digits 12345: after the 1, after the 2, after the 3 and after the 4. In (1 + 2 + 3 + 4 + 5), the binary question “Split or not?” is answered SPLIT every time. In (1234 + 5) and (1 + 2345) it’s answered SPLIT only once.

So the splits are governed by a four-digit binary number ranging from 0001 to 1111. When the binary digit is 1, split; when the binary digit is 0, don’t split. In binary, 0001 to 1111 = 01 to 15 in base 10 = 2^4-1. That’s for a five-digit number, so the four-digit 1234 will have 2^3-1 = 7 sets of sums:

1234 → (123 + 4) + (12 + 34) + (12 + 3 + 4) + (1 + 234) + (1 + 23 + 4) + 110 (1 + 2 + 34) + (1 + 2 + 3 + 4) = 502.

And the six-digit number 123456 will have 2^5-1 = 31 sets of sums. By now, an exciting question may have occurred to some readers. Does any number in base 10 equal the sum of all possible numbers formed by splitting its digits?

The exciting answer is: 0. In other words: No. To see why not, examine a quick way of summing the split-bits of 123,456,789, with nine digits. The long way is to find all possible sets of split-bits. There are 2^8-1 = 255 of them. The quick way is to sum these equations:

1 * 128 + 10 * 64 + 100 * 32 + 1000 * 16 + 10000 * 8 + 100000 * 4 + 1000000 * 2 + 10000000 * 1
2 * 128 + 20 * 64 + 200 * 32 + 2000 * 16 + 20000 * 8 + 200000 * 4 + 2000000 * 2 + 20000000 * 1
3 * 128 + 30 * 64 + 300 * 32 + 3000 * 16 + 30000 * 8 + 300000 * 4 + 3000000 * 3
4 * 128 + 40 * 64 + 400 * 32 + 4000 * 16 + 40000 * 8 + 400000 * 7
5 * 128 + 50 * 64 + 500 * 32 + 5000 * 16 + 50000 * 15
6 * 128 + 60 * 64 + 600 * 32 + 6000 * 31
7 * 128 + 70 * 64 + 700 * 63
8 * 128 + 80 * 127
9 * 255

Sum = 52,322,283.

52,322,283 has eight digits. If you use the same formula for the nine-digit number 999,999,999, the sum is 265,621,761, which has nine digits but is far smaller than 999,999,999. If you adapt the formula for the twenty-digit 19,999,999,999,999,999,999 (starting with 1), the split-bit sum is 16,562,499,999,987,400,705. In base 10, as far as I can see, numbers increase too fast and digit-lengths too slowly for the binary governing the split-sums to keep up. That’s also true in base 9 and base 8:

Num = 18,888,888,888,888,888,888 (b=9)
Sum = 16,714,201,578,038,328,760

Num = 17,777,777,777,777,777,777 (b=8)
Sum = 17,070,707,070,625,000,001

So what about base 7? Do the numbers increase slowly enough and the digit-lengths fast enough for the binary to keep up? The answer is: 1. In base 7, this twenty-digit number is actually smaller than its split-bit sum:

Num = 16,666,666,666,666,666,666 (b=7)
Sum = 20,363,036,303,404,141,363

And if you search below that, you can find a number that is equal to its split-bit sum:

166512 → (1 + 6 + 6 + 5 + 1 + 2) + (16 + 6 + 5 + 1 + 2) + (1 + 66 + 5 + 1 + 2) + (166 + 5 + 1 + 2) + (1 + 6 + 65 + 1 + 2) + (16 + 65 + 1 + 2) + (1 + 665 + 1 + 2) + (1665 + 1 + 2) + (1 + 6 + 6 + 51 + 2) + (16 + 6 + 51 + 2) + (1 + 66 + 51 + 2) + (166 + 51 + 2) + (1 + 6 + 651 + 2) + (16 + 651 + 2) + (1 + 6651 + 2) + (16651 + 2) + (1 + 6 + 6 + 5 + 12) + (16 + 6 + 5 + 12) + (1 + 66 + 5 + 12) + (166 + 5 + 12) + (1 + 6 + 65 + 12) + (16 + 65 + 12) + (1 + 665 + 12) + (1665 + 12) + (1 + 6 + 6 + 512) + (16 + 6 + 512) + (1 + 66 + 512) + (166 + 512) + (1 + 6 + 6512) + (16 + 6512) + (1 + 66512) = 166512[b=7] = 33525[b=10].

So 33525 in base 7 is what might be called a narcischist: it can gaze into the split-bits of its own digits and see itself gazing back. In base 6, 1940 is a narcischist:

12552 → (1 + 2 + 5 + 5 + 2) + (12 + 5 + 5 + 2) + (1 + 25 + 5 + 2) + (125 + 5 + 2) + (1 + 2 + 55 + 2) + (12 + 55 + 2) + (1 + 255 + 2) + (1255 + 2) + (1 + 2 + 5+ 52) + (12 + 5 + 52) + (1 + 25 + 52) + (125 + 52) + (1 + 2 + 552) + (12 + 552) + (1 + 2552) = 12552[b=6] = 1940[b=10].

In base 5, 4074 is a narcischist:

112244 → (1 + 1 + 2 + 2 + 4 + 4) + (11 + 2 + 2 + 4 + 4) + (1 + 12 + 2 + 4 + 4) + (112 + 2 + 4 + 4) + (1 + 1 + 22 + 4 + 4) + (11 + 22 + 4 + 4) + (1 + 122 + 4 + 4) + (1122 + 4 + 4) + (1 + 1 + 2 + 24 + 4) + (11 + 2 + 24 + 4) + (1 + 12 + 24 + 4) + (112 + 24 + 4) + (1 + 1 + 224 + 4) + (11 + 224 + 4) + (1 + 1224 + 4) + (11224 + 4) + (1 + 1 + 2 + 2 + 44) + (11 + 2 + 2 + 44) + (1 + 12 + 2 + 44) + (112 + 2 + 44) + (1 + 1 + 22 + 44) + (11 + 22 + 44) + (1 + 122 + 44) + (1122 + 44) + (1 + 1 + 2 + 244) + (11 + 2 + 244) + (1 + 12 + 244) + (112 + 244) + (1 + 1 + 2244) + (11 + 2244) + (1 + 12244) = 112244[b=5] = 4074.

And in base 4, 27 is:

123 → (1 + 2 + 3) + (12 + 3) + (1 + 23) = 123[b=4] = 27.

And in base 3, 13 and 26 are:

111 → (1 + 1 + 1) + (11 + 1) + (1 + 11) = 111[b=3] = 13.

222 → (2 + 2 + 2) + (22 + 2) + (2 + 22) = 222[b=3] = 26.

There are many more narcischists in all these bases, even if you exclude numbers with zeroes in them, like these in base 4:

1022 → (1 + 0 + 2 + 2) + (10 + 2 + 2) + (1 + 02 + 2) + (102 + 2) + (1 + 0 + 22) + (10 + 22) + (1 + 022) = 1022[b=4] = 74.

1030 → (1 + 0 + 3 + 0) + (10 + 3 + 0) + (1 + 03 + 0) + (103 + 0) + (1 + 0 + 30) + (10 + 30) + (1 + 030) = 1030[b=4] = 76.

1120 → (1 + 1 + 2 + 0) + (11 + 2 + 0) + (1 + 12 + 0) + (112 + 0) + (1 + 1 + 20) + (11 + 20) + (1 + 120) = 1120[b=4] = 88.

Magistra Rules the Waves

One of my favourite integer sequences has the simple formula n(i) = n(i-1) + digitsum(n(i-1)). If it’s seeded with 1, its first few terms go like this:

n(1) = 1
n(2) = n(1) + digitsum(n(1)) = 1 + digitsum(1) = 2
n(3) = 2 + digitsum(2) = 4
n(4) = 4 + digitsum(4) = 8
n(5) = 8 + digitsum(8) = 16
n(6) = 16 + digitsum(16) = 16 + 1+6 = 16 + 7 = 23
n(7) = 23 + digitsum(23) = 23 + 2+3 = 23 + 5 = 28
n(8) = 28 + digitsum(28) = 28 + 2+8 = 28 + 10 = 38

As a sequence, it looks like this:

1, 2, 4, 8, 16, 23, 28, 38, 49, 62, 70, 77, 91, 101, 103, 107, 115, 122, 127, 137, 148, 161, 169, 185, 199, 218, 229, 242, 250, 257, 271, 281, 292, 305, 313, 320, 325, 335, 346, 359, 376, 392, 406, 416, 427, 440, 448, 464, 478, 497, 517, 530, 538, 554, 568, 587, 607, 620, 628, 644, 658, 677, 697, 719, 736, 752, 766, 785, 805, 818, 835, 851, 865, 884, 904, 917, 934, 950, 964, 983, 1003…

Given a number at random, is there a quick way to say whether it appears in the sequence seeded with 1? Not that I know, with one exception. If the number is divisible by 3, it doesn’t appear, at least in base 10. In base 2, that rule doesn’t apply:

n(1) = 1
n(2) = 1 + digitsum(1) = 10 = 1 + 1 = 2
n(3) = 10 + digitsum(10) = 10 + 1 = 11 = 2 + 1 = 3
n(4) = 11 + digitsum(11) = 11 + 1+1 = 101 = 3 + 2 = 5
n(5) = 101 + digitsum(101) = 101 + 1+0+1 = 111 = 5 + 2 = 7
n(6) = 111 + digitsum(111) = 111 + 11 = 1010 = 7 + 3 = 10
n(7) = 1010 + digitsum(1010) = 1010 + 10 = 1100 = 10 + 2 = 12
n(8) = 1100 + digitsum(1100) = 1100 + 10 = 1110 = 12 + 2 = 14

1, 2, 3, 5, 7, 10, 12, 14, 17, 19, 22, 25, 28, 31, 36, 38, 41, 44, 47, 52, 55, 60, 64, 65, 67, 70, 73, 76, 79, 84, 87, 92, 96, 98, 101, 105, 109, 114, 118, 123, 129, 131, 134, 137, 140, 143, 148, 151, 156, 160, 162, 165, 169, 173, 178, 182, 187, 193, 196, 199, 204, 208, 211, 216, 220, 225, 229, 234, 239, 246, 252, 258, 260, 262, 265, 268, 271, 276, 279, 284, 288, 290, 293, 297, 301, 306, 310, 315, 321, 324, 327, 332, 336, 339, 344, 348, 353, 357, 362, 367, 374…

What patterns are there in these sequences? It’s easier to check when they’re represented graphically, so I converted them into patterns à la the Ulam spiral, where n is represented as a dot on a spiral of integers. This is the spiral for base 10:

ulambase10Base 10


And these are the spirals for bases 2 and 3:

ulambase2

Base 2


ulambase3

Base 3


These sequences look fairly random to me: there are no obvious patterns in the jumps from n(i) to n(i+1), i.e. in the values for digitsum(n(i)). Now try the spirals for bases 9 and 33:

ulambase9

Base 9


ulambase33

Base 33


Patterns have appeared: there is some regularity in the jumps. You can see these regularities more clearly if you represent digitsum(n(i)) as a graph, with n(i) on the x axis and digitsum(n(i)) on the y axis. If the graph starts with n(i) = 1 on the lower left and proceeds left-right, left-right up the screen, it looks like this in base 10:

base10

Base 10 (click to enlarge)


Here are bases 2 and 3:

base2

Base 2


base3

Base 3


The jumps seem fairly random. Now try bases 9, 13, 16, 17, 25, 33 and 49:

base9

Base 9


base13

Base 13


base16

Base 16


base17

Base 17


base25

Base 25


base33

Base 33


base49

Base 49


In some bases, the formula n(i) = n(i-1) + digitsum(n(i-1)) generates mild randomness. In others, it generates strong regularity, like waves rolling ashore under a steady wind. I don’t understand why, but regularity seems to occur in bases that are one more than a power of 2 and also in some bases that are primes or squares.


Elsewhere other-posted:

Mathematica Magistra Mundi
8200_idf_insignia

Dig Sum Fib

The Fibonacci sequence is an infinitely rich sequence based on a very simple rule: add the previous two numbers. If the first two numbers are 1 and 1, the sequence begins like this:

1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, 233, 377, 610, 987, 1597, 2584, 4181, 6765, 10946, 17711, 28657, 46368, 75025…

Plainly, the numbers increase for ever. The hundredth Fibonacci number is 354,224,848,179,261,915,075, for example, and the two-hundredth is 280,571,172,992,510,140,037,611,932,413,038,677,189,525. But there are variants on the Fibonacci sequence that don’t increase for ever. The standard rule is n(i) = n(i-2) + n(i-1). What if the rule becomes n(i) = digitsum(n(i-2)) + digitsum(n(i-1))? Now the sequence falls into a loop, like this:

1, 1, 2, 3, 5, 8, 13, 12, 7, 10, 8, 9, 17, 17, 16, 15, 13, 10, 5, 6, 11, 8, 10, 9, 10, 10, 2, 3… (length=28)

But that’s in base 10. Here are the previous bases:

1, 1, 2, 2, 2… (base=2) (length=5)
1, 1, 2, 3, 3, 2, 3… (b=3) (l=7)
1, 1, 2, 3, 5, 5, 4, 3, 4, 4, 2, 3… (b=4) (l=12)
1, 1, 2, 3, 5, 4, 5, 5, 2, 3… (b=5) (l=10)
1, 1, 2, 3, 5, 8, 8, 6, 4, 5, 9, 9, 8, 7, 5, 7, 7, 4, 6, 5, 6, 6, 2, 3… (b=6) (l=24)
1, 1, 2, 3, 5, 8, 7, 3, 4, 7, 5, 6, 11, 11, 10, 9, 7, 4, 5, 9, 8, 5, 7, 6, 7, 7, 2, 3… (b=7) (l=28)
1, 1, 2, 3, 5, 8, 6, 7, 13, 13, 12, 11, 9, 6, 8, 7, 8, 8, 2, 3… (b=8) (l=20)
1, 1, 2, 3, 5, 8, 13, 13, 10, 7, 9, 8, 9, 9, 2, 3… (b=9) (l=16)

Apart from base 2, all the bases repeat with (2, 3), which is set up in each case by (base, base) = (10, 10) in that base, equivalent to (1, 1). All bases > 2 appear to repeat with (2, 3), but I don’t understand why. The length of the sequence varies widely. Here it is in bases 29, 30 and 31:

1, 1, 2, 3, 5, 8, 13, 21, 34, 27, 33, 32, 9, 13, 22, 35, 29, 8, 9, 17, 26, 43, 41, 28, 41, 41, 26, 39, 37, 20, 29, 21, 22, 43, 37, 24, 33, 29, 6, 7, 13, 20, 33, 25, 30, 27, 29, 28, 29, 29, 2, 3… (b=29) (l=52)

1, 1, 2, 3, 5, 8, 13, 21, 34, 26, 31, 28, 30, 29, 30, 30, 2, 3 (b=30) (l=18)

1, 1, 2, 3, 5, 8, 13, 21, 34, 25, 29, 54, 53, 47, 40, 27, 37, 34, 11, 15, 26, 41, 37, 18, 25, 43, 38, 21, 29, 50, 49, 39, 28, 37, 35, 12, 17, 29, 46, 45, 31, 16, 17, 33, 20, 23, 43, 36, 19, 25, 44, 39, 23, 32, 25, 27, 52, 49, 41, 30, 41, 41, 22, 33, 25, 28, 53, 51, 44, 35, 19, 24, 43, 37, 20, 27, 47, 44, 31, 15, 16, 31, 17, 18, 35, 23, 28, 51, 49, 40, 29, 39, 38, 17, 25, 42, 37, 19, 26, 45, 41, 26, 37, 33, 10, 13, 23, 36, 29, 35, 34, 9, 13, 22, 35, 27, 32, 29, 31, 30, 31, 31, 2, 3 (b=31) (l=124)

The sequence for base 77 is short like that for base 30:

1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 68, 81, 73, 78, 75, 77, 76, 77, 77, 2, 3 (b=77) (l=22)

But the sequence for base 51 is this:

1, 1, 2, 3, 5, 8, 13, 21, 34, 55, 39, 44, 83, 77, 60, 37, 47, 84, 81, 65, 46, 61, 57, 18, 25, 43, 68, 61, 29, 40, 69, 59, 28, 37, 65, 52, 17, 19, 36, 55, 41, 46, 87, 83, 70, 53, 23, 26, 49, 75, 74, 49, 73, 72, 45, 67, 62, 29, 41, 70, 61, 31, 42, 73, 65, 38, 53, 41, 44, 85, 79, 64, 43, 57, 50, 57, 57, 14, 21, 35, 56, 41, 47, 88, 85, 73, 58, 31, 39, 70, 59, 29, 38, 67, 55, 22, 27, 49, 76, 75, 51, 26, 27, 53, 30, 33, 63, 46, 59, 55, 14, 19, 33, 52, 35, 37, 72, 59, 31, 40, 71, 61, 32, 43, 75, 68, 43, 61, 54, 15, 19, 34, 53, 37, 40, 77, 67, 44, 61, 55, 16, 21, 37, 58, 45, 53, 48, 51, 49, 50, 99, 99, 98, 97, 95, 92, 87, 79, 66, 45, 61, 56, 17, 23, 40, 63, 53, 16, 19, 35, 54, 39, 43, 82, 75, 57, 32, 39, 71, 60, 31, 41, 72, 63, 35, 48, 83, 81, 64, 45, 59, 54, 13, 17, 30, 47, 77, 74, 51, 25, 26, 51, 27, 28, 55, 33, 38, 71, 59, 30, 39, 69, 58, 27, 35, 62, 47, 59, 56, 15, 21, 36, 57, 43, 50, 93, 93, 86, 79, 65, 44, 59, 53, 12, 15, 27, 42, 69, 61, 30, 41, 71, 62, 33, 45, 78, 73, 51, 24, 25, 49, 74, 73, 47, 70, 67, 37, 54, 41, 45, 86, 81, 67, 48, 65, 63, 28, 41, 69, 60, 29, 39, 68, 57, 25, 32, 57, 39, 46, 85, 81, 66, 47, 63, 60, 23, 33, 56, 39, 45, 84, 79, 63, 42, 55, 47, 52, 49, 51, 50, 51, 51, 2, 3… (b=51) (l=304)

Summer Set Sequence

I wondered what would happen if you added to a set of numbers, (a, b, c), the first number that wasn’t equal to the sum of any subset of the numbers: a + b, a + c, c + b, a + b + c. If the set begins with 1, the first number not equal to any subset of (1) is 2. So the set becomes (1, 2). 3 = 1 + 2, so 3 is not added. But 4 is added, making the set (1, 2, 4). The sequence of additions goes like this:

1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536…

It’s the powers of 2, because some subset of the powers of 2 < 2^p will equal any number from 1 to (2^p)-1, therefore the first addition will be 2^p = the cumulative sum + 1:

1 (cumulative sum=1), 2 (cs=3), 4 (cs=7), 8 (cs=15), 16 (cs=31), 32 (cs=63), 64 (cs=127), 128 (cs=255), 256 (cs=511), 512 (cs=1023), 1024 (cs=2047), 2048 (cs=4095), 4096 (cs=8191), 8192 (cs=16383), 16384 (cs=32767), 32768 (cs=65535)…

If you seed the sequence with the set (2), the first addition is 3, but after that the powers of 2 re-appear:

2, 3, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048, 4096, 8192, 16384, 32768, 65536…

It becomes more complicated if the sequence is seeded with the set (3):

3, 4, 5, 6, 16, 17, 49, 50, 148, 149, 445, 446, 1336, 1337, 4009, 4010, 12028, 12029, 36085, 36086…

You can predict the pattern by looking at the cumulative sums again:

3, 4, 5, 6 (cumulative sum=18), 16, 17 (cs=51), 49, 50 (cs=150), 148, 149 (cs=447), 445, 446 (cs=1338), 1336, 1337 (cs=4011), 4009, 4010 (cs=12030), 12028, 12029 (cs=36087), 36085, 36086 (cs=108258)…

The sequence begins with a block of four consecutive numbers, followed by separate blocks of two consecutive numbers. The first number in each 2-block is predicted by the cumulative sum of the last number in the previous block, according to the formula n = cumulative sum – seed + 1. When the seed is 3, n = cs-3+1.

If the seed is 4, the sequences goes like this:

4, 5, 6, 7, 8, 27, 28, 29, 111, 112, 113, 447, 448, 449, 1791, 1792, 1793, 7167, 7168, 7169…

Now the sequence begins with a block of five consecutive numbers, followed by separate blocks of three consecutive numbers. The formula is n = cs-4+1:

4, 5, 6, 7, 8 (cumulative sum=30), 27, 28, 29 (cs=114), 111, 112, 113 (cs=450), 447, 448, 449 (cs=1794), 1791, 1792, 1793 (cs=7170), 7167, 7168, 7169 (cs=28674)…

And here’s the sequence seeded with (5):

5, 6, 7, 8, 9, 10, 41, 42, 43, 44, 211, 212, 213, 214, 1061, 1062, 1063, 1064, 5311, 5312, 5313, 5314…

5, 6, 7, 8, 9, 10 (cs=45), 41, 42, 43, 44 (cs=215), 211, 212, 213, 214 (cs=1065), 1061, 1062, 1063, 1064 (cs=5315), 5311, 5312, 5313, 5314 (cs=26565)…