Burnlike
Burnlike is a 2D cellular automaton by user:Truttle1, based on Burn by user:ais523, made with the goal of interpreting the example program given in as similar of a way to how it was originally interpreted as possible. A program in Burnlike is represented as a grid of cells containing 1 to 3 colors each in their own separate channel.
Neighbor Difference
The Neighbor Difference is the difference between a color channel in a cell and its Von Neumann (orthogonal) neighbors. Given the example 2 channel Burn program:
33 10 00 11 21 01 00 00 00
The Neighbor Difference for 21 is 01: The neighbors in the left cell sum to 2 and the center is 2, so 2-2=0. For the right cell, the neighbors sum to 2 and the center is 1, so 2-1=1. The 33 cell does not have an effect because the neighborhood only consists of the orthogonal cells.
Neighbor Difference Change
When messing around with rules pertaining to the Neighbor Difference, I found that it was almost impossible to create a rule that led to flood fill style events as described on the Burn wiki page. As stated by User:Salpynx/Burn, if the program tiles as described in the wiki, it is likely that each code patch represents a single rule110 cell. If that were the case, then if the given code patch is left on its own, it would not change at all.
As a result, Burnlike instead bases its rules on the Neighbor Difference Change between the current generation and the previous generation.
Consider:
02 02 02 02 02 02 02 02 02
If the middle cell were changed to 01, in generation 0, the Neighbor Difference Change in generation 1 would be
00 01 00 01 01 01 00 01 00
since, between generations 0 and 1, the Neighbor Difference changed by 1 in all of those channels.
Ruleset
Now that the Neighbor Difference Change is defined, the ruleset for Burnlike is as follows:
For each generation:
- If the Neighbor Difference Change of a channel is 1, decrement the channel by 1. If that causes it to go below the lowest value of its neighbors, set it to the lowest value of its neighbors.
- If the Neighbor Difference Change of a channel is 2, decrement all channels of the cell by 2. If that causes it to go below the lowest value of its neighbors, set it to the lowest value of its neighbors.
- If the cell directly above a cell contains a 3 in any of its cells, no decrements take effect.
This ruleset causes desired flood fill effect between activated wires, it treats Difference Changes of ±1 differently from ±2, and it has a rule that can change adjacent cells, rather than just the cell corresponding to the Difference Change. Furthermore, it is symmetric between colors, provides support for a hypothetical third color, and ensures that cells never return to their original value since channels only decrease.
Rule 110
Consider the original example program:
00 00 01 00 00 00 10 11 01 01 01 11 03 20 11 00 00 11 00 00 11 11 11 11 00 00 00 00 00 11 10 10 10 10 10 11 00 00 10 00 00 12 00 02 11 00 00 11 11 11 11 11 11 11 00 00 30 00 00 21 00 00 01 01 01 01
When the cell at coordinate (0, 2) is set to 00 on generation 1, "slightly disrupting" the original state, the difference change of the cell at (1, 2) is suddenly 01, beginning the "burning" process. If a code patch's activity starts by burning (0, 2), it is considered to be a 1 in this rule110 interpreter.
The signal is then passed to the code patch on the left via the 03 20 box, and it is then passed down towards the 12 From the left code patch's perspective, it has received signal from the upper right. From the center code patch's perspective, it is passing the signal it received from directly above. If signal reaches 12 and passes to 21, then that satisfies the boolean
(c | r)
Which is one clause of Rule 110 as described by Salpynx.
If the code patch directly above, above and to the left, and above and to the right all pass down a signal, then the 30 does not burn out, and this occurs just as the burning from 21 reaches that location. 30 only burns out if !(l & c & r). Therefore, the code patch only passes down signal to the next one if
(c | r) & !(l & c & r)
Which is rule110.
This is quite difficult to understand without actually seeing it, so refer to the animated GIF running the Rule 110 interpreter 01110.
As a consequence of the flood fill effect, the row is almost completely destroyed shortly after computing an iteration. When a code patch receives signal from above, however, the cells left behind always form one of four patterns. Similarly, if a code patch doesn't receive this signal, it never ends in one of those four patterns.
After running this program for a while, and highlighting instances of those four patterns in yellow, Rule 110 visibly appears.
Thoughts
Based on ais523's replies on the Burn discussion page, it is likely that Burnlike is not actually Burn, but a similar cellular automaton where this Rule 110 program is a polyglot between Burnlike and Burn.