How do I read .rule files? (Human Readability)

[TheoSwartz]

I want to make my own rule with lots of colors, just for fun and because it's something I've always wanted to experiment with but never had the medium with which to do so. However I can't make heads nor tails of the .rule format, even after reading a guide on the Golly website (it's like Greek to me even with medium level math skills - I just learn better through practice than reading). Can someone explain the following rule line by line so I can grasp how it works? It's short - just the normal Life rule.

(I understand the @RULE section, it's the @TREE that I don't understand... so many numbers for such a simple rule)

Code: Select all

@RULE Life

@TREE

num_states=2
num_neighbors=8
num_nodes=32
1 0 0
2 0 0
1 0 1
2 0 2
3 1 3
1 1 1
2 2 5
3 3 6
4 4 7
2 5 0
3 6 9
4 7 10
5 8 11
3 9 1
4 10 13
5 11 14
6 12 15
3 1 1
4 13 17
5 14 18
6 15 19
7 16 20
4 17 17
5 18 22
6 19 23
7 20 24
8 21 25
5 22 22
6 23 27
7 24 28
8 25 29
9 26 30

[muzik]

Try and paste them directly into the grid in like rle and mc. The rule should load.

[TheoSwartz]

Try and paste them directly into the grid in like rle and mc. The rule should load.

Erm, that is good for for loading rules but I'd like to understand how they work. I hope I'm explaining myself clearly. I feel like the text files for these rules look way more complicated than they should. For example Life is just B3/S23 but the .rule file is 39 lines long. Once I understand these text files, I can make my own.

[Sphenocorona]

(I understand the @RULE section, it's the @TREE that I don't understand... so many numbers for such a simple rule)

I suggest you try to learn @TABLE sections instead, which have the same purpose in the rule but are much, much easier for humans to work with. @TREE layout is meant to be more efficient for computers to process and run, but the format isn't designed to make any intuitive sense to normal people. There's still long lists of numbers involved there, but at least they are organized and function much more like how a human would normally attempt to describe the transitions that define a rule.

[TheoSwartz]

I suggest you try to learn @TABLE sections instead, which have the same purpose in the rule but are much, much easier for humans to work with. @TREE layout is meant to be more efficient for computers to process and run, but the format isn't designed to make any intuitive sense to normal people. There's still long lists of numbers involved there, but at least they are organized and function much more like how a human would normally attempt to describe the transitions that define a rule.

Thanks, I will go back and look more at @TABLE. Out of curiosity, are there any programs that can generate complicated .rule files based on simple UI and inputs? Rule generators designed for humans?

How do people normally create complicated rule files if not by hand?

[TheoSwartz]

I'm starting to understand it and can read people's tables now on a rudimentary level.

A question for anyone familiar with rule files and the "LifeHistory" rule: Why are there so many variables that are exactly the same in this file? Isn't that bad programming practice? For that matter there are a lot more redundancies in this code that I don't understand, but maybe understanding the variable part will clear up my confusion:

Code: Select all

var a={0,2,4,6}
var b={0,2,4,6}
var c={0,2,4,6}
var d={0,2,4,6}
var e={0,2,4,6}
var f={0,2,4,6}
var g={3,5}
var h={0,1,2}
var i={0,1,2,3,4,5,6}
var j={0,1,2,3,4,5,6}
var k={0,1,2,3,4,5,6}
var l={0,1,2,3,4,5,6}
var m={0,1,2,3,4,5,6}
var n={0,1,2,3,4,5,6}
var o={0,1,2,3,4,5,6}
var p={0,1,2,3,4,5,6}
var q={1,3,5}
var R={1,3,5}
var S={1,3,5}
var T={1,3,5}
var u={3,4,5}

[dvgrn]

Thanks, I will go back and look more at @TABLE. Out of curiosity, are there any programs that can generate complicated .rule files based on simple UI and inputs? Rule generators designed for humans?

How do people normally create complicated rules?

Quite a few people have mastered @TABLE format, and can generate fairly complicated multi-state rules that do a wide variety of interesting things, manually or semi-manually.

I wouldn't think anyone has written very many @TREE format rules by hand. You pretty much always just write a transition function in Python, C++, Perl, or Java, and then let the appropriate generator code do the work for you (Golly's Scripts/Python/Rule-Generators/make-ruletree.py or something in Rules/TreeGenerators.)

That said... have you found Golly's rule-format help page? @TREE format isn't really as hard as it looks. Here's my attempt at a line-by-line explanation -- but we'll have to start reading from the bottom of the file and work upwards.

First, let's label all the nodes -- that's what the mysterious sets of numbers are. Number them in order starting with Node Number Zero:

Code: Select all

 Node0: Level1 STATE0 STATE0
 Node1: Level2 Node0 Node0
 Node2: Level1 STATE0 STATE1
 Node3: Level2 Node0 Node2
 Node4: Level3 Node1  Node3
 Node5: Level1 STATE1 STATE1
 Node6: Level2 Node2  Node5
 Node7: Level3 Node3  Node6
 Node8: Level4 Node4  Node7
 Node9: Level2 Node5  Node0
Node10: Level3 Node6  Node9
Node11: Level4 Node7 Node10
Node12: Level5 Node8  Node11
Node13: Level3 Node9  Node1
Node14: Level4 Node10 Node13
Node15: Level5 Node11 Node14
Node16: Level6 Node12 Node15
Node17: Level3 Node1  Node1
Node18: Level4 Node13 Node17
Node19: Level5 Node14 Node18
Node20: Level6 Node15 Node19
Node21: Level7 Node16 Node20
Node22: Level4 Node17 Node17
Node23: Level5 Node18 Node22
Node24: Level6 Node19 Node23
Node25: Level7 Node20 Node24
Node26: Level8 Node21 Node25
Node27: Level5 Node22 Node22
Node28: Level6 Node23 Node27
Node29: Level7 Node24 Node28
Node30: Level8 Node25 Node29
Node31: Level9 Node26 Node30

