Thread for basic questions

[wirehead]

Does this qualify as a replicator? And if not, what kind of infinite growth is this?

Code: Select all

x = 4, y = 4, rule = B2en3eijy4-ekny5kq6-c7/S1c2ik3-ny4-aitw5a6-en78
b2o$o2bo$o2bo$b2o!

I don't think that's a replicator, more just a chaotic messy plus sign. Replicators have to, well, replicate, and I am not seeing any replication of any part of the pattern. At any rate, if that does evolve into four extremely high-period replicators, the pattern you posted would be classified as a replicator predecessor.

[confocaloid]

I'm not even sure if that pattern actually grows forever, or whether its bounding box grows forever. I ran it long enough to see spaceships created, but those collided with each other or with other parts of the pattern.

[HerscheltheHerschel]

What is this? replicator?

Code: Select all

x = 44, y = 18, rule = R2,C0,M1,S10..19,B4..4,NM
28bob5o2bo4bo$32b4o2b5o$bo4bo2b5obo18bob7o$b5o2b4o18bobobo3bobo$b7obo
19bo2b4obobo$3bobo3bobobo14b2o2b3obo5bo$4bobob4o2bo13b4o2bobo6bo$bo5bo
b3o2b2o16b3o2bo3bo$o6bobo2b4o14bob4obob2o2bo$2bo3bo2b3o16b2obo3bobob2o
$o2b2obob4obo14bobo2b2ob2o5bo$3b2obobo3bob2o12bobobo5b4o$o5b2ob2o2bobo
12b7o2bobo3bo$2b4o5bobobo13bo3b3obo3bobo$o3bobo2b7o14b4obobo3b3o$obo3b
ob3o3bo13bob2obobob2o$3o3bobob4o$5b2obobob2obo!

what does C1 mean in here ? b38s23/C1
I googled but found nothing about the C1 neighborhood. Where can I read about this terminology ?

C1 is not a neighborhood. It is a symmetry. C1 symmetry is just asymmetry.

[hotcrystal0]

Is there any isotropic non-totalistic rule with a replicator that simulates Wolfram rule 30?

[azulavoir]

So that's my basic question: does anyone know where that "C0" rule is coming from, and why it says that rather than "C2"?

As far as I can tell, C0 (and C1!) are used interchangeably with C2 in LifeViewer, and indeed even in the specification of the HROT syntax. And it seems like LifeViewer defaults to C0 when you copy a pattern out of it.

[confocaloid]

So that's my basic question: does anyone know where that "C0" rule is coming from, and why it says that rather than "C2"?

As far as I can tell, C0 (and C1!) are used interchangeably with C2 in LifeViewer, and indeed even in the specification of the HROT syntax. And it seems like LifeViewer defaults to C0 when you copy a pattern out of it.

Here is a quote from my post from a related discussion:

[...]
However, both Golly and Catagolue return rulestrings with C0. So if there is anything close to a "standard", then it is C0, not C2.
Catagolue example: https://catagolue.hatsya.com/object/xp1 ... 4t45s34t58

I think that it makes sense to keep C0 as the default, rather than switching everything to C2. Software would still accept either C0 or C2, but would return/generate "C0" when the rule is 2-state.

[HerscheltheHerschel]

What are the smallest unnatural objects?

[get_Snacked]

What are the smallest unnatural objects?

14P2.4 and Octapole at 14 cells.

[muzik]

Do cases where the envelopes of two oscillators overlap count as distinct oscillators, or not? Or does it only count in cases where the volatility would change, such as in RRO loops or the following?:

Code: Select all

x = 13, y = 23, rule = B3/S23
4bo3bo$3bobobobo$4b2ob2o2$bo9bo$obo7bobo$o3b2ob2o3bo$bo3bobo3bo$2b2obo
bob2o$4bo3bo4$4bo3bo$3bobobobo$4b2ob2o2$bo9bo$obo7bobo$o3b2ob2o3bo$bo
3bobo3bo$2b2obobob2o$4bo3bo!

