What number comes next?

[Hdjensofjfnen]

1, 78, 32, 119, 562, 17, 30, 20, 16, 155, ...
HINT:

Code: Select all

x = 39, y = 5, rule = B3/S23
2o2b3ob3obobob3ob3ob3ob3ob3ob3o$bo4bo3bobobobo3bo5bobobobobobobo$bo2b
3ob3ob3ob3ob3o3bob3ob3obobo$bo2bo5bo3bo3bobobo3bobobo3bobobo$3ob3ob3o
3bob3ob3o3bob3ob3ob3o!

[Hdjensofjfnen]

Solution: Written out in the font provided, the lifespan of the number before it is the next number in the series. Anyone want to continue it?

[77topaz]

155 -> 217 -> 341 -> 22 -> 30, and we have a loop.

Of course, we can also do this starting at other numbers:

2 -> 3 -> 50 -> 16, and we've entered the same loop/attractor.

4 -> 36 -> 66 -> 112 -> 11 -> 14 -> 11, and we have a new, period-2 loop (the other one has period 7).

[Hdjensofjfnen]

155 -> 217 -> 341 -> 22 -> 30, and we have a loop.

Of course, we can also do this starting at other numbers:

2 -> 3 -> 50 -> 16, and we've entered the same loop/attractor.

4 -> 36 -> 66 -> 112 -> 11 -> 14 -> 11, and we have a new, period-2 loop (the other one has period 7).

Cool. Why not 3?

[77topaz]

3 already appears in the sequence for 2, it's redundant to list it separately.

5 is just a mirrored 2, so it immediately falls into the same sequence.

6 (or 9) -> 1150 -> 2411 -> 276 -> 56 -> 19 -> 39 -> 37 -> 35 -> 119, and we've entered the attractor for the period-7 loop.

[Moosey]

7->4, so we get to the period-2 loop.
8->21->21->21, we have a period 1 loop
9 is a mirrored 6
10->8->21
11 is in the known period 2 loop (11->14->11)
12->21, so it joins the (21)1-loop.

Terminology time!
A loop is expressed as (x)n-loop where x is the lowest number in the loop and n is the amount of numbers.
Known loops:
(21)1-loop
(11)2-loop
(13)11-loop


Also, is there any finite number whose next number in its sequence is very large, Ideally with the number growing without limit?

EDIT:
(13)11 not (16)7

[77topaz]

That terminology seems workable to me.

13 -> 607 -> 2063 -> 260 -> 1884 -> 53 -> 705 -> 55 -> 30 -> (16)7-loop

14 is known to be in the (11)2-loop.

15 -> 74 -> 13 -> (16)7-loop

16 and 17 are known to lead to the (16)7-loop.

[Hdjensofjfnen]

18 --> 31 --> 6 --> (16)7-loop

Code: Select all

x = 7, y = 5, rule = B3/S23
2o2b3o$bo2bobo$bo2b3o$bo2bobo$3ob3o!

EDITS:
19 leads to (16)7-loop
20 is part of (16)7-loop
21 is part of (21)1-loop
22 is part of (16)7-loop
23 --> 705, which leads to (16)7-loop
24 --> 11, which is part of (11)2-loop
25 --> 6 leads to (16)7-loop
26 --> 6 leads to (16)7-loop
27 --> 1227 --> 623 --> 39 which leads to (16)7-loop
28 --> 150 --> 31 which leads to (16)7-loop
29 --> 61 --> 19 which leads to (16)7-loop
30 --> 54 --> 72 --> 13 which leads to (16)7-loop
31 --> 6 leads to (16)7-loop
32 leads to (16)7-loop
33 --> 18 leads to (16)7-loop
34 --> 311 --> 9 which leads to (16)7-loop
35 = 32
36 leads to (11)2-loop YAAAY ANYTHING BUT THE 7-LOOP
37 leads to (16)7-loop
38 --> 26 leads to (16)7-loop
39 leads to (16)7-loop
40 --> 793 --> 30 leads to (16)7-loop
41 --> 370 --> 678 (with a natural eater!) --> 487 --> 412 --> 212 --> 176 --> 673 --> 247 --> 11, which we all know is part of the (11)2-loop
The (16)7-loop looks really common because of all of its various terms.

