Talk:Burn
Notes
Some other notes I remembered that may help people reconstruct the language:
- Upon loading the program, it's used to tile an entire infinite plane (possibly disrupted slightly; I can't remember); the program was the initial state for a certain algorithm for updating cells (making it a cellular automaton).
- Cell updates were irreversible; if a cell were ever changed, it was never changed back to its original value (although it might be changed again).
Unfortunately, that's not much to go on. --ais523 20:26, 16 December 2010 (UTC)
Random Observations and Guesses
The frequency of each group of numbers is as follows, from most common to least common:
00 - 27 times
11 - 18 Times
01 - 8 Times
10 - 7 Times
02 - 1 Time
12 - 1 Time
20 - 1 Time
21 - 1 Time
03 - 1 Time
30 - 1 Time
Some other general observations:
- In ais523's note above, they mention "tiling an entire infinite plane." This leads me to believe that an infinite 2D array is created at some point, with each cell having a default value. Some of them possibly have different values than others (disrupted slightly.)
- The only characters that appear in Burn are 0, 1, 2, and 3. It is safe to assume that those characters are the only valid ones in Burn.
- The esolang has something to do with color, or it has the ability to print output in color.
- Comments start with a semicolon.
- Each line of the automation is probably printed after it is computed, since rule 110 works in a line-by-line fashion, and this interpreter contains an infinite playing field. Since the line is apparently infinite, though, I have no clue when it would decide to stop printing a line.
--Truttle1 (talk) 04:38, 3 April 2019 (UTC)
every line includes a 1. based on that i think that maybe burn is written so if i want to write 1000 i would need to write: 10 00 so even though numbers maybe are seperate they are written in that format anyways. maybe burn uses a base 3 number system? also maybe a spesific number represents a on and not on cell?
this may be usefull? it seems that maybe it has some kind of path on each number. 2 and 3 is always alone for some reasone
no op|no op|je|no op|no op|no op test_attr|set_attr|je|je|je|set_attr jg|add|set_attr|no op|no op|set_attr no op|no op|set_attr|set_attr|set_attr|set_attr no op|no op|no op|no op|no op|set_attr test_attr|test_attr|test_attr|test_attr|test_attr|set_attr no op|no op|test_attr|no op|no op|get_prop_addr no op|jl|set_attr|no op|no op|set_attr set_attr|set_attr|set_attr|set_attr|set_attr|sat_attr no op|no op|mem addr|no op|no op|sub no op|no op|je|je|je|je
--Yayimhere (talk) 18:54, 27 april 2024 (UTC)
One-eyed representations
So first let's make up some terms. The source code is a grid, 6 by 11 cells in size. There're two numbers in any cell. Let's call the left number "left-eyed" and the right one "right-eyed". So now, instead of one grid with two sized cells, we can have two grids with one sized cell.
| Representation | Left-eye view | Right-eye view |
|---|---|---|
| Raw | 0 0 0 0 0 0 1 1 0 0 0 1 0 2 1 0 0 1 0 0 1 1 1 1 0 0 0 0 0 1 1 1 1 1 1 1 0 0 1 0 0 1 0 0 1 0 0 1 1 1 1 1 1 1 0 0 3 0 0 2 0 0 0 0 0 0 |
0 0 1 0 0 0 0 1 1 1 1 1 3 0 1 0 0 1 0 0 1 1 1 1 0 0 0 0 0 1 0 0 0 0 0 1 0 0 0 0 0 2 0 2 1 0 0 1 1 1 1 1 1 1 0 0 0 0 0 1 0 0 1 1 1 1 |
| Scheme | ;
─┐ │;
┗┐ │;
└──┤;
│;
──┬──┤;
│ │;
│ │;
──┴──┤;
3 ┃;
; |
│ ;
─┼──┐;
3 │ │;
└──┤;
│;
│;
┃;
┏┐ │;
─┴┴──┤;
│;
────┘;
|
In the schemes:
- 0 is represented by a whitespace.
- 1 is represented by a thin line.
- 2 is represented by a thick line.
- 3 is represented by a three.
-- Dart (talk) 18:18, 5 December 2019 (UTC)
Given the top comment in the program, I've been assuming that what you call "left" and "right" is really "blue" and "green", and that other potential programs might possibly have a different set of colors. --Ørjan (talk) 03:00, 6 December 2019 (UTC)
- If other programs might have different colours, that must mean somewhere in the code Blue and Green should be defined first. But it can't be in the grid because "the program is the initial state". So this brings up the possibilities that the comment is not actually a comment, colours are dynamic and can be changed by some pattern occurring, or simply that all programs have the same colours. -- Dart (talk) 09:18, 6 December 2019 (UTC)
The program could start with a grid and communicate with the other one to build the interpeter. --(this comment by Hex96 at 13:46, 7 December 2019 UTC; please sign your comments with ~~~~)
Colours
I'm taking a creative guess that given the language name Burn, the colours BG = Blue Green (not Black Grey), are to be represented with the Red channel fully set, to give a fire-like visualisation as the cells switch states.
From experimenting with 12bit colour values, r = 0xF, g = 3G + 6, b = 3B + 4 gives nice distinguishable colour variants for the cells. Putting them in a table reveals that only some combinations are used in the example code, and the core 4 substantially more than those on the diagonal (using the frequency count above). -- Salpynx (talk) 05:42, 9 December 2019 (UTC)
| 00 | 01 | 02 | 03 |
| 10 | 11 | 12 | |
| 20 | 21 | ||
| 30 |
a tape
IF this is a Turing tarpit i would suspect that the 8’th row is some sort of tape like thing. I suspect this because of the fact that there are only one kind of symbol there which could be the base symbol and/or number on the tape. Since its a CA this may not make sense --Gggfr (talk) 07:23, 21 July 2024 (UTC)
Reverse engineering attempts
I'm going to take a guess, but even if I'm right it won't be exact yet. I'll use the notation (row, column) where row and column are indices starting at zero for the instruction pointer. It has a stack, a direction pointer similar to piet, and data pointer similar to brainfuck where each address in memory can store one bit. The program starts at (0, 3) and each iteration goes one pixel in the direction currently held in the direction pointer, I'm assuming it's initialized to down. If the color changes, it will do an operation depending on the new color. Black (notated 00) is a special color. If the instruction pointer is about to enter a black pixel, it doesn't change the instruction pointer and instead changes the direction pointer. In this case:
Going into this instruction VV 00 01 00 00 01 01 00 00 00
The direction pointer will be set to right. In this case:
00 00 00 00 01 01 < Going into this instruction 00 01 00
The direction pointer will be set to down. If there are two directions the direction pointer can be set to, it will pop a value from the stack, and the direction pointer will be set accordingly. In this case:
Going into 00 01 00
this instruction > 01 01 00
00 01 00
If it pops a zero, the DP will be set to up. Otherwise, it will be set to down.
Here is a table of the color I think I've figured out so far.
01 = NOP 11 = PUSH 02 = POP 10 = Pop a value x and push (not x) 30 = Duplicate the top of the stack
With this table, the example program sets address 0x0000 to 1 and exits the top half of the program. Hope this helps. --aithecomputerguy --(this comment by aithecomputerguy at 17:48, 7 June 2014 UTC; please sign your comments with ~~~~)
- FWIW, I think this guess is inconsistent with the additional information ais523 gave above. --Ørjan (talk) 11:32, 2 December 2014 (UTC)
There is not a ‘23’, what would that do? --(this comment by Hex96 at 18:20, 5 December 2019 UTC; please sign your comments with ~~~~)
I think I got the main parts down
I think the first line adds a square or whatever to the top, the next 4 lines are if then statements, the next two is the else statement and the last 3 are the looping and changing the selected cell to all 3 created at the same time. That’s what I think is what is happening with the program. --(this comment by Hex96 at 16:16, 4 December 2019 UTC; please sign your comments with ~~~~)
- I doubt it. This language is a cellular automaton, so it's highly unlikely that it has traditional
if ... then ... elseflow control sequences. And structures in the script don't seem 1D enough to allow something like that anyway. -- Dart (talk) 09:05, 5 December 2019 (UTC)
- K thanks, I should have guessed that. I'm stupid, it's an esolang, not python on steroids --(this comment by Hex96 at 15:29, 5 December 2019 UTC; please sign your comments with ~~~~)
Attempted programs
Hello, world
I think that a hello world program would be like this
00 01 02 03 04 05 06 07 08 09 10 11 setting up variables 80 80 80 80 80 80 80 80 80 80 80 80 saying that they are ascii values 72 101 108 108 111 44 32 119 111 114 108 100 the ascii values 40 40 40 40 40 40 40 40 40 40 40 40 prints the var underneath 00 01 02 03 04 05 06 07 08 09 10 11 the var underneath
I realised this would probably be wrong because as said by Trutle1 it is safe to assume that the only valid syntax is 0, 1, 2 and 3. --(this comment by Hex96 at 18:58, 4 December 2019 UTC; please sign your comments with ~~~~)
if you could create any text through the program, that would be cool. --(this comment by Hex96 at 10:11, 6 December 2019 UTC; please sign your comments with ~~~~)
Phoney Burn
Here's my not-very-serious attempt to create an interpretation for this code as a Rule 110 implementation: User:Salpynx/Phoney_Burn_01. It's more of a generic 1D automaton encoding than the 2D automaton I think Burn probably is, but it was an interesting exercise. Maybe it'll spark some ideas for more serious reverse engineering, or other creative solutions. -- Salpynx (talk) 10:08, 9 December 2019 (UTC)
a slightly more serious attempt
burn may have a not feature. If that is true then my guess is this:
The first line will start a nested loop.
the second and third and forth line and so on will do nots and loops to decide the cells value.
the next line will make that cell appear. The final line end the nested loops.
this program could do a rule 110 interpreter but slightly different:
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 00 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
Original:
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
--(this comment by Hex96 at 19:15, 9 January 2020 UTC; please sign your comments with ~~~~)
also 21 may print the top value on the stack as ascii.
--(this comment by Hex96 at 18:24, 13 January 2020 UTC; please sign your comments with ~~~~)
PNG of the program
Here's a PNG of what the program might look like. To me, it sort of looks like there's a path of 11's at the right, a short path of 01's at the bottom, another short path of 10's, and the 00's are empty spaces. Wonder what the odd ones out are doing there. --Quadril-Is (talk) 06:38, 13 December 2019 (UTC)
comment: i think it kinda looks like a maze. maybe the purple things are like doors with keys of some sort? and the yellow things are keys. idk im using video game logic to solve it so. idk --Yayimhere (talk) 18:54, 27 april 2024 (UTC)
not sure if this helps
hey not sure if this helps, but if you take the Rule 110 program, remove all the spaces and newlines, convert that from base-4 to base-2 (base-2 is binary), then put it through a binary to text translator you get this:
�(©Â(�ª¨*""(�0�*ªª¨�H
Again, not sure if this helps. --Yes (talk) 18:19, 16 July 2022 (UTC) comment: looks like hexcode to me. i converted it:
80 FFFD 28 88 A9 C2 80 28 FFFD AA A8 2A 22 22 28 FFFD 30 FFFD 80 2A AA AA A8 FFFD 48 88.
it looks like some memory stuff and that converts to:
ÿý(©Â(ÿýª¨*""(ÿý0ÿý*ªª¨ÿýH
and the hex from before has now become machine code(kinda) using opcodes:
or no_op|loadw loadw loadw loadw store|jl or|or or|test_attr and|clear_attr jl|or no_op|jl or|loadw loadw loadw loadw store|test_attr test_attr|test_attr or|jl test_attr|jl jl|jl jl|jl or|loadw loadw loadw loadw store|jg no_op|loadw loadw loadw loadw store|or no_op|jl test_attr|test_attr test_attr|test_attr test_attr|test_attr or|loadw loadw loadw loadw store|dec_chk or|or or|
it seems to load a lot from memory and use if statements a lot. like jl and jg --Yayimhere (talk) 18:54, 27 april 2024 (UTC)
Reverse Engineering of an Interpreter
I was considering the possibility of recreating an interpreter that is specifically designed to where it will make the code Burn uses, make the desired result, as it could help reverse engineer, and could maybe help User:Ais523 remember more of how it functioned, however a rule 110 interpreter seems very complex, and I'm not sure in that case what exactly the language would be doing in order to get the result of a rule 110 interpreter. Some info is scattered around here, and where ais523 was able to remember anything, so I think this is possible, I might need to better understand the concept of the language first. --SpaceByte (talk) 18:12, 17 January 2023 (UTC)
base4-base2-text-hexadecimal NCR
€ � ( ˆ © Â € ( � ª ¨ * " " ( � 0 � € * ª ª ¨ � H ˆ
i think this dosent help at all --(this comment by Tesolang at 12:14, 9 March 2023 UTC; please sign your comments with ~~~~)
base4-base2-text-octal
heres the octal version
200 177775 50 210 251 302 200 50 177775 252 250 52 42 42 50 177775 60 177775 200 52 252 252 250 177775 110 210
--(this comment by Tesolang at 12:16, 9 March 2023 UTC; please sign your comments with ~~~~)
my thought
I think Burn uses WireWorld-style wires? --(this comment by Xyzzy at 10:00, 18 July 2023 UTC; please sign your comments with ~~~~) I think so too --Gggfr (talk) 06:42, 20 July 2024 (UTC)
Some ideas
Here are the assumptions I'm making:
- Only orthogonally adjacent cells can affect a specific cell.
- The "color channels can only ever decrease" memory is correct. Assuming the
01's,10's, and11's are wires, this could mean that signals travel through them by burning the 1's:
01 01 01 00 becomes 01 01 00 00 becomes 01 00 00 00
(Particularly, 11's can burn in either one channel or in both:)
11 11 11 01 becomes 11 11 01 01 11 11 11 10 becomes 11 11 10 10
- The initial infinite tiling is disrupted in exactly one "tile" of the program, and if the infinite tiling was not disrupted, all cells would stay the same.
- One row of tiles corresponds to one generation of rule 110, the next row corresponds to the next generation, etc.
- (This assumption is less important) The red channel in the rule 110 program is 0 for all cells, it's just not listed because it's not used. The left number is the blue channel, and the right number is the green channel.
Given that, the only way a signal can travel from a "tile" of the program to the "tile" below is through a green wire, so the next generation would have to be calculated in the row above and then transferred to the row below.
Looking at this specific portion of the program:
30 00 00 21 01 01 01 01 01 00 00 00
I'd guess that the 30 stops the green wire from burning, like so:
30 01 01 01 01 00 becomes 30 01 01 01 00 00 becomes 30 01 01 00 00 00 becomes 30 01 01 00 00 00 (no burning)
This means that for the "tile" below to receive a burn from the "tile" above, the 30 has to be modified somehow, most likely to 00 or 20, along with a green signal being sent through the 21.
If signals are transferred through burning, though, I'm not exactly sure how the burning rule works, due to this:
01 <- signal from above sent through here 11 01 01 11
The simplest burning rule would be something like (assuming only wires exist) if at most one neighbor has a wire of the same channel, the cell becomes empty. However, even if the signal from above is burned, there are still three more green wires to support. The burning rule could be about parity, so if there's only one or three wires, the cell becomes empty, and for zero, two, or four, the cell stays, but I'm not entirely sure.
Something I'm less sure of is that 2 cells may act as "filters" of some sort, meaning that for example here:
11 11 21 01
If only green is burning, the "filter" blocks it:
10 11 21 01 becomes 10 10 21 01 becomes 10 10 21 (no burning) 01
But if both blue and green are burning:
00 11 21 01 becomes 00 00 21 01 becomes 00 00 00 01 becomes 00 00 00 00
That's all I've thought of for now. I haven't actually tried burning a wire and seeing where it goes yet, which may be something I should do. --PkmnQ (talk) 11:18, 20 July 2024 (UTC)
- Rechecking this after a bit, and I thought the
11wire worked differently, but no, all of them are supported by a01and10if there is no other11. --PkmnQ (talk) 13:26, 20 July 2024 (UTC)
I may want to recheck this with User:Salpynx/Burn in mind later. If nothing else, this at least gives some explanation on why boolean types are not sufficient. --PkmnQ (talk) 12:52, 2 August 2024 (UTC)
Likely b1
- After a bit more thinking, I think I know what b1 might be. I think that
20"converts" a green-channel signal into a double-channel signal somehow, for example:
00 00 00 00 01 -> 00 00 00 11 20 -> 11 20 -> 00 20 -> 00 ?? (can't rule out something happening to the 20) 11 11 11 00
- Given that, here's what I assume for b1:
Neither burning:
01 01
01 01 01 11 10 11 01
20 11 11 20
11 11 11 11
11
(nothing happens, both channels remain)
Left burning:
00 01
01 01 01 11 10 11 01
20 11 11 20
11 11 11 11
11
(7 generations later)
00 01
00 00 00 10 10 11 01
20 00 10 20
00 00 00 10
10
(blue channel remains)
Right burning:
01 00
01 01 01 11 10 11 01
20 11 11 20
11 11 11 11
11
(5 generations later)
01 00
01 01 01 01 00 00 00
20 11 01 20
11 11 11 11
11
(both channels remain)
Both burning:
00 00
01 01 01 11 10 11 01
20 11 11 20
11 11 11 11
11
(7 generations later)
00 00
00 00 00 00 00 00 00
20 00 00 20
00 00 00 00
00
(neither channel remains)
- More specifically, here's what I assume for b1 (and b2, since the assumptions I'm making for this behavior of b1 also requires b2 to be something specific):
b1 = lambda a, b: (a, a and b) # This is (green, blue), not (blue, green) b2 = lambda a, b: a[1] and b[1] # D = b2(b1(L, C), b1(C, R)) = b2((L, L and C), (C, C and R)) = (L and C) and (C and R) = L and C and R
- One important point is that this would have to technically be an implementation of Rule 124 (the horizontally flipped equivalent of Rule 110) since there's no way to distinguish between x00 and x01, which Rule 110 requires but Rule 124 does not. If I were to guess t1 and b3, this is the first thing I see:
t1 = lambda a, b, c: (a[0] or c[0]) and not b b3 = lambda a, b: a # ???
- I'm very suspicious of b3 in that interpretation, though, so I doubt it's correct. -PkmnQ (talk) 10:03, 8 September 2024 (UTC)
- I think that
20"converts" a green-channel signal into a double-channel signal somehow, for example: – this jogged my memory a little; if I remember correctly, and I might well not remember correctly after this long, it isn't specifically the20that does a conversion but the combination of the20and11(although I don't remember whether it does the conversion you mentioned or some other conversion). But I can't remember why (although it would be related to the relative values of the color channels, not something that's specific to 2 or to 20). I have also become very uncertain about whether the burning decreases or increases the numbers; it might be worth trying the reasoning in both directions to see if one makes more sense than the other. --ais523 22:16, 8 September 2024 (UTC)
- I think that
Better Burn
i improved your language Better Burn and your welcome! :D tommyaweosme 01:11, 6 August 2024 (UTC)
- Your language is unrelated to mine, except in that it uses superficially similar syntax to the example program. --ais523 01:15, 6 August 2024 (UTC)
Mentioning 2 things.
We have nothing
At the beginning of the page, there's a disclaimer mentioning the page is too short, as if we can add to it based off of ALL THAT NOTHING we have.
The name is perfect
Seriously though, why is the language named "Burn" the same language where the information got *Burned* to the ground... get it?
UHH
why didnt you just write it down before forgetting, what KIND of language was this maybe
- wait fuck you actually have a pointUser:Gaham (Discord:belarusianflag)
wait
oh it says stub, add more, with all the nothing we have
A ruleset that interprets Rule 110 given the example program
A couple weeks ago I remembered that Burn exists and saw that ais523 added a few additional hints. I thought it would be fun to try a serious attempt to reverse engineer Burn and so I did. After messing with it for a couple days, the ruleset I came up with treats the example program as a Rule 110 interpreter, and it fits (mostly) within the constraints added by ais523 in 2021.
Rule Description
Burnlike is a 2D cellular automaton 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.
(This is going to be long...)
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 Burn's flood fill rules, 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 Burn program for a while, and highlighting instances of those four patterns in yellow, Rule 110 visibly appears.
Thoughts
This might not be what ais523 initially intended for Burn, but when I switched to exploring difference changes between generations, rather than just differences, it did not take long for this Rule 110 behavior to appear. The cell above containing 3 insulating a cell rule feels a bit out of place though, so it's very possible that this is not the original way this program was meant to be interpreted. Furthermore, I could not find a way for this program to natively display the output in a clear way (such as having a bright cell burn away when signal is passed in) and had to resort to highlighting residue patterns, so if the program was supposed to do that then my ruleset is not "true" Burn. Also, some cells, such as the 02, don't seem to do much, and I might be overlooking something. This might be due to the example never being tested though.
- Although I can't remember the original language, my suspicion is that this is close to being correct, but not actually fully correct. I don't think the original was based on rates of change, but rather just on the values. That said, the "if the difference is 1, one channel changes, if the difference is 2, all channels change" seems very familiar and is probably essentially correct (although I think it's more likely to be "2 or more" rather than just "2") – I'm pretty sure that there was a rule with that sort of general nature. I'm pretty sure there wasn't a "cell above another cell" special case – although it is possible that there is a bug in the original program (which was never tested) and that that case is a workaround for the bug. --ais523 04:28, 10 April 2025 (UTC)
- I tried rulesets involving the plain values longer than I considered rulesets involving rates of change and I couldn't get anywhere. In particular, I found it almost impossible to create a ruleset where the program is in equilibrium until something disturbs it and it then undergoes flood fill, which are two things I believe this program must do. In fact, I couldn't find any rule that did flood fill without some issues (such as not flooding on junctions of more than 2), and the differences themselves are all over the place on the program grid. When I based it off of change, however, it didn't take long for the ruleset I have to emerge. The rate of change rule fits the given program like a glove, even if that's just a coincidence. Does the animated GIF look how you remember the program behaving, assuming you remember at all? Also, the special 3 case was just made to plug a hole, but I guess I'm just surprised it was the only hole I had to plug to get functioning Rule 110, especially if this ruleset only works by coincidence. Truttle1 (talk) 01:48, 11 April 2025 (UTC)
- The GIF does look like I expected the program to work, in terms of the times at which individual cells change (rather than the values they change to). I would be very surprised if "Each patch represents one rule 110 cell" were incorrect. In any case, seeing this makes me fairly convinced that the numbers were designed to always increase (rather than always decrease) with a special case for 0. The reason is that each patch is taking information about the cell above by checking to see if the "01" above it changes. But if the 01 changes to a 00, that seems unlikely to have an influence on the program because there are 00s everywhere anyway – so more likely it changes to 02 or 03 in order to provide the signal, and that means that the numbers must increase. With numbers decreasing, the rate-of-change-based algorithm is probably required in order to allow the communication between patches to work correctly – hopefully having them as increasing would make that unnecessary. (It wouldn't surprise me if your current implementation happened to implement the original program's logic exactly, just with different numbers.) --ais523 06:32, 12 April 2025 (UTC)