Thread for basic questions

[Vort]

...
Although that may actually become an useful way of grouping collisions...

I think having several algorithms may be useful for optimization purposes.

The first, fast, algorithm may distinguish between "no collision" and "collision is probable" cases.
Then second, slower, algorithm, may split "probable" case into "no collision" and "collision" outcomes.

[confocaloid]

...
Although that may actually become an useful way of grouping collisions...

I think having several algorithms may be useful for optimization purposes.

The first, fast, algorithm may distinguish between "no collision" and "collision is probable" cases.
Then second, slower, algorithm, may split "probable" case into "no collision" and "collision" outcomes.

For three-glider collisions, one could have the following subsets:

• Three-directional: all three gliders come from different directions.
• 90-degree two-directional, all gliders are initially well-separated.
• 90-degree two-directional, two out of three gliders form a single quasi-object.
• 180-degree two-directional, all gliders are initially well-separated.
• 180-degree two-directional, two out of three gliders form a single quasi-object.

Independently from that, one can subdivide in a different way:

• Two out of three gliders collide strictly before third glider collides with the result. Third glider hits settled final ash from a two-glider collision.
• Two out of three gliders collide strictly before third glider collides with the result. Third glider hits the reaction before it settles.
• All three gliders collide at the same time.

Independently from that, one can subdivide by the final pattern (empty / stationary stable / stationary periodic / some escaping spaceship(s)).

Together, several such subdivisions (made sufficiently precise and unambiguous, and implemented) would give multiple smaller families or subsets of collisions.

edit: wording.

[WhiteHawk]

Relocated this p45 hassler from 2023 oscillator stamp collection. My question is what sort of hassler is it - it does form Pi-heptomino hasslers in the middle at one point, though it also forms B-heptominos as well.

Code: Select all

x = 53, y = 51, rule = B3/S23
9$19bob2o7b2o3b2o$12b2o5b2obo7bobo2bo$11bo2bo2b2o7bob2o2bo3bo$12b2o2b
obob2o4b2obobob4o$13bob2o2b2o2bo7bobo$13bo2bo5b2o6b2obob2o$8bob2ob2o19b
obo$8b2obo$11bo$11b2o3$29b2o$7b2o13bo6bobo$8bo13b2o7bo$8bobo10bob2o4b
obo$9b2o6b2o4b2o4b2o6b2o$16bobo4b2obo10bobo$16bo7b2o13bo$16bobo6bo13b
2o$17b2o3$35b2o$36bo$36bob2o$11bobo19b2ob2obo$11b2obob2o6b2o5bo2bo$14b
obo7bo2b2o2b2obo$11b4obobob2o4b2obobo2b2o$11bo3bo2b2obo7b2o2bo2bo$12b
o2bobo7bob2o5b2o$11b2o3b2o7b2obo!

[confocaloid]

If it really did "form Pi-heptomino hasslers in the middle at one point", then it would be a pi-heptomino hassler hassler instead, which (as far as I can tell) it isn't.

The hassled active reaction never becomes "two pi-heptominoes and nothing else". In those phases where you see pi-heptominoes, the active reaction includes something else.

The hassled active reaction never becomes "two B-heptominoes and nothing else", either. In those phases where you see B-heptominoes, the active reaction includes something else.

So while it is a hassler oscillator, this oscillator is neither a pi hassler nor a B hassler.

Relocated this p45 hassler from 2023 oscillator stamp collection. My question is what sort of hassler is it - it does form Pi-heptomino hasslers in the middle at one point, though it also forms B-heptominos as well.

Code: Select all

x = 53, y = 51, rule = B3/S23
9$19bob2o7b2o3b2o$12b2o5b2obo7bobo2bo$11bo2bo2b2o7bob2o2bo3bo$12b2o2b
obob2o4b2obobob4o$13bob2o2b2o2bo7bobo$13bo2bo5b2o6b2obob2o$8bob2ob2o19b
obo$8b2obo$11bo$11b2o3$29b2o$7b2o13bo6bobo$8bo13b2o7bo$8bobo10bob2o4b
obo$9b2o6b2o4b2o4b2o6b2o$16bobo4b2obo10bobo$16bo7b2o13bo$16bobo6bo13b
2o$17b2o3$35b2o$36bo$36bob2o$11bobo19b2ob2obo$11b2obob2o6b2o5bo2bo$14b
obo7bo2b2o2b2obo$11b4obobob2o4b2obobo2b2o$11bo3bo2b2obo7b2o2bo2bo$12b
o2bobo7bob2o5b2o$11b2o3b2o7b2obo!

