ConwayLife.com

I found a crystal that climbs up a p14 glider stream: Is it known?

ThePlayzr wrote: September 28th, 2025, 10:32 pm I found a crystal that climbs up a p14 glider stream:

Code: Select all

x = 83, y = 104, rule = B3/S23
39b2o$38bo2bob2o$37bo2b2obobo$37b2obo4bo$38bo2b2o2bob2o$36bo2bobo2b2o
2bo$35bob3obobo2bo$26bo9bo5bob2o$26b3o8b3o$4b2o23bo10b6o$4bobo4b2o3b2o
6b4o2bo4b3ob2o4bo$7bo3b2o2bobo6bo3b2o4bo3bobob2o$2o3b2obo6bobob2ob2o3b
o4bo2b4obobo$bo2bobob7obobobobo5b6obobo2bo3bo$o3bo2bo8bo3bo2bo4bo6bo2b
o2b4o$4obo2b6o2b2ob6o5b5o3b2o$5b3o4bo2b3obo4bo8bo5bob2o$2o3bobobo4bo5b
ob2o10b2obobobobo$o4bobobob10obo4bo6bo3bobo2bo$b3ob2o2bo12bo3bobo5bo3b
obobo$4bo4b4o2b2o2b2obob3obo4b5o3bo$b2obo7bo2bo4bo2bo4b2o2b5o$bobo7bo
4bo3bo3b4o2bo5bo$10bob4o2b2ob3o4b2o5bo$11bo4b2obobo3b2obobo3b2o3b2o$12b
3obo9bobo2b2obo3bo2bo$14bo2b4o4bo2bo4bo4b3o$15b2o4bo4b3ob3obo$17b5o7b
ob2o3b3o$17bob4o3b2obo4b2o3bo$4b2o8b2obo5bobobob2o4bo3bo$5bo8bo2bo2bo
2bobo3bo2b2o3bob2o$5bobo7b2o2bobobo2bo2bo6b2o3bo$6b3ob2o5b5ob3o2b2obo
6b3o3b2o$8b2obo5bo4bo7b2obo4bo5bo2b2o$8b3o7b3obob6o2b2o11bobo$4b2o3bo
10bobobo9b2o8b2obo2b2o10b2o$4bo2bobo17b2obo2bobo7bo3bobobo10bobob2o$6b
2obo2bo8b3o3bo4bo2bo6b3ob2obo14bobobob2o$10b2o16bo3bo2b2ob2o23b2o3bob
o$29b2ob2o6bo5b2o4b2ob2o7bo3bo2bo$22bo9b2o3bo2bo4b3o3b6o2b2o2bo5b2o$21b
3o13bo2bo3bo13bo5b5o$11b2o7b5o12b2obo3b2o4bobo2bobo3bo6bo$11b2o6b2o3b
2o12bobo3bo3bobob2obob11o$10bo8b2ob3o13bobobobobobobo14bo$9b3o8b4o15b
obob2ob2o2bobob9o$19bo2bo18bo3bo4bob2o5bo2bo$40b2o3bob3o5b2o$14b3o7bo
21b2o8bo$15bo7bobo28bo$13b2o9bo29b2o$13b2o4$14b2o$14bobo$15b2o2$12b2o
$13bo$10b3o$10bo39$81b2o$81b2o!

Is it known?

Independently discovered on several occasions:
viewtopic.php?p=183890#p183890
viewtopic.php?p=162508#p162508
viewtopic.php?p=4249#p4249

I expect it was known well before that too.

@ dvgrn

Why do we use EAT ( Eater ) instead of DELETE ( ?????Deleter????? ) ?

Thank You - Cheers !

otismo wrote: September 30th, 2025, 11:40 am @ dvgrn

Why do we use EAT ( Eater ) instead of DELETE ( ?????Deleter????? ) ?

Thank You - Cheers !

Because the eaters don’t remove the cells.

otismo wrote: September 30th, 2025, 11:40 am Why do we use EAT ( Eater ) instead of DELETE ( ?????Deleter????? ) ?

