Code: Select all
x = 4, y = 4, rule = B3/S23
2o$obo$b3o$b3o!
Code: Select all
x = 4, y = 4, rule = B3/S23
2o$obo$b3o$b3o!
I don't think it has a name. There are so many life patterns, that have no particular interesting behaviors, that the vast majority of them don't have individual names. This is true for larger still-lifes and oscillators (but generally not spaceships, as they tend to be fragile and rare, at least in Life). This is especially true for patterns that are unstable.
This particular pattern is fairly common, though. C28 presented it in ten-cell form, but it has a six-cell predecessors and at least three seven-cell predecessors (and I wouldn't be surprised if that number turned out to be higher).mniemiec wrote: ↑May 4th, 2021, 2:03 pmI don't think it has a name. There are so many life patterns, that have no particular interesting behaviors, that the vast majority of them don't have individual names. This is true for larger still-lifes and oscillators (but generally not spaceships, as they tend to be fragile and rare, at least in Life). This is especially true for patterns that are unstable.
Code: Select all
x = 41, y = 41, rule = B3/S23
o$o34bo$o34b2o$36bobo$2o35b2o$2bo30$o$o$o36bo$o2bo32b2o$b2o34bo2bo$38b2o!
Code: Select all
x = 5, y = 4, rule = B3/S23
2b2o$bo2bo$o2bo$o2bo!
Code: Select all
x = 3, y = 5, rule = B3/S23
bo$obo$obo$b2o$bo!
Code: Select all
x = 17, y = 4, rule = B3/S23
2bo11bobo$b2obo8b2o$o11bo$2o10b2o!
I know the question is kind of old, but most of the uses I've seen for it are in Lifecompetes, where it's used to cheaply launch pis faster than the other 5-cell pi predecessor.hotdogPi wrote: ↑February 13th, 2021, 2:13 pmI didn't know about this 5-cell pi predecessor until I found it by accident — what is it actually used in?
Code: Select all
x = 3, y = 4, rule = B3/S23 bo$3o2$bo!
Code: Select all
x = 4, y = 4, rule = B2ek3ij4-jnqrz/S23
2b2o$3bo$ob2o$3o!
Sorry, I was working on finding this before.
Code: Select all
x = 21, y = 21, rule = LifeColorful
11.E$10.3E$10.E.2E$13.E4$2.2B$.2B$2B$.2B15.2D$19.2D$18.2D$17.2D4$7.C$
7.2C.C$8.3C$9.C!
The first letter is for the input methuselah. P is for pi-heptomino, H is for Herschel, and so on.ColorfulGabrielsp138 wrote: ↑May 8th, 2021, 10:51 pmWhat are the naming conventions for Herschel and non-Herschel conduits?
First one correct.cgoler2 wrote: ↑May 9th, 2021, 9:01 amThe first letter is for the input methuselah. P is for pi-heptomino, H is for Herschel, and so on.ColorfulGabrielsp138 wrote: ↑May 8th, 2021, 10:51 pmWhat are the naming conventions for Herschel and non-Herschel conduits?
Then, the letter "x" I'm not sure what it means.
The number is the repeat time of the conduit, and finally the other letter is the output methuselah.
Code: Select all
x = 100, y = 48, rule = LifeHistory
59.D3.D.4D10.D4.3D2.5D.D3.D$59.D3.D.D3.D8.2D3.D3.D.D5.D3.D$59.D3.D.D
3.D.D3.D3.D7.D.D5.D3.D$59.5D.4D3.D.D4.D6.D3.3D2.5D$59.D3.D.D3.D3.D5.D
5.D7.D.D3.D$D3.D.4D3.3D3.3D2.D3.D30.D3.D.D3.D2.D.D4.D4.D4.D3.D.D3.D$D
3.D.D3.D.D5.D3.D.D3.D30.D3.D.4D2.D3.D2.3D2.5D2.3D2.D3.D$D3.D.D3.D.D5.
D2.2D.D3.D$5D.4D2.4D2.D.D.D.5D$D3.D.D3.D.D3.D.2D2.D.D3.D$D3.D.D3.D.D
3.D.D3.D.D3.D$D3.D.4D3.3D3.3D2.D3.D5$79.2B$74.3B.4B$65.2B2.2B2.9B6.A$
63.D20B3.A.A$61.DBD20B3.A.A$12.B.3B.B2.4B35.B3D9B2A9B2.2A.3A$7.13B.4B
36.D11B2A9B3.B4.A$5.D11B2A5B2A37.20B2.B2AB3A$4.B3D9B2A5B2A39.4B.3B.
10B.B2A.A$5.DBD15B.B41.4B6.10B$7.D12B2AB44.4B5.9B$9.2B2.7B2A46.4B5.
10B$14.8B47.3B5.12B.3B$13.7B50.23B$11.10B51.22B$9.12B51.23B$9.2BD8B
53.22B.2B$8.3BDBD4B54.25B2A$9.2B3D4B52.25B.B2A$8.5BD4B50.26B3.B$7.10B
51.2BD22B$6.4B57.3BDBD4B.15B$6.3B59.2B3D4B2.14B$4.4B59.5BD4B3.4B3.4B$
4.2A60.10B5.5B2.2B$5.A59.4B15.2A$2.3A60.3B16.A$2.A60.4B18.3A$63.2A22.
A$64.A$61.3A$61.A!
Code: Select all
x = 149, y = 49, rule = LifeHistory
.3D2.4D9.3D2.5D.D3.D.D15.D29.D$D3.D.D3.D7.D3.D.D5.D3.D.D15.D29.D15.D
29.D$D5.D3.D.D3.D.D3.D.D5.D3.D.4D4.D4.4D2.3D2.4D3.3D2.4D3.4D2.3D2.4D
2.5D8.4D.D3.D.D.2D8.4D3.3D3.3D$D2.2D.4D3.D.D3.3D3.3D2.5D.D3.D7.D3.D.D
3.D.D3.D.D3.D.D3.D.D3.D.D3.D.D3.D3.D9.D5.D3.D.2D2.D3.D3.D3.D.D3.D.D3.
D$D3.D.D2.D4.D3.D3.D5.D.D3.D.D3.D7.D3.D.5D.D3.D.5D.D3.D.D3.D.5D.D3.D
3.D10.3D2.D3.D.D7.D3.D3.D.D3.D.5D$D3.D.D3.D2.D.D2.D3.D.D3.D.D3.D.D3.D
7.D3.D.D5.D3.D.D5.D3.D.D3.D.D5.D3.D3.D13.D.D3.D.D7.D3.D3.D.D3.D.D$.3D
2.D3.D.D3.D2.3D3.3D2.D3.D.4D4.D4.4D2.4D.4D3.4D.D3.D2.4D2.4D.D3.D4.2D
7.4D3.4D.D7.2D2.D3.D2.4D2.4D$60.D57.D23.D$60.D54.3D21.3D8$68.A$68.3A$
71.A$62.2B6.A.A$61.4B5.A.AB$62.4B5.A3B$63.4B6.4B$64.4B5.6B$65.4B4.7B$
66.4B2.8B.4B.B$67.17B.B2A$68.18B2A$68.16B.2B$68.5BD10B$68.6BD8B$66.2A
B.2B3D7B$65.A.AB2.11B$65.A5.10B$64.2A5.2B2A6B$70.3B2A6B$71.10B$71.8B.
B2A.A$70.7B3.B2AB3A$70.6B6.B4.A$71.6B4.2A.3A$71.5B6.A.A$70.6B6.A.A$
70.6B7.A$71.5B$71.3D2B$72.BDB$72.3D$73.B!
Code: Select all
ping catagolue.hatsya.com
Pinging ghs.googlehosted.com [172.217.24.19]
Ping statistics for 172.217.24.19:
Packets: Sent = 4, Received = 0, Lost = 4 (100% loss)
Cancel that, please! Capital F has never stood for "flip" -- it means "Forward". In modern conduit syntax, "x" means "flip". In the 1990s a small "f" was also used for "flip", but that went out of style by the time Karel Suhajda's Hersrch program came along, because it was obviously potentially confusing.
Code: Select all
x = 19, y = 19, rule = B3/S23
8b2o$8b3o$7bo4bo$6b4ob3o$7bo2bo2b3obo$7b3o2bo4b2o$3bo3bo2b2ob2obo$2b5o
bo4b2obo$2obobobo2b3o$2obobo5bobo$bo2bobobo3b2o$3bo2bob2o$2b2obo2bobo$
3b2ob2ob2o$4bob2o$4bo$6b2o$4b2o$5bo!
Sheer random chance it looks like — that and a common symmetrical predecessor arising from a pair of commonly-edgeshot active objects. It's pure serendipitous coincidence that two separate reactions happen to edgeshoot the same pair of active objects at the right relative position, though...wwei47 wrote: ↑May 9th, 2021, 11:32 pmWhy does this puffer produce so many long inverted double claws? I know that it's symmetric, but why long inverted double claws in particular?Code: Select all
x = 19, y = 19, rule = B3/S23 8b2o$8b3o$7bo4bo$6b4ob3o$7bo2bo2b3obo$7b3o2bo4b2o$3bo3bo2b2ob2obo$2b5o bo4b2obo$2obobobo2b3o$2obobo5bobo$bo2bobobo3b2o$3bo2bob2o$2b2obo2bobo$ 3b2ob2ob2o$4bob2o$4bo$6b2o$4b2o$5bo!
The immediate reaction seems to be the same for all of them.
Code: Select all
x = 8, y = 8, rule = B3/S23
2b2o$4bo2bo$o3b3o$o$b2o$2bo$2bo$bo!
Code: Select all
bo$obo$b2o2$b2o$obo$bo$
Sure.cgoler2 wrote: ↑May 12th, 2021, 8:18 amIn this orientation:Any you can only use c/2 spaceships coming from the left.Code: Select all
bo$obo$b2o2$b2o$obo$bo$
Code: Select all
x = 25, y = 45, rule = B3/S23
5b3o3b3o$5bo2bobo2bo9bo$3bo11bo6bobo$3bo2b2o3b2o2bo7b2o$3bobo2b3o2bob
o$5bo7bo9b2o$22bobo$2bobo9bobo6bo$b2o13b2o$b2ob2o7b2ob2o2$2bobo9bobo$
4bo3b3o3bo$2bob2obo3bob2obo$3bob2o5b2obo$5b2obobob2o2$8b3o$7bobobo$3b
3obobobob3o$3b2o2b5o2b2o$4bo3b3o3bo3$8bobo$7b2ob2o2$4b3obobob3o$3bo11b
o$3b2obo5bob2o$3b2o3b3o3b2o$5b2obobob2o$3bo2bobobobo2bo$2bo3bobobobo3b
o$4b2o2bobo2b2o$4bo3bobo3bo$4bo2b2ob2o2bo$bobo4bobo4bobo$2o5b2ob2o5b2o
$6bo5bo$5b2obobob2o$b3o2bobobobo2b3o$o2bo11bo2bo$o17bo$bo15bo!
Code: Select all
x = 89, y = 29, rule = B3/S23
87bo$86bobo$87b2o2$87b2o$86bobo$87bo4$26b2o3bo$25bo2bo2b2o27b2o$2bo25b
o7bo19bobob3o$o3bo22b2o3bo4bob3o7b2o4bo9b3o$5bo27b3o3b2obo5b3o5b3obob
o$o4bo23bo5bo2bo3bo7bo3b3o3bo3b2o2b2o$b5o22b3o5b3obobo11b2o10bo2bo$31b
obo10bo4b3o4bo9bo2bo$28b2ob9o2bob2o2b2o2bobo2bo7bo2bo$39bo8b5o4bo7bo$
28b2ob9o2bob2o2b2o2bobo2bo7bo2bo$31bobo10bo4b3o4bo9bo2bo$28b3o5b3obob
o11b2o10bo2bo$29bo5bo2bo3bo7bo3b3o3bo3b2o2b2o$33b3o3b2obo5b3o5b3obobo
$27b2o3bo4bob3o7b2o4bo9b3o$28bo7bo19bobob3o$25bo2bo2b2o27b2o$26b2o3bo
!
You've got a lot of questions there.
Code: Select all
x = 4, y = 4, rule = B2ek3ij4-jnqrz/S23
2b2o$3bo$ob2o$3o!
Ok then, here's the important part about the rule format. There's also an @ICONS thing, but I don't think that's very important unless you're making a turmite or something and need to specify direction.
Is it ok that I make posts this long?Rule format
A .rule file contains all the information about a rule: its name, documentation, table/tree data (used by the RuleLoader algorithm), and any color/icon information. The .rule format is textual and consists of one or more sections. Each section starts with a line of the form @XXX... where X is an uppercase letter. If there is more than one section with the same name then only the first one is used. Any unrecognized sections are silently ignored (this will allow us to add new sections in the future without breaking old versions of Golly).
The currently recognized sections are described below. You might like to refer to WireWorld.rule while reading about each section.
@RULE
This is the only mandatory section. The first line of a .rule file must start with @RULE followed by a space and then the rule name. For example:
@RULE WireWorld
The supplied rule name must match exactly the name of the .rule file. This helps Golly to avoid problems that can occur on case-sensitive file systems. When naming a new rule it's best to stick to the following conventions, especially if you'd like to share the .rule file with other Golly users:
Please capitalize all rule names and create files like Foo.rule rather than foo.rule. This helps to emphasize that rule names are important, especially on case-sensitive file systems. If the rule "foo" is specified inside a .rle or .mc file then Golly won't be able to find Foo.rule on a case-sensitive system like Linux.
To allow for possible future extensions in the way Golly handles rule names, it's best to use only letters and digits. Hyphens and underscores are also okay if you need some sort of separator. Hyphens can allow a set of related rules to share colors and/or icons (see below). Note in particular that spaces and colons must not be used.
After the @RULE line and before the next section (or end of file) you can include any amount of arbitrary text, so this is the place to include a description of the rule or any other documentation. If the .rule file has a @TREE section then this is a good place to put the Python transition function that was used to create the tree data.
@TABLE
This section is optional. If present, it contains a transition table that can be loaded by the RuleLoader algorithm. The contents of this section is identical to the contents of a .table file. A detailed specification of the .table format is available here. This is a simple example:
# Signals (2/3) pass alongside a wire (1):
n_states:4
neighborhood:vonNeumann
symmetries:rotate4
var a={2,3}
var b={2,3}
var c={2,3}
a,0,b,1,c,b
Empty lines and anything following the hash symbol "#" are ignored. The following descriptors must appear before other content:
n_states: specifies the number of states in the CA (from 0 to n_states-1 inclusive).
neighborhood: specifies the cell neighborhood for the CA update step. Must be one of: vonNeumann, Moore, hexagonal, oneDimensional. Other neighborhoods are supported through emulation, using RuleTableToTree.py, see the RoadMap for a full list.
symmetries: can be none, permute or one of the symmetries supported for the neighborhood you have chosen. For a full list, see the RoadMap.
After the descriptors comes the variables and transitions. Each variable line should follow the form given in the above example to list the states. Variables should appear before the first transition that uses them. Variables can be used inside later variables.
Transition lines should have states or variables separated by commas. If there are no variables and n_states is less than 11 then the commas can be omitted. Only one transition (or variable) should appear on each line. Inputs are listed in the order C,N,E,S,W,C' for the von Neumann neighborhood, C,N,NE,E,SE,S,SW,W,NW,C' for the Moore neighborhood, C,N,E,SE,S,W,NW,C' for the hexagonal neighborhood, and C,W,E,C' for the oneDimensional neighborhood.
Where the same variable appears more than once in a transition, it stands for the same state each time. For example, the transition in the example above expands to the following: 20212->2, 20213->2, 20312->3, 20313->3, 30212->2, 30213->2, 30312->3, 30313->3, and all 90-degree rotations of those (because of the rotate4 symmetry).
A transition can have a variable as its output (C') if that variable appears more than once in the transition (as in the example above), so that it has a definite value.
Rule tables usually don't specify every possible set of inputs. For those not listed, the central cell remains unchanged.
Transition rules are checked in the order given — the first rule that matches is applied. If you want, you can write rules in the form of general cases and exceptions, as long as the exceptions appear first.
(This form of CA rule table representation was inspired by that in Gianluca Tempesti's PhD thesis: http://lslwww.epfl.ch/pages/embryonics/ ... ndixA.html.)
If you have a C/C++ implementation of a transition function, there is a way to automatically produce a rule table. See Rules/TableGenerators/make-ruletable.cpp for instructions.
To share your rule tables with others, you can archive them at the public Rule Table Repository.
@TREE
This section is optional. If present, it contains a rule tree that can be loaded by the RuleLoader algorithm. (If the .rule file also contains a @TABLE section, RuleLoader will use the first one it finds.) The contents of this section is identical to the contents of a .tree file.
A detailed description of a rule tree is provided below, but most people don't need to know these details because Golly provides a number of tools for creating rule trees. The make-ruletree.py script in Scripts/Python/Rule-Generators can convert a Python transition function (passed via the clipboard) into a rule tree. The script will either create a new .rule file or update the @TREE section in an existing .rule file. Another script, RuleTableToTree.py, does much the same job using a requested .table file as input.
Golly also includes programs that permit you to transform a given transition function in C++, Lua, Python, Perl, or Java into a .tree file (see Rules/TreeGenerators) if the number of states is sufficiently small (approximately 10 states for eight-neighbor rules, and 32 states for four-neighbor rules). The contents of the .tree file can then be copied into the @TREE section of your .rule file.
Essentially, the tree format allows you to add your own rules to Golly without needing to know how to recompile Golly and without dealing with the intricacies of external libraries; it generates relatively compact files, and the data structure is designed for very fast execution.
A rule tree is nothing more than a complete transition table for a rule, expressed in a compressed, canonicalized tree format. For an n state rule, each tree node has n children; each child is either another tree node or a next state value. To look up a function of m variables, each of which is a state value, you start at the root node and select the child node corresponding to the value of the first variable. From that node, you select the child node corresponding to the value of the second variable, and so on. When you finally look up the value of the final variable in the last node, the result value is the actual next state value, rather than another node.
The tree format has fixed the order of variables used for these lookups. For a four-neighbor rule, the order is always north, west, east, south, center; for an eight-neighbor rule, the order is always northwest, northeast, southwest, southeast, north, west, east, south, center.
Without compression, for an n-state rule, there would be a total of 1+n+n^2+n^3+n^4 nodes for a four-neighbor rule, and 1+n+...+n^8 for an eight-neighbor rule; this could quickly get unmanageable. Almost all rules show significant redundancy, with identical rows in the transition table, and identical nodes in the rule tree. To compress this tree, all we do is merge identical nodes, from the bottom up. This can be done explicitly as we construct the tree from a transition function (see Rules/TreeGenerators/RuleTreeGen.java) or symbolically as we evaluate a more expressive format.
The tree format itself is simple, and has similarities to the macrocell format. It is not intended for human authorship or consumption. The tree format has two parts: a header, and the rule tree itself. The header consists of comments (lines starting with a "#") that are ignored, and three required parameter values that must be defined before the first tree node. These values are defined, one per line, starting with the parameter name, then an equals sign, and finally an integer value. The three parameters are num_states, which must be in the range 2..256 inclusive, num_neighbors, which must be 4 or 8, and num_nodes, which must match the number of node lines.
The tree is represented by a sequence of node lines. Each node line consists of exactly num_states+1 integers separated by single spaces. The first integer of each node line is the depth of that node, which must range from 1..num_neighbors+1. The remaining integers for nodes of depth one are state values. The remaining integers for nodes of depth greater than one are node numbers. Nodes are numbered in the order they appear in the file, starting with zero; each node must be defined before its node number is used. The root node, which must be the single node at depth num_neighbors+1, must be the last node defined in the file.
@COLORS
This section is optional and can be used to specify the RGB colors for one or more states using lines with 4 numbers, like these:
0 48 48 48 dark gray
1 0 128 255 light blue
2 255 255 255 white
3 255 128 0 orange
Golly silently ignores any states that are invalid for the rule. To specify a color gradient for all live states (all states except 0) you can use a line with 6 numbers, like this:
0 0 255 255 0 0 blue to red
In both cases, any text after the final number on each line is ignored. Blank lines or lines starting with "#" are also ignored.
Note that a .rule file is loaded after switching to the current algorithm's default color scheme, so you have the choice of completely changing all the default colors, or only changing some of them. Use Preferences > Color to change the default colors for each algorithm.
Code: Select all
x = 4, y = 4, rule = B2ek3ij4-jnqrz/S23
2b2o$3bo$ob2o$3o!