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 ... else
flow 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
11
wire worked differently, but no, all of them are supported by a01
and10
if 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 the20
that does a conversion but the combination of the20
and11
(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?