Examine individual changes
Jump to navigation
Jump to search
This page allows you to examine the variables generated by the Abuse Filter for an individual change.
Variables generated for this change
Variable | Value |
---|---|
Edit count of the user (user_editcount) | 0 |
Name of the user account (user_name) | 'Hex96' |
Age of the user account (user_age) | 179 |
Page ID (page_id) | 3605 |
Page namespace (page_namespace) | 1 |
Page title (without namespace) (page_title) | 'Burn' |
Full page title (page_prefixedtitle) | 'Talk:Burn' |
Action (action) | 'edit' |
Edit summary/reason (summary) | 'I think I got the main parts down' |
Old content model (old_content_model) | 'wikitext' |
New content model (new_content_model) | 'wikitext' |
Old page wikitext, before the edit (old_wikitext) | '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. --[[User:ais523|ais523]] 20:26, 16 December 2010 ([[User:ais523|U]][[User talk:ais523|T]][[Special:Contributions/Ais523|C]])
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:
<pre>
Going into
this instruction
VV
00 01 00
00 01 01
00 00 00
</pre>
The direction pointer will be set to right. In this case:
<pre>
00 00 00
00 01 01 < Going into this instruction
00 01 00
</pre>
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:
<pre>
Going into 00 01 00
this instruction > 01 01 00
00 01 00
</pre>
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.
<pre>
01 = NOP
11 = PUSH
02 = POP
10 = Pop a value x and push (not x)
30 = Duplicate the top of the stack
</pre>
With this table, the example program sets address 0x0000 to 1 and exits the top half of the program. Hope this helps.
--[[User:aithecomputerguy|aithecomputerguy]]
{{unsigned|17:48, 7 June 2014|aithecomputerguy}}
:FWIW, I think this guess is inconsistent with the additional information ais523 gave above. --[[User:Oerjan|Ørjan]] ([[User talk:Oerjan|talk]]) 11:32, 2 December 2014 (UTC)
== Random Observations and Guesses ==
The frequency of each group of numbers is as follows, from most common to least common:
00 - 27 times<br />
11 - 18 Times<br />
01 - 8 Times<br />
10 - 7 Times<br />
02 - 1 Time<br />
12 - 1 Time<br />
20 - 1 Time<br />
21 - 1 Time<br />
03 - 1 Time<br />
30 - 1 Time<br />
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 rule110 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.
--[[User:Truttle1|Truttle1]] ([[User talk:Truttle1|talk]]) 04:38, 3 April 2019 (UTC)' |
New page wikitext, after the edit (new_wikitext) | '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. --[[User:ais523|ais523]] 20:26, 16 December 2010 ([[User:ais523|U]][[User talk:ais523|T]][[Special:Contributions/Ais523|C]])
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:
<pre>
Going into
this instruction
VV
00 01 00
00 01 01
00 00 00
</pre>
The direction pointer will be set to right. In this case:
<pre>
00 00 00
00 01 01 < Going into this instruction
00 01 00
</pre>
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:
<pre>
Going into 00 01 00
this instruction > 01 01 00
00 01 00
</pre>
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.
<pre>
01 = NOP
11 = PUSH
02 = POP
10 = Pop a value x and push (not x)
30 = Duplicate the top of the stack
</pre>
With this table, the example program sets address 0x0000 to 1 and exits the top half of the program. Hope this helps.
--[[User:aithecomputerguy|aithecomputerguy]]
{{unsigned|17:48, 7 June 2014|aithecomputerguy}}
:FWIW, I think this guess is inconsistent with the additional information ais523 gave above. --[[User:Oerjan|Ørjan]] ([[User talk:Oerjan|talk]]) 11:32, 2 December 2014 (UTC)
== Random Observations and Guesses ==
The frequency of each group of numbers is as follows, from most common to least common:
00 - 27 times<br />
11 - 18 Times<br />
01 - 8 Times<br />
10 - 7 Times<br />
02 - 1 Time<br />
12 - 1 Time<br />
20 - 1 Time<br />
21 - 1 Time<br />
03 - 1 Time<br />
30 - 1 Time<br />
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 rule110 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.
--[[User:Truttle1|Truttle1]] ([[User talk:Truttle1|talk]]) 04:38, 3 April 2019 (UTC)
== 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. That’s what I think is what is happening with the program.' |
Unified diff of changes made by edit (edit_diff) | '@@ -75,2 +75,6 @@
--[[User:Truttle1|Truttle1]] ([[User talk:Truttle1|talk]]) 04:38, 3 April 2019 (UTC)
+
+== 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. That’s what I think is what is happening with the program.
' |
New page size (new_size) | 4073 |
Old page size (old_size) | 3801 |
Lines added in edit (added_lines) | [
0 => '',
1 => '== I think I got the main parts down ==',
2 => '',
3 => '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. That’s what I think is what is happening with the program.'
] |
Unix timestamp of change (timestamp) | 1575473966 |