User:Salpynx/Phoney Burn 01

From Esolang
Jump to navigation Jump to search

Phoney Burn is a disposable cellular esolang designed to meet the requirements of the Burn reverse engineering challenge.

It devolved out of a serious attempt. Given there is quite a bit of data in the mystery program, there will be more than one way to construct languages that implement Rule 110 using that source, and can be generalised to implement other 1D automata. This takes a minimalist and deliberately over-literal interpretation of the reverse engineering challenge, with tongue firmly in cheek to quickly bash out something that (mostly) works.

Relationship to Burn

I'm confident this is NOT how original Burn worked. Burn looks to be itself a 2D cellular automaton, which can be used to implement 1D CAs. Phoney Burn is not a proper 2D automaton, merely a highly contrived grid based sequential data processor which can be used to implement arbitrary cellular automata (1D elementary CAs at least, up to four states, and maybe extensible to 2D). In the case of the example code, it is a highly contrived rule 110 implementation which uses the required infinite tiling of the rule 110 Turing completeness proof, which is obtained via a most unlikely encoding scheme. I don't know if the Burn Rule 110 program was meant to be a TC proof with the required infinite tiling -- my guess is not, but rather that it was a proof-of-concept to show that a universal 1D CA could be constructed in Burn. I could be wrong, but the easiest way to check would be to ask Burn's creator. Since Phoney Burn was deliberately a creative exercise, it seemed appropriate to choose a significant tiling and force the "data" to decode to that.

It's possible that some of this is unintentionally close to accurate, but it was created as an experiment to show that discovering one of the many possible languages that interpret this code as a Rule 110 implementation is easier than reverse-engineering a specific original one.

Phoney Burn walkthrough

Line 1

 00 00 01 00 00 00

The header. 01 indicates a 1D automaton.

Line 2

 10 11 01 01 01 11

Definition of our 1D automaton.

Reading right-to-left from the EOL marker 11:

01 indicates the maximum state value a cell can have (1-3)

Subsequent digit pairs show next values of cells surrounded by 00, 01, 10, 11, sequentially for each state from 0 to max state

 ((0(0)0 => 0) (0(0)1 => 1), (1(0)0 => 0) (1(0)1 => 1) for '0' cells = '01 01'
 ((0(1)0 => 1) (0(1)1 => 1), (1(1)0 => 1) (1(1)1 => 0) for '1' cells = '11 10'

Combining these RTL gives 10 11 01 01, which is the values from the code example. The above rules are those of Rule 110.

Lines 3-5

 03 20 11 00 00 11
 00 00 11 11 11 11
 00 00 00 00 00 11

Defines a variable 03 using mode 20 to be used for tiling.

Mode 20 is an unusual encoding method where the doubled 00 and 11 represent the inverse single value, so

  • 00 => 1
  • 11 => 0

The final 11 in each row is an EOL marker, and not counted as data.

This encoding has the additional peculiarity that, because the data is storing sequential runs of bits, if the next row starts with the same data symbol as the previous data row ended with, it is double-inverted, and a single padding separator bit is added.

  • 11 00 00 encodes 011
  • 00 00 11 11 11 starts with 00, which ended the previous row, so 00 00 here encodes 001, and 11 11 11 encodes 000
  • 00 00 00 00 00 encodes 11111

Combined, variable 03 = 01100100011111, which is a reversed (and offset) version of one generation of the infinite 14 cell tiling required for the Rule 110 TC proof.

Line 6

 10 10 10 10 10 11

Playfield separator.

Line 7

  00 00 10 00 00 12

Core part of our playfield definition.

Line 8

  00 02 11 00 00 11

Merge the previous row with the 02 rows following the 11 program terminator. The program grid is modified so that this row becomes the result of the merged rows. (I stopped trying so hard at this point, there are multiple ways these rows could be combined.)

Line 9

  11 11 11 11 11 11

Program terminator. When encountered, the configuration is complete and the CA will run according to the previously defined rules.

Lines 10-11

 00 00 30 00 00 21
 00 00 01 01 01 01

Two data rows to be merged.

The row ending in 21 is inverse-associated with the previous row ending in 12 as a substitution rule, to replace the 00 00s of the first row with the reversed data stored in 30 -> 03, which gives: 11111000100110, now the 14 cell tiling required for Rule 110 universality (offset by 9 from what is given at wikipedia:Rule_110#Spaceships_in_Rule_110). The cells are to be tiled infinitely to the left and the right as signified by the 12 21 notation.

The final row (minus the final pair 01, in line with the other rows which also have terminating indicators, 01 => 10) is used to replace the 10 as the starting configuration for the CA to give a starting configuration of:

 (11111000100110)*00111(11111000100110)*

Upon reaching the 11 11 11 11 11 11 final terminator row, the CA rules are triggered repeatedly on the previously assembled data row.

This results in a single example of the stable vertical repeating (7 step) structure which is used in the Rule 110 Cyclic Tag System implementation for data strings, which seems like a reasonable simple yet important structure to encode.

Phoney Burn Rule 110 Output (data row only)