[Moosey]

someone needs to make a script to enumerate these.

Open question:
are there any loops besides the 3 known ones so far?

[Moosey]

Hold on, wait:
there is no (16)7-loop ( ), 16 evolves into this (13)11-loop! (705->55->30->54->72->13->607->2063->260->1884->53->705)

Code: Select all

x = 25, y = 710, rule = B3/S23
14b3ob3ob3o$16bobobobo$16bobobob3o$16bobobo3bo$16bob3ob3o75$17b3ob3o$
17bo3bo$17b3ob3o$19bo3bo$17b3ob3o77$7b3ob3o$9bobobo$7b3obobo$9bobobo$
7b3ob3o40$10b3obobo$10bo3bobo$10b3ob3o$12bo3bo$10b3o3bo103$14b3ob3o$
16bo3bo$16bob3o$16bobo$16bob3o55$14b2o2b3o$15bo4bo$15bo2b3o$15bo4bo$
14b3ob3o33$7b3ob3ob3o$7bo3bobo3bo$7b3obobo3bo$7bobobobo3bo$7b3ob3o3bo
150$3b3ob3ob3ob3o$5bobobobo5bo$3b3obobob3ob3o$3bo3bobobobo3bo$3b3ob3ob
3ob3o35$4b3ob3ob3o$6bobo3bobo$4b3ob3obobo$4bo3bobobobo$4b3ob3ob3o33$2o
2b3ob3obobo$bo2bobobobobobo$bo2b3ob3ob3o$bo2bobobobo3bo$3ob3ob3o3bo64$
7b3ob3o$7bo5bo$7b3ob3o$9bo3bo$7b3ob3o!

[77topaz]

Hold on, wait:
there is no (16)7-loop ( ), 16 evolves into this (13)11-loop! (705->55->30->54->72->13->607->2063->260->1884->53->705)

Code: Select all

x = 25, y = 710, rule = B3/S23
14b3ob3ob3o$16bobobobo$16bobobob3o$16bobobo3bo$16bob3ob3o75$17b3ob3o$
17bo3bo$17b3ob3o$19bo3bo$17b3ob3o77$7b3ob3o$9bobobo$7b3obobo$9bobobo$
7b3ob3o40$10b3obobo$10bo3bobo$10b3ob3o$12bo3bo$10b3o3bo103$14b3ob3o$
16bo3bo$16bob3o$16bobo$16bob3o55$14b2o2b3o$15bo4bo$15bo2b3o$15bo4bo$
14b3ob3o33$7b3ob3ob3o$7bo3bobo3bo$7b3obobo3bo$7bobobobo3bo$7b3ob3o3bo
150$3b3ob3ob3ob3o$5bobobobo5bo$3b3obobob3ob3o$3bo3bobobobo3bo$3b3ob3ob
3ob3o35$4b3ob3ob3o$6bobo3bobo$4b3ob3obobo$4bo3bobobobo$4b3ob3ob3o33$2o
2b3ob3obobo$bo2bobobobobobo$bo2b3ob3ob3o$bo2bobobobo3bo$3ob3ob3o3bo64$
7b3ob3o$7bo5bo$7b3ob3o$9bo3bo$7b3ob3o!

You're right. Hdjensofjfnen incorrectly said in the OP that 30 leads to 20, which we all assumed was true:

Code: Select all

x = 7, y = 5, rule = B3/S23
3ob3o$2bobobo$3obobo$2bobobo$3ob3o!

30 -> 54 is the correct link.

[Hdjensofjfnen]

You're right. Hdjensofjfnen incorrectly said in the OP that 30 leads to 20, which we all assumed was true:

Code: Select all

x = 7, y = 5, rule = B3/S23
3ob3o$2bobobo$3obobo$2bobobo$3ob3o!

30 -> 54 is the correct link.

I cannot believe I confused this sequence with aliquot sequences.
EDIT: Oh, wait, I see what I got wrong:

Code: Select all

x = 7, y = 5, rule = B3/S23
3ob3o$2bobobo$b2obobo$2bobobo$3ob3o!