The first number in each set of three is that node's level in the tree. There's only ever going to be one Level9 node (for any rule where cells have eight neighbors), and that's where we start. Notice that besides the "9", the other two numbers both identify nodes from the next lower level in the tree (Level8). Level1 nodes (only) have STATE values instead of node numbers, because down there at the bottom there's no more tree.

The Help says that for an eight-neighbor rule, the order is always northwest, northeast, southwest, southeast, north, west, east, south, center. Let's walk down the tree for a neighborhood that looks like this --

1 0 0
0 1 1
0 1 0

and find out what the new state of the center cell should be.

Node31: Level9 Node26 Node30 -- NW is first, and that neighbor is a 1, so we pick Node30.
Node30: Level8 Node25 Node29 -- NE is next, and that neighbor is a 0, so we pick Node25.
Node25: Level7 Node20 Node24 -- SW is next, and that neighbor is a 0, so we pick Node20.
Node20: Level6 Node15 Node19 -- SE is next, and that neighbor is a 0, so we pick Node15.
Node15: Level5 Node11 Node14 -- N is next, and that neighbor is a 0, so we pick Node11.
Node11: Level4 Node7 Node10 -- W is next, and that neighbor is a 0, so we pick Node7.
Node7: Level3 Node3 Node6 -- E is next, and that neighbor is a 1, so we pick Node6.
Node6: Level2 Node2 Node5 -- S is next, and that neighbor is a 1, so we pick Node5.
Node5: Level1 STATE1 STATE1 -- CENTER is last,
       but since there are three ON neighbors,
       the answer is going to be STATE1 no matter what the center state is.

Now suppose the south neighbor were off?

1 0 0
0 1 1
0 0 0

Node6: Level2 Node2 Node5 -- S is next, and that neighbor is a 0, so we pick Node2.
Node2: Level1 STATE0 STATE1 -- CENTER is last,
       but now there are only two ON neighbors,
       so the center cell stays at STATE0 if it starts at STATE0,
       or stays at STATE1 if it's currently STATE1.

Try something like

0 0 0
0 1 1
0 0 0

and you'll find you traverse a completely different part of the tree, all different nodes. You should end up at Node0, where on the last step it doesn't matter if the center cell is STATE0 or STATE1. With

Node0: Level1 STATE0 STATE0

you end up with a STATE0 answer either way.

[TheoSwartz]

Thanks for taking the time to write that out dvgrn, it actually makes sense to me looking at a list of events like that, and well... thinking of it as a tree that I can actually trace with my eyes.

It looks like you were typing this out as I was writing my last post, so I want to reiterate that I'm beginning to understand @TABLE format a bit now, and will probably stick to that over writing a tree out manually.

[praosylen]

A question for anyone familiar with rule files and the "LifeHistory" rule: Why are there so many variables that are exactly the same in this file? Isn't that bad programming practice? For that matter there are a lot more redundancies in this code that I don't understand, but maybe understanding the variable part will clear up my confusion:

Code: Select all

var a={0,2,4,6}
var b={0,2,4,6}
var c={0,2,4,6}
var d={0,2,4,6}
var e={0,2,4,6}
var f={0,2,4,6}
var g={3,5}
var h={0,1,2}
var i={0,1,2,3,4,5,6}
var j={0,1,2,3,4,5,6}
var k={0,1,2,3,4,5,6}
var l={0,1,2,3,4,5,6}
var m={0,1,2,3,4,5,6}
var n={0,1,2,3,4,5,6}
var o={0,1,2,3,4,5,6}
var p={0,1,2,3,4,5,6}
var q={1,3,5}
var R={1,3,5}
var S={1,3,5}
var T={1,3,5}
var u={3,4,5}

The reason for the identical variables is that if one uses the exact same variable name multiple times in one line, it must stand for the same state value each time, whereas if one uses two differently-named variables that can take on the same range of states, they may stand for different states (e.g. 1,i,i,1,1,1,1,1,1,0 could be parsed as 1,2,2,1,1,1,1,1,1,0 or 1,5,5,1,1,1,1,1,1,0 (among other things), but not 1,2,5,1,1,1,1,1,1,1 (for example), but 1,i,j,1,1,1,1,1,1,1 could be parsed as any of the three). In this way, rule table variables behave more like mathematical variables than programming variables.

Hope that makes any sense.

[TheoSwartz]

A for awesome,

I suspected that might be the case but it's good to hear it clear cut from someone else. Thanks for explaining!

[TheoSwartz]

By the way, how am I supposed to read rule names like "B34tw5y_S23" and "B2ce3ai_S23" ? I've just been figuring out the birth rules from trial and error. Haha.

[fluffykitty]

This has some information about Hensel notation (aka those weird rulenames) and a lot of other nontotalistic notations.

[dvgrn]

This has some information about Hensel notation (aka those weird rulenames) and a lot of other nontotalistic notations.

See also this message and the one following, which includes a script that will generate a rule table for any Hensel-notation rule string.

The EricG post that fluffykitty linked to contains some outdated links to Hensel's "neighbors.html" table rather than the "neighbors2.html" version which -- amazingly enough -- seems to be the consensus standard format. The last post in the thread mentions the general agreement to use neighbors2.html as the standard.