[WhiteHawk]

I realize this is actually an extremely similar question to the one I just asked, but I observed that the oscillator below is called "p40 moose honey farm hassler" when inputted into Catagolue.

xp40_62sgw252y8252wgs26zoge21x75596y069557x12egozggymggz10nk8xeaa96y069aaex8kn01z643x4a4y84a4x346

However, none of the major sequences hassled in the object is actually a honey farm predecessor, but instead represent a single beehive predecessor, an interchange predecessor, as well as an ephemeral line-of-six, a lump of muck predecessor which collides with a blinker, and even an active region which ends up producing a beehive and a block (which actually inhibits more of the reaction), but no honey farm predecessor as far as I could find.

Code: Select all

x = 65, y = 8, rule = B3/S23
11bo$4o6bobo26b2o21b3o$o3bo5bobo25bo2bo20bo$3obo6bo6b6o15b2o19b3o$3bo
7bo28b2o18b3o$10bobo47b2o$10bobo$11bo!

My question is then why is it called a "Honey Farm Hassler" when it does not hassle any honey farm predecessor?

Also, why are all of the interchange hasslers awkwardly placed at the bottom of the interchange page? Shouldn't they be their own page?

[hotdogPi]

I probably made a typo and meant to type traffic light or interchange.

[confocaloid]

I think it was added in this commit: https://gitlab.com/hatsya/open-source/c ... 8906a3c9a1
Other than that, I've no idea where the name comes from.

I realize this is actually an extremely similar question to the one I just asked, but I observed that the oscillator below is called "p40 moose honey farm hassler" when inputted into Catagolue.

xp40_62sgw252y8252wgs26zoge21x75596y069557x12egozggymggz10nk8xeaa96y069aaex8kn01z643x4a4y84a4x346
[...]
[...]
Also, why are all of the interchange hasslers awkwardly placed at the bottom of the interchange page? Shouldn't they be their own page?

The "X hasslers" pages are problematic for several reasons, including people repeatedly misunderstanding / disagreeing on what exactly makes a "X hassler" when "X" is a specific active object.

It would be better to avoid creating more such pages until there is some evidence of consensus on the issue.

It might be better to deprecate most of the existing "X hasslers" pages, and prefer something more well-defined and objective, e.g. period-specific pages.

[WhiteHawk]

I probably made a typo and meant to type traffic light or interchange.

So did you find it? Citing for Interchange page.

[pifricted]

Is there already a CA art collection thread?

[confocaloid]

Is there already a CA art collection thread?

There might be already a bit too many scattered "art" type threads.

viewtopic.php?f=12&t=4980 "Art"
viewtopic.php?f=12&t=6323 "Still Life Art"
viewtopic.php?f=12&t=6173 "StateInvestigator Pixel Art"
viewtopic.php?f=12&t=5436 "Art from CGoL"
...

I'm skeptical about having a single thread. Those people who are going to want to share some kind of "art" will almost surely disagree on what that means, and people will continue to make new separate threads, and the combined thread will end up being mostly ignored, as far as its intended purpose goes.

Even with simple technical questions (where correctness, welldefinedness is measurable and agreement is possible in principle), people already disagree.
Defining what makes "art" and what would be ontopic in such a thread is basically hopeless. It will devolve into another random-posts thread.

[WhiteHawk]

What are some examples of statorless, but not strictly volatile, odd-period oscillators in Life?

EDIT How is volatility checked for cells which repeat at every 1/3, 1/4, 1/5, 1/8, or just 1/nth fraction of the total period of an oscillator?

[hotdogPi]

What are some examples of statorless, but not strictly volatile, odd-period oscillators in Life?

p75

Code: Select all

x = 30, y = 34, rule = B3/S23
bo$bo2$bo$obo2$3o8bo2bob2obo2bo$10b2o2bo4bo2b2o$11bo2bob2obo2bo$3o2$ob
o$bo2$bo$bo8b2o5b3o$9bo2b2o2b2ob2o$9b2ob2o2b2o2bo$10b3o5b2o8bo$28bo2$
28bo$27bobo2$27b3o$7bo2bob2obo2bo$6b2o2bo4bo2b2o$7bo2bob2obo2bo8b3o2$
27bobo$28bo2$28bo$28bo!