EDIT:
42 --> 362 --> 203 --> 30, part of (13)11.
43 --> 365 --> 27 --> 1227 --> 623 --> 39 --> 37 --> 35 --> 119 --> 562 --> 17 --> 30, part of (13)11.
44 --> 61 --> 19 --> 39 --> 37 -> 35 -> 119 --> 562 --> 17 --> 30, part of (13)11.
45 --> 944 --> 1308 --> 348 --> 247 --> 11, part of (11)2.
46 --> 17 --> 30, part of (13)11.

[dvgrn]

someone needs to make a script to enumerate these.

You can say that again! Tracking this stuff by hand must get old after a while.

On the other hand, Python or Lua code that reliably tells you the exact time that a methuselah stabilizes continues to be hard to find. One possibility is to adapt the methuselah fingerprinter script. That will work for everything that's come up in these sequences so far, but will start to fail whenever switch engines show up, or any oscillator with a period that's not a factor of 6.

Maybe stabilize3() from apgsearch 1.x would be a better bet, or maybe nowadays there's a lifelib call that the latest apgsearch uses to pinpoint methuselah lifespans -- there's a get_popseq(), for example, but I haven't figured out whether it can be used from Python yet.

Anyway, here's a small initial contribution to a semi-automated sequence tracker script:

Code: Select all

# makedigits.py
import golly as g
g.setrule("Life")

digits = ["3o$obo$obo$obo$3o!","2o$bo$bo$bo$3o!",
             "3o$2bo$3o$o$3o!","3o$2bo$3o$2bo$3o!",
             "obo$obo$3o$2bo$2bo!","3o$o$3o$2bo$3o!",
             "3o$o$3o$obo$3o!","3o$2bo$2bo$2bo$2bo!",
             "3o$obo$3o$obo$3o!","3o$obo$3o$2bo$3o!"]
digitcells = [g.parse(d) for d in digits]

def makedigits(i):
    cells, offset = [],0
    for char in str(int(i)):
        cells+=g.transform(digitcells[int(char)],offset,0)
        offset+=4
    return cells

pat = makedigits(1234567890)
g.addlayer()
g.putcells(pat)

[77topaz]

Here's an updated version of that script, repurposing some code from isorule.py to allow users to select what number they put in:

Code: Select all

# makedigits.py

import golly as g
from glife import validint

g.setrule("Life")

digits = ["3o$obo$obo$obo$3o!","2o$bo$bo$bo$3o!",
             "3o$2bo$3o$o$3o!","3o$2bo$3o$2bo$3o!",
             "obo$obo$3o$2bo$2bo!","3o$o$3o$2bo$3o!",
             "3o$o$3o$obo$3o!","3o$2bo$2bo$2bo$2bo!",
             "3o$obo$3o$obo$3o!","3o$obo$3o$2bo$3o!"]
digitcells = [g.parse(d) for d in digits]

def makedigits(i):
    cells, offset = [],0
    for char in str(int(i)):
        cells+=g.transform(digitcells[int(char)],offset,0)
        offset+=4
    return cells

s = g.getstring('Enter the number:', '', 'Number placer')
if not validint(s):
    g.exit('Bad number: %s' % s)

stringvalue = int(s)
if stringvalue < 0:
    g.exit('Negative numbers not included.')

pat = makedigits(s)
g.addlayer()
g.putcells(pat)

EDIT: Added an error message for if you try to enter a negative number (those are not caught by validint).

[testitemqlstudop]

Every number eventually enters a loop.

Collatz Conjecture version 2.

[testitemqlstudop]

Here's a version of apgluxe I named uncreatively "apgerator" (apgluxe + iterator) that prints out the time it takes for an arbitrary RLE to stabilize.

COMPILE WITH " --symmetry stdin"

Reason it's 5MB is because it includes lifelib

https://drive.google.com/file/d/1aVzGgJ ... sp=sharing

[77topaz]

47 -> 41 -> (11)2

48 -> 58 -> 150 -> 31 -> (13)11

49 -> 154 -> 110 -> 9 -> (13)11

50 is known to lead to (13)11.

51 -> 23 -> (13)11

52 is a mirrored 25, and so also leads to (13)11.

53, 54 and 55 are in (13)11.

56 is known to lead to (13)11.

57 -> 26 -> (13)11

58 is known to lead to (13)11 (see 48).