We usually use the names that were given to objects by early discoverers. There's a very long tradition in the community of paying close attention to those details. Saves an awful lot of noise and confusion, compared to the nightmare situation where each newcomer invents and campaigns for their own name that they're sure is much better.

In this case, we call fishhooks "eater" or "eater 1" because that was the metaphor that the MIT group used when they were figuring out all the cool things that eaters could do back in 1971. See, e.g., the "three course meal" on page 15 of LifeLine #3.

What is 5blink?

Resu wrote: October 3rd, 2025, 4:37 amWhat is 5blink?

5blink

We have black-white reversals and checkerboard duals, but can the more general case of an "agar dual" exist, in which patterns in an agar in one rule exist and function the same in a vacuum in some other rule?

For example, is there a rule (which supports orthogonal mirror reflections and 180-degree rotations) in which cells evolve identically to how they would evolve in an infinite zebra stripes agar in Life?

What is this pattern's growth rate? It is linear, but what is the limiting ratio of population to generation?

I apologize if this is not the right place to ask. I genuinely don't know where else to.

I want to run apgsearch on my computer for B36S23/C1. Running it using the default ruleset results in a consistent speed of ~5000 soups/second. (I don't know if this is slow or not, but I'm fairly happy with this) However, running it on this ruleset results in an inconsistent speed of 1-100 soups/second, which is agonizingly slow. I'm running this all on a Windows 11 laptop on Cygwin64.

Should I expect any alternate rulesets to be slower than Life, or am I doing something wrong? I know next to nothing about Life and everything about it, I just want to see what to expect from random soups.

Jay Bergé wrote: October 8th, 2025, 9:55 am I apologize if this is not the right place to ask. I genuinely don't know where else to.

I want to run apgsearch on my computer for B36S23/C1. Running it using the default ruleset results in a consistent speed of ~5000 soups/second. (I don't know if this is slow or not, but I'm fairly happy with this) However, running it on this ruleset results in an inconsistent speed of 1-100 soups/second, which is agonizingly slow. I'm running this all on a Windows 11 laptop on Cygwin64.

Should I expect any alternate rulesets to be slower than Life, or am I doing something wrong? I know next to nothing about Life and everything about it, I just want to see what to expect from random soups.

The HighLife replicator is probably slowing things down.

hotdogPi wrote: October 8th, 2025, 10:07 am The HighLife replicator is probably slowing things down.

Seems fair. Is there any way to speed things up on my end, or should I accept the speed it's running at?

Jay Bergé wrote: October 8th, 2025, 10:18 am Seems fair. Is there any way to speed things up on my end, or should I accept the speed it's running at?

You can speed up apgsearch by closing down other applications, and you may be able to get minimal speed inprovements by compiling with --profile. Assuming you have multiple cores, it would be much faster for all rules by using WSL instead of Cygwin (where parallelisation does not work) and running apgluxe with -p <number of threads>. But HighLife is a nightmare to search because of all the replicators, so you might have to accept the speed you are running it at if you want to search it.

In general, the following characteristics can make a rule very slow to search:
-Common infinite growth patterns.
-Lots of unique common objects.
-Chaotic infinite growth patterns - these include replicators, quadratic growth, or any strange enough pattern that confuses the identification algorithm.
-Chaotic nature in general - a rule which is nearly explosive will still be slow to apgsearch.

what is the pattern behind the minimum populations of rectifier loops?

EDIT by dvgrn: I'm guessing this question was inspired by looking at Rectifier#SKOPs.

EDIT: Yes, it was

WhiteHawk wrote: October 10th, 2025, 1:34 pm what is the pattern behind the minimum populations of rectifier loops?

If the rectifier loop period is a number of the form 258+8N, it can work with just one signal in the loop -- minpop of 113.
If the length is of the form 133+4N, it can work with just two signals in the loop -- minpop of 116.
If 5 signals are needed in the loop, minpop is 148 (higher because there can't be a pop-reducing pi stage of the signals in both rectifiers at the same time).
If 6 signals are needed in the loop, minpop is 136.
If 10 signals are needed in the loop, minpop is 156.

See the second column in the Rectifier#SKOPs table.

EDITed a bit: It's a good exercise to work out exactly why, for example, the p178 and p194 rectifier-loop oscillators need 5 circulating signals as opposed to 2 or 6 or 10 -- and why 3-signal loops never show up in the SKOP list, but 6-signal loops do.

It's not a coincidence that 178 and 194 are separated by a distance of 8N. (186 would be in the list too, except that we have a 64-cell SKOP for that period.)

dvgrn wrote: October 10th, 2025, 2:49 pm

WhiteHawk wrote: October 10th, 2025, 1:34 pm what is the pattern behind the minimum populations of rectifier loops?

If the rectifier loop period is a number of the form 258+8N, it can work with just one signal in the loop -- minpop of 113.
If the length is of the form 133+4N, it can work with just two signals in the loop -- minpop of 116.
If 5 signals are needed in the loop, minpop is 148 (higher because there can't be a pop-reducing pi stage of the signals in both rectifiers at the same time).
If 6 signals are needed in the loop, minpop is 136.
If 10 signals are needed in the loop, minpop is 156.

See the second column in the Rectifier#SKOPs table.

It's a good exercise to work out exactly why, for example, the p178 and p194 rectifier-loop oscillator needs 5 gliders as opposed to 2 or 6 or 10. It's not a coincidence that 178 and 194 are separated by a distance of 8N. (186 would be in the list too, except that we have a 64-cell SKOP for that period.)

Thanks
I was looking for a relationship in terms of what periods require a minimum of n number of glider signals in their loops (also was investigating if p178 and p194 SKOPs could be reduced). It might be helpful to list those relationships on the wiki.

WhiteHawk wrote: October 10th, 2025, 3:00 pmI was looking for a relationship in terms of what periods require a minimum of n number of glider signals in their loops (also was investigating if p178 and p194 SKOPs could be reduced). It might be helpful to list those relationships on the wiki.

I started to add a paragraph under the SKOP table, but decided to leave it for someone else. I might get some details wrong, and maybe someone else knows all the rules backwards and forwards already. If not, feel free to figure them out and then explain them on the wiki.

Here's a sample calculation for p178 and p194, just to get things started:

p178 is listed as needing 5 signals in the loop, so the total loop length is 178*5 = 890.

We can change the total loop length by 8 ticks by moving one rectifier one diagonal cell closer or farther from the other one.

If some loop length 890 - 8N was also a (smaller) multiple of 178, then we could use that number of signals instead. Let's see... a quick Fill Down in a spreadsheet says that 178 is the first period with an integer result for (890-8N)/178 -- N=89.

Unfortunately we can't put two rectifiers that close together -- the minimum total length of a two-rectifier loop is 266. So the 5-signal loop is as good as it's going to get. These calculations have already been done for every period, in building that SKOP table; in the absence of some new technology, I doubt you'll find any reductions.

Similarly 194*5 = 970, and there are no smaller multiples of 194 that look like 970-8N ... until we hit 194, but 194 is still smaller than 266.

Sokwe wrote: October 11th, 2025, 3:15 pm Fully enumerated object counts by number of cells are given on the LifeWiki:Object_counts page.

Why has it not been confirmed that there are no p6 or p12 oscillators with 9 cells even though it has been confirmed for all other periods that none exist? I did read the page/thread on this, but I didn't really get it since it was really dense.

WhiteHawk wrote: October 11th, 2025, 10:05 pmWhy has it not been confirmed that there are no p6 or p12 oscillators with 9 cells even though it has been confirmed for all other periods that none exist? I did read the page/thread on this, but I didn't really get it since it was really dense.

Long story short, Nick Gotts (who did the relevant exhaustive enumerations) wrote some code that tested 9-cell patterns by running the eventual ash for 12 ticks, and ignored anything where the pattern at T=k+12 matched the pattern at T=k. k=16384 apparently -- mentioned here.

I can't quite tell if there was some kind of population-only test for "quiescence", since gliders and xWSSes are mentioned as well as pulsars, to justify the convenience of checking T=k+12.

Sokwe suggested a special run to definitively rule out p6 and p12 spaceships and oscillators with 9 and 10 cells. It sounded like that might happen, but the thread stopped being active soon after that.

I don't think that any of the relevant code or data has been shared yet --

NickGotts wrote: December 23rd, 2019, 6:33 am I also intend to make my code and data files available online at some point. However, the data files for 10 cell single-cluster patterns fill about 35GB, although I wouldn't necessarily need to include them all.

-- and Nick Gotts hasn't been active on the forums for the last couple of years. It might be worth checking to see if that might still be available. EDIT: I've sent Nick an email.

Hi,

As I wrote to Dave in response to his email, I'm just getting back into Game of Life after an almost complete break (I'm getting back into it by working on a smaller survey of a similar type, which I'll post about soon.

The main aim of my exhaustive (but unfinished) survey was to establish the minimum number of cells needed to produce infinite growth, so I wrote code to filter out patterns that had settled down into clusters of oscillators, gliders and *WSSs that were never going to interact with each other - anything it did not weed out, I would examine by eye. So, the obvious filtering procedure was to choose a number of steps to advance a pattern before comparing it to its former state. The number had to be divisible by 4 (to make it easy to check that fleets of gliders and *WSSs had simply moved further from each other and any oscillators), and by 3 - because I didn't want to be alerted for every pulsar. My memory is that I used 60 rather than 12 some of the time, to filter out patterns including pentadecathlons, but I'll check. The code could be rerun using 4 (or 20) instead of 12 or 60, so that any 6 or 12 period oscillators (along with pulsars) would pass the filter.

I'm afraid the code and data have never been made available, but I do hope to remedy that. The survey wasn't completed - I hadn't covered the 10-cell multi-cluster patterns (i.e. those that consist of two or three separate clumps of cells), and I need to check whether I got all the 9-cell multi-cluster patterns; and I really should check all the code I used, make sure it runs in the current version of Golly and still looks sound, and comment it, before releasing it and completing the search. So it may be a while yet.

Is there any serious doubt remaining for 9-cell patterns? There is enough raw compute power today that the enumeration doesn't need to be very clever.

pcallahan wrote: October 13th, 2025, 3:52 pm Is there any serious doubt remaining for 9-cell patterns? There is enough raw compute power today that the enumeration doesn't need to be very clever.

It's likely for a "glider colliding with block" type pattern to pop up and sabotage the search, so something is needed to detect such patterns.

b-engine wrote: October 14th, 2025, 12:08 am

pcallahan wrote: October 13th, 2025, 3:52 pm Is there any serious doubt remaining for 9-cell patterns? There is enough raw compute power today that the enumeration doesn't need to be very clever.

It's likely for a "glider colliding with block" type pattern to pop up and sabotage the search, so something is needed to detect such patterns.

But I think those have all been covered. The biggest collision between a glider and a block is a pi heptomino and it doesn't release any gliders. I don't know the collisions with a tub offhand. Then there are r-pentomino reactions with a block.

I am pretty sure all of these have been explored as well as interactions of 3 clusters of 3. Unfortunately, it has never been written down neatly as a proof that all cases are covered.

Today, it should be possible to handle a lot of this by brute force. E.g., ignore gliders and r-pentominoes and say you cover just 9 live cells in a 20x20 bounding box. A truly brute force approach would require 400 choose 9 trials, or about 6.597973299E+17. That's too much, but most of these consist of isolated cells or cell pairs that vanish in one generation. You're really only concerned with blinker and block precursors.

I think Nick Gotts went through all of this by hand already, but there is probably a more uniform description of what you would have to enumerate.

For some reason, when I copy a pattern, and go into the web version of golly, and paste, it just pastes the default pattern. Does the web version not have external sync for clipboard?
Also, how do I turn a pattern into a .mc file that I can run in golly without pasting?
Edit: how do I use the web version of golly to make a population graph?

Can you monomerise the twin bees shuttle?