[confocaloid]

Do cases where the envelopes of two oscillators overlap count as distinct oscillators, or not?

Probably depends on the purpose? There might be some situation where it would help to think otherwise, but under normal conditions, as far as I can see those never interact with each other, and the pattern evolves the same way as if the two oscillators were evolved independently before being placed in a single universe.

[dvgrn]

There might be some situation where it would help to think otherwise, but under normal conditions, as far as I can see those never interact with each other, and the pattern evolves the same way as if the two oscillators were evolved independently before being placed in a single universe.

Yup. There might be a case where we wish that, say, apgsearch/Catagolue's census code could pry apart a couple of oscillators that are much more deeply overlapping than that example -- e.g., to be able to identify the following as two independent, non-interacting twin-bees shuttles:

Code: Select all

x = 58, y = 17, rule = B3/S23
19b2obo$2o12b3o2b2o2bo3b2o$2o13b2o6bo3b2o$16b3o3b2o$17bo3bo$30bo5bo$17b
o3bo8bo5bo11b2obo$16b3o3b2o19b3o2b2o2bo3b2o$2o13b2o6bo2b2o11b2o3b2o6b
o3b2o$2o12b3o2b2o2bo21b3o3b2o$19b2obo7bo5bo9bo3bo$30bo5bo$46bo3bo$45b
3o3b2o$29b2o13b2o6bo3b2o$29b2o12b3o2b2o2bo3b2o$48b2obo!

In practice there's an inevitable trade-off between doing the absolute deepest possible analysis of every "oscillator" to see if it can be partitioned, versus actually getting a reasonably good census done in a reasonable amount of time. But it seems like overlapping oscillators should really count as distinct, as long as you can remove either one without the other one being affected in any way.

[confocaloid]

That might be solvable with postprocessing. In addition to the algorithm trying to partition non-interacting parts quickly, there could be rules of the form "Rewrite every occurrence of xp46_33y427dcccy733zccy44eb333y1ee0rhe4y74eqoooy766zypooy48sm666y7oo into two occurrences of xp46_033y133zzzckgsxsgkczz0cc".

[silversmith]

That might be solvable with postprocessing.

I had an idea for an algorithm which could help to do this. At a high level, every live cell of a pattern would have a "color" ranging from 0 to N-1, where N is the number of cells in the pattern. Any time a cell is born it inherits the highest color out of the three which it was born of. Then each rotor in a pattern should eventually become a uniform, unique color.

[confocaloid]

That might be solvable with postprocessing.

I had an idea for an algorithm which could help to do this. At a high level, every live cell of a pattern would have a "color" ranging from 0 to N-1, where N is the number of cells in the pattern. Any time a cell is born it inherits the highest color out of the three which it was born of. Then each rotor in a pattern should eventually become a uniform, unique color.

How would one handle gutter symmetry, and other similar cases? I don't think rotors like this would ever become uniform.

Code: Select all

x = 9, y = 5, rule = B3/S23
bo5bo$obo3bobo$o2bobo2bo$2bo3bo$2b2ob2o!

Code: Select all

x = 62, y = 11, rule = B3/S23
19b2obo16bob2o$2o12b3o2b2o2bo3b2o4b2o3bo2b2o2b3o12b2o$2o13b2o6bo3b2o4b
2o3bo6b2o13b2o$16b3o3b2o14b2o3b3o$17bo3bo18bo3bo2$17bo3bo18bo3bo$16b3o
3b2o14b2o3b3o$2o13b2o6bo14bo6b2o13b2o$2o12b3o2b2o2bo14bo2b2o2b3o12b2o$
19b2obo16bob2o!

[silversmith]

How would one handle gutter symmetry, and other similar cases? I don't think rotors like this would ever become uniform.

This algorithm wouldn't handle them. It would be the first step in identifying groups of cells which make up a single rotor, and then a next step would be running each piece without the others to determine if the rotor is an independent oscillator, similar to the problem of determining if a still-life is strict.