59 -> 105 -> 20 -> (13)11

60 -> 14 -> (11)2

Also, a few single iterations of numbers with more digits:
1234 -> 194, 12345 -> 1376, 123456 -> 181, 9906738142 -> 425
With all of these lasting for far shorter than the numbers they encode, I strongly suspect the Testitem Conjecture is indeed correct - there may be some many-digit number that manages to lead to a higher number via trickery involving switch engines or some such, but then the next number would just lead to something lower again.

In fact, I suspect a number's lifetime is, on average, proportional to its number of digits and thus log(itself), rather than itself.

[dvgrn]

With all of these lasting for far shorter than the numbers they encode, I strongly suspect the Testitem Conjecture is indeed correct - there may be some many-digit number that manages to lead to a higher number via trickery involving switch engines or some such, but then the next number would just lead to something lower again.

In fact, I suspect a number's lifetime is, on average, proportional to its number of digits and thus log(itself), rather than itself.

The second paragraph seems likely to be true, but I bet the first paragraph is just a version of the hasty induction fallacy. Eric Angelini's EAlvetica font is basically identical to these numbers except for the "1" which is a minimal vertical line instead of a fixed-width 3x5 character:

Code: Select all

x = 71, y = 95, rule = B3/S23
3ob3o$obobobo$3obobo$2bobobo$3ob3o26$3ob3ob3ob3o$2bo3bobobo3bo$3ob3obo
bo3bo$2bobo3bobo3bo$3ob3ob3o3bo26$3obobobob3obobo$obobobobo3bobobo$3ob
3obo3bob3o$2bo3bobo3bo3bo$3o3bobo3bo3bo26$ob3ob3ob3ob3ob3obob3ob3ob3ob
3ob3ob3obobob3obobob3obobobobo$obobobo3bo3bobobobobobobobobo3bobobo3bo
3bobobobobobobo3bobobobobo$ob3ob3ob3ob3ob3obobobobobob3ob3o3bob3obobob
obob3ob3obobob3o$obobo3bo3bo3bobobobobobobobobo5bo3bo3bobobobobo3bo3bo
bobo3bo$ob3ob3ob3ob3ob3obob3ob3ob3ob3o3bob3obobob3o3bob3obobo3bo!

Dean Hickerson figured out how to do all kinds of things with EAlvetica, up to and including building arbitrarily complex objects with 90-degree slow-pair glider constructions. The above is from Golly's Life/Syntheses/life-integer-constructions.rle, but see also Scripts/Lua/life-integer-gun30.lua.

I bet it will also be possible with this font to find pairs of numbers that make clean [leftward *WSS(es) plus rightward *WSS(es)], which collide to make NW- and NE-traveling gliders, just like in life-integer-gun30. And once those are available, we can use slow-pair constructions -- or probably even just any old recipe for a NE-traveling glider --

Code: Select all

x = 123, y = 5, rule = B3/S23
3ob3obobobobobobobobobobobobobobobobobobobobobobobobobobobobobobob3obo
bob3ob3ob3obobobobobobobobobobobobobobobobobobo$obobobobobobobobobobob
obobobobobobobobobobobobobobobobobobobobobobobo3bobo3bo3bobo3bobobobob
obobobobobobobobobobobobobo$3ob3ob3ob3ob3ob3ob3ob3ob3ob3ob3ob3ob3ob3ob
3ob3ob3ob3ob3o3bob3ob3ob3ob3ob3ob3ob3ob3ob3ob3ob3o$obobobo3bo3bo3bo3bo
3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bobobo3bo3bo3bo3bo3bo3bo3bo
3bo3bo$3ob3o3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bob3o3bo3bob3ob
3o3bo3bo3bo3bo3bo3bo3bo3bo3bo!

-- and then a matching NW-traveling glider to shoot it down and make a stationary target, followed by a NW slow salvo. (Would have to clean up the blinker with a *WSS, or find a cleaner recipe than the above.)

Slow salvos can be compiled with slmake, so we could build arbitrarily complex patterns, including ones that never become predictable so they have infinite lifespans. That would stop a loop from happening, right?

-- Would an infinite-spaceships gun be good enough to count as having an infinite lifespan? If not, what _is_ the lifespan of an infinite-spaceships gun? If it would have to be something more complicated, how about a pi calculator?