p105

Code: Select all

x = 40, y = 40, rule = B3/S23
17b8o$8bo8bob4obo$8bo8b8o$7bobo$8bo$8bo$8bo$8bo22bo4bo$7bobo19b2ob4ob
2o$8bo22bo4bo$8bo4$19b3o$3o17bo$obo18bo$3o34b3o$3o11bobo20bobo$3o11b2o
9bo11b3o$3o11bo9b2o11b3o$obo20bobo11b3o$3o34b3o$18bo18bobo$19bo17b3o$
18b3o4$31bo$3bo4bo22bo$b2ob4ob2o19bobo$3bo4bo22bo$31bo$31bo$31bo$30bob
o$15b8o8bo$15bob4obo8bo$15b8o!

[WhiteHawk]

p75

Code: Select all

p105

Code: Select all

Hmm... I guess these do qualify for what I asked for since the Pentadecathlons make the reaction statorless but not strictly volatile, but I was thinking more unsupported reactions like the statorless (not strictly volatile) p6, the statorless twin bees shuttle, etc.

[confocaloid]

[...] Obviously it's easy to tell for even-period oscillators if a cell on at the start is on at the halfway point, but how is volatility checked for cells which repeat at every 1/3, 1/4, 1/5, 1/8, or just 1/nth fraction of the total period of an oscillator?

What is the perceived problem with determining periods of cells?
For every cell in the rotor of the oscillator, write down the sequence of its states over time. That sequence has a finite period, not exceeding the period of the oscillator.

Code: Select all

1 0 0 1 0 0 1 0 0 1 0 0 1 0 0    -- oscillates at period 3
1 0 0 1 0 1 0 0 1 0 1 0 0 1 0    -- oscillates at period 5
1 0 1 0 1 0 0 1 0 1 0 1 0 0 1    -- oscillates at full period 15
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1    -- stator bit
0 0 0 0 0 0 0 0 0 0 0 0 0 0 0    -- permanently dead cell

[dvgrn]

EDIT How is volatility checked for cells which repeat at every 1/3, 1/4, 1/5, 1/8, or just 1/nth fraction of the total period of an oscillator?

As far as I know, there are no interesting shortcuts for checking subperiod volatility.

As confocaloid says, you have to list out the cell states for each cell for the full period. Then you check each factor of that period separately, making sure that the full list doesn't repeat itself precisely at that subperiod.

For each subperiod S, you can stop checking as soon as you find a state that's different at time N vs. at time N+S.

[confocaloid]

[...] For every cell in the rotor of the oscillator, write down the sequence of its states over time. That sequence has a finite period, not exceeding the period of the oscillator. [...]

EDIT How is volatility checked for cells which repeat at every 1/3, 1/4, 1/5, 1/8, or just 1/nth fraction of the total period of an oscillator?

As far as I know, there are no interesting shortcuts for checking subperiod volatility. [...]

There may be interesting shortcuts in implementation:

There is just a lot of computation required for this pattern: the evolution of 34040 active cells across 29400 generations for 71 different sub-periods, none of which have a match.

Having said this I realised that for an oscillator of period p, in order for a specific cell to be oscillating at sub-period n, it must be alive for at least p / n generations. By computing the alive count per cell over period p (which is fairly inexpensive), I could use this information to quickly discard a sub-period n search for a specific cell if its alive count was less than this threshold.

In this extreme case the performance has doubled. On my machine build 1082 took 117 seconds to Identify the pattern vs 53 seconds on build 1083. For other patterns there will likely be a smaller improvement.

[...]
Actually each cell must be alive for some multiple of p / n generations. Build 1084 now identifies this pattern in 9.2 seconds on my machine.

Code: Select all

x = 40, y = 22, rule = B2n3aeijy4ci5cr6n/S2aek3-acek4eiknr5ir6eik7e
38bo$38b2o$39bo5$31b2o$31b2o5$31b3o$31b3o2$28b3o$2o2bo23bo2bo$o27b2o2b
2o$2obo26bo2bo$b3o26b3o$2bo!

[Haycat2009]

What is the differnce between @TREE and @TABLE?

[confocaloid]

What is the differnce between @TREE and @TABLE?

Those are two different formats for defining a multistate cellular automaton.

