Talk:Fusion Tag

Initialization

It seems to me that if you can manage to create at least one sufficiently large number to jump to, you can put the rest of the initialization near the end of the program, with no need for compression in that part. My first three attempts at writing programs haven't got past the first ^, though. --Ørjan (talk) 00:48, 8 July 2018 (UTC)

I attempted to check all cases with 1 (trivial) or 2 (below) zeros before the first ^, and none of them managed to pass it:

0. .0+{a}0+{b}^

a>0:

1. 0+{a}0+{b}.^    a b
2. 0+{a}0+{b}.^    b+1 b

a>0, b<=a:

3. 0+{a}0+{b}.^    a b (loop)

a>0, b>=a+1:

3. 0+{a}0+{b}.^    a+b+1 (crashes if b>0)
4. 0+{a}0.^        0 (loops)

a==0:

1. 00+{b}.^    0 b
2. 00+{b}.^    b 0 b (growing loop if b==0)

a==0, b==1:

3. 00+.^       0 1 1
4. 00+.^       1 1 0 1 (0 -> 0 1, 1 -> 1, growing loop)

a==0, b>=2:

3. 00+{b}.^    0 b+2
4. 00+{b}.^    b+2 0 b
5. 00+{b}.^    0 b (loop)

--Ørjan (talk) 03:49, 8 July 2018 (UTC)

Checking the most intuitive option for three zeros, it seems to get past a bit, about 25%:

a>=1, b>=a+2, c>=a+b+3

Program length a+b+c+4

0. .0+{a}0+{b}0+{c}^
1. 0+{a}0+{b}0+{c}.^   a b c
2. 0+{a}0+{b}0+{c}.^   b c+1 b c
3. 0+{a}0+{b}0+{c}.^   c+1 b a+c+2 c
4. 0+{a}0+{b}0+{c}.^   b a+c+2 a+b+c+2
5. 0+{a}0+{b}0+{c}.^   a+c+2 2*a+b+c+4 c
5. 0+{a}0+{b}0+{c}.^   2*a+b+c+4 b+c+1

That would allow a structure like

0+{a}0+{a+2}0+{2*a+5}^<main><initialization>

where <main> only has length a and starts at offset 4*a+11, but <initialization> can be as long as you want.

--Ørjan (talk) 06:51, 9 July 2018 (UTC)

Hmm, this could still cause difficulties. The programming techniques I've been working on rely on being able to hit a long string of +++…++^ at a relatively small offset (in order to compress the tag entries), but that doesn't exist early enough in the "bootstrap section" to be able to fit even a single reference to it into the "main" section. (In fact, the "main" section here is fairly useless because nothing but references to the bootstrap section fit in it.) So I think what you might have to do instead is to put some sort of decompression routine into the initialization section, then put the main section to the right of that. --ais523 19:48, 9 July 2018 (UTC)

Well the main point of this was to show that you can get past the first ^ in the program at all, which wasn't obvious to me for a while. Without that there would be no hope of getting a decompression routine running. I realized the main section was awkwardly small, but I was sort of hoping you had an idea for how to use it.

I haven't thought up any other good ideas for the next step. This jumping method depends on having the c section be longer than its starting offset, so I'm not sure how to fit a long +++…++^ at a point where it can be referred to much more succinctly, but such that you can still manage to jump past it to get to initialization. --Ørjan (talk) 08:47, 10 July 2018 (UTC)

I think I've figured it out: have a and b as small as possible (1 and 3 respectively), and c very large. The code will end up jumping to just after the bootstrap section. Then manually push a lot of a+b+3 (i.e. 7, using 0+++++++) onto the queue (which will aim for the first + in the definition of c, and finish with a ^. When the 7s end up cycling round to the front of the queue, they'll end up all adding to the same stack element, creating a very large number (much larger than the amount of code you used here, as c is much larger than 7). Then you put the actual initialisation code there, and have enough space as you want in between for the main program (plus a fairly simple way to do decompression.) It'd only be easily possible to use tape elements close to (a bit less than) multiples of c, but that hardly matters; you can just "space out" your program more to compensate. --ais523 18:15, 10 July 2018 (UTC)

Hah, edit conflict, I was writing up essentially the same idea as your first half there. I definitely think this is TC now. --Ørjan (talk) 18:38, 10 July 2018 (UTC)