Also, additional steps would be needed to determine which parts of a stator are part of/necessary for a particular rotor.

[dvgrn]

I had an idea for an algorithm which could help to do this. At a high level, every live cell of a pattern would have a "color" ranging from 0 to N-1, where N is the number of cells in the pattern. Any time a cell is born it inherits the highest color out of the three which it was born of. Then each rotor in a pattern should eventually become a uniform, unique color.

Let's see, that would generalize reasonably well to non-Life rules -- focus on the newly born cells, and eventually there's some hope of having each contiguous stretch of rotor marked in one color.

It doesn't even always work to identify contiguous rotors, though. It might not always work even for oscillators with no stator like Karel's p177 or Gabriel's p138.

I haven't tried those two particular cases -- maybe the color change can migrate through the dying sparks fast enough, not sure -- but it's certainly possible to build engineered examples of things where the rotor won't be successfully colored all one color. For example, anything glider-supported wouldn't allow the color to propagate back to the gun -- right?

[confocaloid]

I played with a related idea (but for a different purpose), which was:

• a cell of a different state should be born only in some rarely occurring 3x3 condition;
• that different cellstate should be "contagious", propagating to the surrounding alive cells, as soon as that rare event happened;
• the alive cellstates should be "cyclically symmetric", so that no single cellstate "wins" over others.

I got the following:

[...] A (5,2)c/190 spaceship with a single-colour phase:

Code: Select all

x = 16, y = 36, rule = Pedestrian5C_v1
3.A2.A$2.A3.A$6.A$.A2.A$2.2A$2.A6$3.3A$3.3A$3.2A$2.A$2A2.A$.A3.A$.A2.
A$2.3A2$12.A2.A$11.A3.A$15.A$10.A2.A$11.2A$11.A8$13.2A$12.A.A$13.A!

[...]

Oscillators with B8 in the rotor (the ruletree):

Code: Select all