I think the content of a @TREE section is (more or less) a reflection of the internal representation. It is not supposed to be written manually, and in most cases is autogenerated by some script.

The @TABLE format is more user-friendly, and indeed a rule table can be written by hand, by listing all the rules one-by-one, one rule per line.

Also, while the exact formats are probably specific to Golly/LifeViewer, the underlying ideas are old and appear in different contexts. Both the idea of having a sequence of if-then rules which are checked in order until there is a match, and the idea of traversing a tree representation to determine what to do, are old.

[Haycat2009]

I think the content of a @TREE section is (more or less) a reflection of the internal representation. It is not supposed to be written manually, and in most cases is autogenerated by some script.

Ugh. I just tried reverse-engineering a @TREE rule table and figuring how it worked. (So I could write one)

On a side note, are there any scripts that can convert between the two?

[confocaloid]

I just tried reverse-engineering a @TREE rule table and figuring how it worked.

The rule tree format is documented in Golly's help: https://golly.sourceforge.io/Help/formats.html#tree

[dvgrn]

On a side note, are there any scripts that can convert between the two?

Yup, Scripts/Python/Rule-Generators/RuleTableToTree.py (comes with Golly).

As confocaloid says, the tree format is more directly usable by Golly, so conversion in the tree-to-table direction pretty much never happen. I suspect that for some rules, the @TREE structure ends up containing a lot of non-intuitive shortcuts, simplifying the tests that need to be done on neighbor states.

So if a RuleTreeToTable script were written, it would often produce very weird-looking rules -- with no convenient grouping or comments explaining the groups! The tree format doesn't have to care about maintaining those human-compatible details.

[WhiteHawk]

Are there any oscillators with constant populations higher than period 4?

Are there any oscillators with constant populations higher than period 2 that aren't billiard tables?

[confocaloid]

Are there any oscillators with constant populations higher than period 4?

Are there any oscillators with constant populations higher than period 2 that aren't billiard tables?

A straightforward "yes" to both answers. Here is an example for period 15, constant population 314:

Code: Select all

x = 146, y = 16, rule = B3/S23
63bo39bo9bo$43bo8b3o8bo19bo8b3o7bobo8bo$23bo8b3o7b3o17b3o7b3o7b3o7b3o$
3bo8b3o7b3o6bo3bo5bobobo5bo3bo17bo19bo19bo9bo19bo$2b3o6bo3bo5b5o5bo3bo
5bobobo5bo3bo17bo19bo8b3o7bobo8bo8b3o7bobo$b2ob2o4bo5bo15b3o7b3o17b3o
7b3o7b3o8bo8b3o17bobo7bobo6bo3bo$3ob3o36bo8b3o8bo28bobo8bo8b3o8bo8b3o
6bo3bo$3ob3o2bo7bo45bo8b3o7bobo38bo8b3o6bo3bo$3ob3o2bo7bo45bo8b3o7bobo
38bo8b3o6bo3bo$3ob3o36bo8b3o8bo28bobo8bo8b3o8bo8b3o6bo3bo$b2ob2o4bo5bo
15b3o7b3o17b3o7b3o7b3o8bo8b3o17bobo7bobo6bo3bo$2b3o6bo3bo5b5o5bo3bo5bo
bobo5bo3bo17bo19bo8b3o7bobo8bo8b3o7bobo$3bo8b3o7b3o6bo3bo5bobobo5bo3bo
17bo19bo19bo9bo19bo$23bo8b3o7b3o17b3o7b3o7b3o7b3o$43bo8b3o8bo19bo8b3o
7bobo8bo$63bo39bo9bo!

[WhiteHawk]

A straightforward "yes" to both answers. Here is an example for period 15, constant population 314:

Code: Select all

Well, I guess that is kind of what I asked for.

More specifically, is there a oscillator, one which is both nontrivial and can't be subdivided into separate working oscillators, for either of the questions poised previously?

[confocaloid]

More specifically, is there a oscillator, one which is both nontrivial and can't be subdivided into separate working oscillators, for either of the questions poised previously?

The example I posted is a nontrivial oscillator (because there is a cell oscillating at full period), but it is not a strict object.

I think finding strict nontrivial constant population oscillators shouldn't be too hard, though. For all high periods, you can just take any oscillator built using stable Herschel tracks or stable glider reflectors, and join phases together by welding together catalysts. That will be both strict and nontrivial. There will remain some low periods not covered, and will have to be solved case-by-case.