[77topaz]

That's precisely the kind of trickery I was referring to. You could use such tricks to make a single number that lasts for an arbitrarily high number of generations, but then the next number will just fall lower again, and then eventually lead to a loop. With a particular amount of patience, you could even design such a number so that the number of generations the number lasts also forms a UC mechanism. Perhaps you could even string an arbitrary number of them together. But that arbitrary number would still be finite, because each longer chain would require more and more digits to start with. You couldn't build an infinitely climbing sequence without requiring an infinite amount of complexity and thus an infinite amount of digits to begin with, and so the sequence of any finite number will eventually decrease again and fall into a loop, and so the Testitem Conjecture would hold.

[Moosey]

If you make a universal construtor/coumputer, you could in theory make it last a number n such that n is larger than the number that made the previous UCC and n produces a UCC as well with a similar fate, lasting another number (q) such that q is larger than n and also produces a UCC... You’d probably want to compute these numbers beforehand though. Of course, these numbers needn’t be immediately following each other in the sequence, there just need to be “attainable” by the UCC. If there is some way for the UCC to compute n in less than n generations and there are infinitely many numbers that are larger than the previous and make a new UCC, then there are an infinite number of very large finite numbers which never enter a loop. Of course, that’s a lot of if’s; the [testitem] conjecture is still quite possibly true.

[dvgrn]

Of course, that’s a lot of if’s; the [testitem] conjecture is still quite possibly true.

The trickery I was referring to is much simpler.

Find a number that builds a pattern that doesn't have a finite lifespan. Then the sequence ends, technically without going into a loop, just because there's no way to choose a number to continue. Any finite number will be smaller than the actual lifespan, and infinitely long numbers can be chosen that have any sufficiently large lifespan you might want.

For example, a doubly infinite string of 7's never settles down, though arguably it does become boring very quickly, at T=7:

Code: Select all

x = 99, y = 5, rule = B3/S23:T100,0
3ob3ob3ob3ob3ob3ob3ob3ob3ob3ob3ob3ob3ob3ob3ob3ob3ob3ob3ob3ob3ob3ob3ob
3ob3o$2bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo
3bo3bo3bo3bo$2bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo
3bo3bo3bo3bo3bo3bo$2bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo
3bo3bo3bo3bo3bo3bo3bo3bo$2bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo
3bo3bo3bo3bo3bo3bo3bo3bo3bo3bo!

Not sure about a string of 7's that's finite on the left and unbounded on the right. I think there's a point where it becomes predictable, but it's a little hard to pick out a precise lifespan. But seed a singly infinite string of 7s with, I don't know, increasingly long subsets of the digits of pi or something, and it's clear that there's no single well-defined value that could continue the sequence after an infinite-lifespan pattern.

Anyway, I do realize this is something of a wild tangent, but it seems like patterns without a finite lifespan would need to be specifically accounted for in the conjecture somehow, before it could possibly be true.

Long before we run into any UC-based cases, there will be infinite-growth cases showing up -- numbers that make switch engines. I'm assuming that the lifespan for these would be the first tick after the last spark dies that isn't switch-engine-related and predictable? Not sure exactly how to define that clearly.

Catagolue/apgmera just throws methuselahs like this away, so I don't think there's any existing code that could be borrowed to automatically find the exact lifespan of an infinite-growth pattern. Also, even for normal methuselahs, apgmera is susceptible to slight underestimates: it only finds the point where the population goes permanently periodic. The methuselah fingerprinter script has a similar weakness -- it finds the point where the population change goes periodic.

[dvgrn]

With a particular amount of patience, you could even design such a number so that the number of generations the number lasts also forms a UC mechanism. Perhaps you could even string an arbitrary number of them together. But that arbitrary number would still be finite...

Here again, the way that small numbers tend to behave -- with lifespans that on average are much smaller than the numbers they represent -- really doesn't give any information at all about the way certain absolutely ridiculously large numbers might turn out to behave.

We could actually re-use the same UC design indefinitely to produce a non-looping sequence. The UC will have to know the length of the number that built it, but that's easy -- just have the very beginning and the very end of the number build blocks or something at those extremities, and then include a structure in the UC that measures the distance between those blocks.