x = 137, y = 323, rule = Pedestrian5C_v1
36.A30.D$14.E.E.E17.3A23.2A2.2D$39.A22.A.A$18.E15.5A.A18.2A.A3.A$33.A
6.A18.2A.A2.2A$14.E.E.E13.A.A.A.A.A.2A17.A.B3.D$32.A.A2.B2.A.A18.A3.
2A$18.E12.2A.A.A.A.A.A20.A3.3D$34.A6.A18.A.2A.AD2.D$14.E.E.E15.A.5A
18.2D3.A.D$35.A$36.3A$38.A9$14.E3.E18.2A$36.A2.A$14.E3.E15.3A.A.A$33.
A4.A.A$14.E.E.E13.A.3A.A.2A$32.A4.B4.A$18.E14.2A.A.3A.A$34.A.A4.A$18.
E15.A.A.3A$35.A2.A$36.2A8$57.2A$55.A2.A$14.E.E.E36.3A$34.A.A2.A$14.E
3.E15.3A.A.2A11.7A$33.A6.A11.A7.A$14.E.E.E15.A5.2A10.3A3.3A$37.B18.B$
14.E3.E14.2A5.A11.3A3.3A$34.A6.A10.A7.A$14.E.E.E14.2A.A.3A12.7A$35.A
2.A.A$55.3A$54.A2.A$54.2A6$105.2A$105.A$11.E2.E.E.E21.2A10.2A48.2A.A
24.2A$40.2A10.2A48.A.A25.2A$11.E6.E$69.A15.A9.A15.A$11.E6.E50.3A11.3A
9.3A11.3A11.2A$33.2A3.2A3.3A2.3A3.2A3.2A11.A3.3A3.A15.A3.3A3.A13.A2.A
3.3A3.2A$11.E6.E14.2A2.A2.A2.A.A2.A.A2.A2.A2.2A10.A4.A.A4.A13.A4.A.A
4.A12.A.A4.A.A3.2A$37.A.A3.3A2.3A3.A.A14.2A3.3A3.2A13.2A3.3A3.2A11.2A
.2A3.3A$11.E6.E19.A16.A2$38.A16.A$37.A.A3.3A2.3A3.A.A$33.2A2.A2.A2.A.
A2.A.A2.A2.A2.2A10.2A3.3A3.2A13.2A3.3A3.2A11.2A.2A3.3A$33.2A3.2A3.3A
2.3A3.2A3.2A10.A4.A.A4.A13.A4.A.A4.A12.A.A4.A.A3.2A$72.A3.3A3.A15.A3.
3A3.A13.A2.A3.3A3.2A$69.3A11.3A9.3A11.3A11.2A$69.A15.A9.A15.A$40.2A
10.2A$40.2A10.2A76.2A$130.2A11$7.E.E.E2.E.E.E19.2A$38.2A6.2A$11.E2.E
31.2A2$7.E.E.E2.E.E.E2$7.E10.E22.A3.A5.2A$33.2A5.2A2.2A5.2A$7.E.E.E2.
E.E.E14.2A5.A3.A4$38.2A$38.2A6.2A$46.2A13$37.2A17.2A$36.A.A17.A.A$37.
A19.A$33.B27.B$7.E.E.E2.E.E.E13.B.B25.B.B$32.B.2B.3B4.2B3.2B4.3B.2B.B
$11.E2.E18.B3.B.B3.3B3.3B3.B.B3.B$37.3B3.B2.B.B2.B3.3B$7.E.E.E2.E.E.E
24.2B.B.B.2B$44.2B3.2B$7.E6.E3.E2$7.E.E.E2.E.E.E4$44.2B3.2B$43.2B.B.B
.2B$37.3B3.B2.B.B2.B3.3B$33.B3.B.B3.3B3.3B3.B.B3.B$32.B.2B.3B4.2B3.2B
4.3B.2B.B$32.B.B25.B.B$33.B27.B$37.A19.A$36.A.A17.A.A$37.2A17.2A10$
43.A26.A$43.A.A22.A.A$7.E.E.E2.E.E.E12.2A11.A.A6.A6.A6.A.A11.2A$31.2A
11.A2.A4.3A4.3A4.A2.A11.2A$11.E2.E3.E25.A.A4.2A.2A2.2A.2A4.A.A$43.A.A
6.3A4.3A6.A.A$7.E.E.E2.E3.E24.A9.A6.A9.A2$11.E2.E3.E$43.A9.A6.A9.A$7.
E.E.E2.E.E.E24.A.A6.3A4.3A6.A.A$44.A.A4.2A.2A2.2A.2A4.A.A$31.2A11.A2.
A4.3A4.3A4.A2.A11.2A$31.2A11.A.A6.A6.A6.A.A11.2A$43.A.A22.A.A$43.A26.
A12$31.2A28.2A$7.E.E.E2.E.E.E12.A.A26.A.A$32.A28.A$7.E10.E2$7.E.E.E2.
E.E.E$39.3A10.3A$7.E3.E2.E15.3A6.A.A10.A.A6.3A$39.3A10.3A$7.E.E.E2.E.
E.E4$39.3A10.3A$30.3A6.A.A10.A.A6.3A$39.3A10.3A4$32.A28.A$31.A.A26.A.
A$31.2A28.2A8$34.2B7.A7.2A$35.B7.3A5.2A$7.E.E.E2.E3.E16.B.B8.A$36.2B
7.2A$7.E3.E2.E3.E2$7.E.E.E2.E.E.E2$11.E6.E2$7.E.E.E6.E3$45.A$44.A.A$
43.A3.A$43.A3.A$43.A3.A$44.A.A$45.A2$47.2A7.2B$47.A8.B.B$41.2A5.3A7.B
$41.2A7.A7.2B7$46.2B$4.E2.E.E.E2.E.E.E27.2B2$4.E6.E2.E3.E2$4.E2.E.E.E
2.E3.E2$4.E2.E6.E3.E2$4.E2.E.E.E2.E.E.E2$38.3B12.3B$38.B.B12.B.B$38.
3B12.3B36.2E26.2A$92.3E24.3A$83.2E9.2E.E18.A.2A9.2A$83.E5.E4.E2.E18.A
2.A4.A5.A$88.E5.2E.E18.A.2A5.A$38.3B12.3B28.E3.E3.3E24.3A3.A3.A$38.B.
B12.B.B30.E5.2E7.E10.A7.2A5.A$38.3B12.3B44.3E8.3A$100.3E8.3A$99.2E.2E
6.2A.2A$100.3E8.3A$100.3E8.3A6$46.2B$46.2B8$34.2B$35.B$E3.E2.E.E.E2.E
3.E16.B.B$36.2B$E3.E6.E2.E3.E2$E.E.E2.E.E.E2.E.E.E2$4.E2.E10.E$68.B$
4.E2.E.E.E6.E47.3B$65.B$65.2B2$48.3B8.2B$51.B7.2B$51.B7.2B$48.2B2.B.
3B$57.B.3B.B.B$44.3B3.B3.C2.B.3B.B2.B$47.B9.B.3B.B.B$51.6B$44.2B2.2B
9.2B$46.2B11.2B$59.2B7$27.2B$28.B$25.3B$25.B6$56.2B$56.B.B$58.B$58.2B!

Edit 1 (2022-12-06): added a p17
Edit 2 (2023-04-11): added a p3
Edit 3 (2023-05-26): added a p25

How would one handle gutter symmetry, and other similar cases? I don't think rotors like this would ever become uniform.

This algorithm wouldn't handle them. It would be the first step in identifying groups of cells which make up a single rotor, and then a next step would be running each piece without the others to determine if the rotor is an independent oscillator, similar to the problem of determining if a still-life is strict.

Also, additional steps would be needed to determine which parts of a stator are part of/necessary for a particular rotor.

I agree that can work as a step. The next steps probably would involve running over subsets of the collection of all identified groups of cells, to see which sets of groups of cells are phases of oscillators and which are not. That could work for patterns that are likely to occur in the results from apgsearch census.
(edited to clarify)

[dvgrn]

The next steps probably would involve running over subsets of identified groups of cells, to see which subsets are phases of oscillators and which are not. That could work for patterns that are likely to occur in the results from apgsearch census.

More specifically, I think you'd have to say "see which subsets are phases of the rotors of (known) oscillators". The colorization method, as it's described, doesn't spread into the stators of oscillators, so you can't just compare with a whole oscillator -- but stators are often welded or otherwise variable, anyway, so maybe that's a good thing!

There are various somewhat more aggressive algorithms for colorizing an oscillator that do successfully spread through the oscillator's stator, and even across gutters -- but that wouldn't jump to any Oscillator #2 that never came close enough to affect Oscillator #1's neighbor counts.

For cases like the original example of two Rich's p16s, where the two oscillators _do_ affect each other's neighbor counts but not enough to cause a birth, things get more complicated, especially when the algorithm is supposed to work across the full range of outer-totalistic or even isotropic non-totalistic rules.

[silversmith]

It doesn't even always work to identify contiguous rotors, though. It might not always work even for oscillators with no stator like Karel's p177 or Gabriel's p138.

I haven't tried those two particular cases -- maybe the color change can migrate through the dying sparks fast enough, not sure -- but it's certainly possible to build engineered examples of things where the rotor won't be successfully colored all one color. For example, anything glider-supported wouldn't allow the color to propagate back to the gun -- right?

Based on some manual testing, Gabriel's p138 would become one color, while Karel's p177 would become 4 diagonally separate partitions. However, you are correct that if an object being supported by glider guns has a "higher color" than the gliders, then the object would forever have at least two colors of active cells.

One solution would be to measure if the "spread of color" has become periodic, and then reverse the transmission rule, so that the lower color spreads instead. Assuming one could do so efficiently, it would solve the case of gun supported objects, but not oscillators like Karel's p177. The only solution I could think of there is trying to run the pieces without the support of the others. Since the parts would collapse, a program could detect the change in evolution and recognize them as a contiguous pattern.

[qqd]

How do you access a ruletable in Golly for a rule?

[confocaloid]

How do you access a ruletable in Golly for a rule?

If you mean scripting, I think you could do that indirectly using "numstates" and "evolve(cell_list, numgens)" functions. Make a celllist with the 3x3 condition of interest, evolve it for one tick and check the new state of the central cell. That suffices to recover one row (of the ruletable which was expanded to avoid all variables). I don't think there is an easy way to determine which neighbourhood is used, or whether the ruletable is permutation-symmetric or isotropic or completely asymmetric.

If you mean something in the user interface, I don't remember any functionality beyond being able to load a ruletable via the "Set Rule" dialog.

See also the quoted post, for a related feature request

Provide a programmatic way to construct and use in a pattern an arbitrary RuleLoader-supported rule from a Golly script, without storing the rule in a file

[qqd]

How do you access a ruletable in Golly for a rule?

If you mean scripting, I think you could do that indirectly using "numstates" and "evolve(cell_list, numgens)" functions. Make a celllist with the 3x3 condition of interest, evolve it for one tick and check the new state of the central cell. That suffices to recover one row (of the ruletable which was expanded to avoid all variables). I don't think there is an easy way to determine which neighbourhood is used, or whether the ruletable is permutation-symmetric or isotropic or completely asymmetric.

If you mean something in the user interface, I don't remember any functionality beyond being able to load a ruletable via the "Set Rule" dialog.

See also the quoted post, for a related feature request

Provide a programmatic way to construct and use in a pattern an arbitrary RuleLoader-supported rule from a Golly script, without storing the rule in a file

I feel that is extremely inefficient. I would need to check hundreds of grids to reconstruct the ruletable of a many state rule. Plus, can't you access it from Golly's memory? It must be there somewhere, since how can it run the rule without knowing its ruletable?

[confocaloid]

[...]
See also the quoted post, for a related feature request

Provide a programmatic way to construct and use in a pattern an arbitrary RuleLoader-supported rule from a Golly script, without storing the rule in a file

I feel that is extremely inefficient. I would need to check hundreds of grids to reconstruct the ruletable of a many state rule. Plus, can't you access it from Golly's memory? It must be there somewhere, since how can it run the rule without knowing its ruletable?

Same thoughts here. But I don't know of any API to directly access (either read or modify) the internal in-memory representation of the rule from a script. I think they'll suggest to do that indirectly via file system operations.
It would be nice to be able to generate a rule dynamically, without having to store it in a file.

[TinkerMagus]

Does the pattern of lightweight, middleweight, and heavyweight spaceships continue ? I made three guesses but all of them failed ? Does this family end with only these 3 ?

Code: Select all

x = 33, y = 37, rule = B3/S23
10bo7b2o$o2bo4bo3bo3bo4bo$4bo8bo8bo$o3bo3bo4bo2bo5bo$b4o4b5o3b6o13$28b
o$4b3o20b3o$2bo5bo16bo5bo$9bo22bo$2bo6bo15bo6bo$3b7o16b7o9$16bo$15bob
o$13bo5bo$20bo$13bo6bo$14b7o!

[confocaloid]

Does the pattern of lightweight, middleweight, and heavyweight spaceships continue ? I made three guesses but all of them failed ? Does this family end with only these 3 ?

Code: Select all

x = 33, y = 37, rule = B3/S23
10bo7b2o$o2bo4bo3bo3bo4bo$4bo8bo8bo$o3bo3bo4bo2bo5bo$b4o4b5o3b6o13$28b
o$4b3o20b3o$2bo5bo16bo5bo$9bo22bo$2bo6bo15bo6bo$3b7o16b7o9$16bo$15bob
o$13bo5bo$20bo$13bo6bo$14b7o!

OWSS
xWSS
standard spaceship