The UC can be arranged to deduce exactly how long it has been since T=0, and it can be programmed to calculate a number that's safely longer than the distance between the two marker blocks -- just add 7's toward the end of the digit string that it calculates, let's say, to make a new digit string that would place those blocks farther apart. The digit string could otherwise be identical for every UC in the sequence.

The UC then waits around for a truly mind-bending number of ticks, before triggering a self-destruct sequence that ends its lifespan at precisely the calculated number. It doesn't even have to self-destruct completely, it can just run the last signal glider into an eater and go dormant.

Even if there are flaws in this particular design, I'm fairly sure that it will be possible to patch them up somehow, so that the conjecture in its current form is definitely false.

[Moosey]

So there a two conjectures:
The testitemqlstudop conjecture states that all numbers will eventually enter a loop.
The Moosey conjecture states that the testitemqlstudop conjecture is true for the vast majority of numbers, but there should be a tiny fraction of all numbers (but still an infinite amount) which lead to ever-larger numbers and thus never reach a loop.
Any others?

[testitemqlstudop]

I strongly believe in the Testitem Conjecture. I think it is rather unfeasible to construct a glider synthesis of a distorted Gemini puffer by removing some of the gliders programming its destruction and also shifting the second Gemini to be a little off (but anyways, voila, a PRNG)!

However, there's another possibility: Once X passes an upper bound B (maybe B < BB(BB(6))? Who knows?) every starting value X goes on forever. I strongly doubt this, though.

Some good news: A messy C++ program to automate sequence generation.

Some bad news: apgluxe had a bug and it says "78" lasts 31 gens instead of 32. So don;t use


Use my apgerator program. Tested for Linux, ask me if you have questions (Put MY apgluxe COMPILED WITH "--symmetry stdin" in the same folder!)

Code: Select all

#include <iostream>
#include <fstream>
#include <vector>
#include <string>
#include <sstream>
#define COMMAND "rm -f lspan.txt && cat RLE.out | ./apgluxe -L 0 -n 1 -t 1 > /dev/null 2> lspan.txt"
using namespace std;

string HEADER = "x = 0, y = 0, rule = B3/S23\n";

string LETTERS[10][5] = {
    {"ooo","obo","obo","obo","ooo"},
    {"oob","bob","bob","bob","ooo"},
    {"ooo","bbo","ooo","obb","ooo"},
    {"ooo","bbo","ooo","bbo","ooo"},
    {"obo","obo","ooo","bbo","bbo"},
    {"ooo","obb","ooo","bbo","ooo"},
    {"ooo","obb","ooo","obo","ooo"},
    {"ooo","bbo","bbo","bbo","bbo"},
    {"ooo","obo","ooo","obo","ooo"},
    {"ooo","obo","ooo","bbo","ooo"}};

string assembleRLE(string num)
{
    // first row
    string answer = HEADER;
    for(int i=0; i<5; i++)
    {
        for(char x:num)
            answer += (LETTERS[x-'0'][i]+'b');
        if(i == 4)
            answer += "!\n";
        else
            answer += "$\n";
    }
    return answer;
}

string runApgerator(string RLE)
{
    ofstream outf("RLE.out");
    outf << RLE << endl;
    outf.close();
    int EXITSIG = system(COMMAND);
    if(EXITSIG != 0)
    {
        cerr << "Oopsie woopsie apgluxie did a fucksie wucksie" << endl;
        exit(-1);
    }
    ifstream inf("lspan.txt");
    string output;
    getline(inf, output);
    getline(inf, output);
    return output;
}

uint64_t s2l(string n)
{
    std::istringstream ss(n);
    uint64_t ans;
    ss >> ans;
    return ans;
}

bool tested[1000000];

int main()
{
    string n; cin >> n;
    while(!tested[s2l(n)])
    {
        cout << n << " ";
        uint64_t decimal = s2l(n);
        if(decimal >= 1000000)
        {
            cerr << endl;
            cerr << "Last sequence element grew greater than 1 million!" << endl;
            exit(-1);
        }
        tested[decimal] = true;
        n = runApgerator(assembleRLE(n));
    }
    cout << n;
}

[testitemqlstudop]

heyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyyy