Methuselah metrics

[melwin22]

I'm afraid this is gonna be a long one... Some of my observations, thoughts and questions (bolded) about methuselah metrics. The post uses examples from CGoL, but I believe all of this rant applies to a much wider class of cellular automata.

A „methuselah” is not really a term that can be precisely defined, and there were a lot of debates on what counts and what doesn’t. We all generally understand that a methuselah is a pattern that evolves for a long time, as the word comes from the biblical figure who supposedly lived 969 years, the longest lifespan mentioned in the Bible. Let’s for now stick with that loose definition and look at six main metrics that are used to measure the „quality” of a methuselah.

1) Lifespan (L)
The most obvious one. Lifespan of a pattern is „the first generation such that the pattern can be resolved into still lifes, oscillators and escaping spaceships” (from LifeWiki on methuselah), unless the pattern grows infinitely. L could still be defined for those patterns as something along the lines of „the first generation such that the pattern can be resolved into still lifes, oscillators, escaping spaceships and escaping periodic growing objects”, but what exactly does that mean? Can quadratic or logarithmic growth be considered periodic? This becomes a deep rabbit hole very quickly, therefore from now on I will talk only about objects that do not grow infinitely.

For a pattern to count as a methuselah and not a spark, usually the threshold of L=100 is used; that is, objects that live for less than 100 generations are not considered methuselahs.

Still, a „methuselah” with arbitrarily long lifespan can be easily constructed: a glider running toward a block from N blocks away has L proportional to N.

2) Final population (F)
Number of alive cells in the stabilized pattern. For methuselahs consisting only of still lifes, gliders and blinkers, stabilized population is constant, but consider patterns like Eve, which has a pulsar. It lives for 30046 generations: on that generation, it stabilizes, and has a population of 3034. On the next generation, population raises to 3050, and then falls to 3026, and this last number is listed as F for Eve. This seems to imply that the minimum is taken from the periodic phase, but for Justyna (which has a beacon) F is listed as the maximum from the periodic phase. Why is that? Which population should be chosen?

Furthermore, maybe another metric should be considered: M, or the Maximum population. Eve reaches 3700+ live cells during its evolution, and this difference might be even higher for other objects. This also allows to measure diehards, which have F of 0. What do you think?

A „methuselah” with arbitrarily high final population is also easy to construct: a glider running toward a gun from N blocks away, which eventually destroys the gun, has F proportional to N.

3) Final population divided by Initial population (F/I)
Can also be called the „growth factor” of an object, this metric penalizes large initial patterns. As it is quite obvious that large initial pattern will generally produce large amount of ash, a methuselah consisting of hundreds of cells usually isn’t considered interesting. However, lifespan of the pattern isn’t taken into account here, so the metric actually favors the most expansive patterns, not necessarily the most long-lived.

The trick I mentioned in section #2 still applies: a glider running toward a gun from N blocks away, which eventually destroys the gun, has F/I proportional to N.

4) Lifespan divided by Initial population (L/I)
Was originally called the „evolutionary factor”. Also penalizes large initial patterns, but works better for measuring methuselahs, because it takes into account their lifespan. I believe this was used as the main metric before #6 was invented; correct me if I'm wrong.

The same trick still works: L/I is proportional to N.

5) Final population divided by Lifespan (F/L)
For me, this is a very counterintuitive metric, because it actually penalizes long lifespan, which is kind of against the very idea of a methuselah. Simple objects have F/L much higher than any methuselah (a pre-block with L=1 and F=4…). Even editors of LifeWiki seem to be confused about this, because out of the four metrics mentioned in the „Methuselah” article, it’s the only one without any description. Maybe L/F would make more sense?

A pattern with arbitrarily high F/L can be built in a different way. Take the Max spacefiller and place a block N cells away. Max will eventually hit the block and become a giant pool of ash, with F being proportional to N^2, and L proportional to N, allowing for as large F/L as desired.

6) Lifespan divided by Minimum Covering Polyplet Size (L/MCPS)
I believe this to be a superior metric out of the six, because none of the easy tricks mentioned so far work here. MCPS grows proportionally to N, so placing an object N cells away from some simple reaction that eventually reaches it is effectively disqualified.

That is not to say that L/MCPS is perfect; there are, in fact, ways to „cheat” here as well, but they are much more sophisticated. One thing that comes to my mind is to take the Summers/Nivasch logarithmic growth and place some mechanism which reacts with the output, but N cells away. Because every iteration of the logarithmic growth takes more time to complete, lifespan grows exponentially with N, and therefore allows as large L/MCPS as desired. What is the simplest way you can think of to get arbitrarily high L/MCPS?

Another problem with MCPS is that calculating its value is an NP-hard problem, and for large patterns it becomes quite a nightmare to actually figure out how big exactly MCPS is.

Conclusions:
- L/MCPS is the best metric, but hard to calculate.
- L/I is probably the second best and much easier to calculate.
- F/L doesn’t make sense.
- Maximum population could be used as another metric (or, perhaps, M/I, M/MCPS?).
- There are ways to produce an arbitrarily high score in any mentioned metric.

To counter the last problem, the usual solution is to limit the initial population or initial bounding box. I propose the following:
- MCPS of the starting pattern should be at most 1024 (this includes all objects listed in „List of long-lived methuselahs” on LifeWiki).
- Because that is hard to calculate, one can first look at a simpler constraint: if a pattern fits inside a 32x32 bounding box (the standard apgsearch box for higher symmetries), its MCPS physically can’t exceed 1024.
- If you think this is too much, a reduction to 256 cells also seems valid (although it does disqualify two large objects mentioned in the article).

This eliminates the Summers/Nivasch logarithmic growth, which has a much higher initial population. What is the highest L/MCPS you can think of that fits within this constraint?

Thank you for listening to my podcast.

[EvinZL]

- If you think this is too much, a reduction to 256 cells also seems valid (although it does disqualify two large objects mentioned in the article).

This eliminates the Summers/Nivasch logarithmic growth, which has a much higher initial population. What is the highest L/MCPS you can think of that fits within this constraint?

Thank you for listening to my podcast.

It is possible to implement logarithmic growth within 256 cells:

Code: Select all

x = 126, y = 127, rule = B3/S23
2bo$obo$b2o54$75b2o$75bo3$78b2o28b2o7bo6bo$78bo38b2o5b2o$107bobo$105bo
14bo$101b2obob2o12b2o$102bob2o$75bo27bo$74bobo$75b2o20bo$97b2o2$77bo
15bo6bo$77b2o14b2o5b2o8$87bo$86b2o$98bo9bo$83bo14bobo5b3o$66b4o13b2o
13b2o5bo$64b2o4b2o33b2o$64b2o5bo$66b2obobo14bo$71bo14b2o$67bo3bo31bo$
67bo4bo30bo$69b3o3bo26bobo$69b2o4bo25b2ob2o$75b2o23bo5bo$77bo25bo$77b
3o20b2o3b2o3$80bo$79bob5o$78b2o5bo$78b2o3bo2bo$86bo$80b2obo2bo16bo$83b
o2bo3bo12b2o$84b2o3bobo$84b2o4b2o2$90b2o$90bo2$90bo$86b2o2b2o$85bobo$
86bo$82b2o$82b2o2bo$80bo4bobo$78b2o5bo$79b2o5b2o$87bo2bo2$88bo$89b2o$
87bo$85b2o$86b2o!

[melwin22]

- If you think this is too much, a reduction to 256 cells also seems valid (although it does disqualify two large objects mentioned in the article).

This eliminates the Summers/Nivasch logarithmic growth, which has a much higher initial population. What is the highest L/MCPS you can think of that fits within this constraint?

Thank you for listening to my podcast.

It is possible to implement logarithmic growth within 256 cells:

Code: Select all

x = 126, y = 127, rule = B3/S23
2bo$obo$b2o54$75b2o$75bo3$78b2o28b2o7bo6bo$78bo38b2o5b2o$107bobo$105bo
14bo$101b2obob2o12b2o$102bob2o$75bo27bo$74bobo$75b2o20bo$97b2o2$77bo
15bo6bo$77b2o14b2o5b2o8$87bo$86b2o$98bo9bo$83bo14bobo5b3o$66b4o13b2o
13b2o5bo$64b2o4b2o33b2o$64b2o5bo$66b2obobo14bo$71bo14b2o$67bo3bo31bo$
67bo4bo30bo$69b3o3bo26bobo$69b2o4bo25b2ob2o$75b2o23bo5bo$77bo25bo$77b
3o20b2o3b2o3$80bo$79bob5o$78b2o5bo$78b2o3bo2bo$86bo$80b2obo2bo16bo$83b
o2bo3bo12b2o$84b2o3bobo$84b2o4b2o2$90b2o$90bo2$90bo$86b2o2b2o$85bobo$
86bo$82b2o$82b2o2bo$80bo4bobo$78b2o5bo$79b2o5b2o$87bo2bo2$88bo$89b2o$
87bo$85b2o$86b2o!

Thanks for the reply, but this isn't really what I meant.
1) First of all, it grows infinitely, and I specifically excluded such types of patterns in my rant.
2) The pattern you posted has a population of less than 256 cells, but definitely doesn't have MCPS within 256, which is what I was thinking of (maybe didn't make this clear enough). As I said, figuring out the exact value of MCPS is difficult, I believe in this case it's around 350. As we know from the RCT theory, basically anything is possible within 75 cells of 15 gliders, so MCPS must be taken into consideration with this kind of thought experiments.
3) There is some sort of logarithmic reaction here, but dimensions of the bounding box grow linearly, and the Summers/Nivasch logarithmic growth which I mentioned has the bounding box that grows logarithmically, which I believe is needed.

[EvinZL]

- If you think this is too much, a reduction to 256 cells also seems valid (although it does disqualify two large objects mentioned in the article).

This eliminates the Summers/Nivasch logarithmic growth, which has a much higher initial population. What is the highest L/MCPS you can think of that fits within this constraint?

Thank you for listening to my podcast.

It is possible to implement logarithmic growth within 256 cells:

Code: Select all

x = 126, y = 127, rule = B3/S23
2bo$obo$b2o54$75b2o$75bo3$78b2o28b2o7bo6bo$78bo38b2o5b2o$107bobo$105bo
14bo$101b2obob2o12b2o$102bob2o$75bo27bo$74bobo$75b2o20bo$97b2o2$77bo
15bo6bo$77b2o14b2o5b2o8$87bo$86b2o$98bo9bo$83bo14bobo5b3o$66b4o13b2o
13b2o5bo$64b2o4b2o33b2o$64b2o5bo$66b2obobo14bo$71bo14b2o$67bo3bo31bo$
67bo4bo30bo$69b3o3bo26bobo$69b2o4bo25b2ob2o$75b2o23bo5bo$77bo25bo$77b
3o20b2o3b2o3$80bo$79bob5o$78b2o5bo$78b2o3bo2bo$86bo$80b2obo2bo16bo$83b
o2bo3bo12b2o$84b2o3bobo$84b2o4b2o2$90b2o$90bo2$90bo$86b2o2b2o$85bobo$
86bo$82b2o$82b2o2bo$80bo4bobo$78b2o5bo$79b2o5b2o$87bo2bo2$88bo$89b2o$
87bo$85b2o$86b2o!

Thanks for the reply, but this isn't really what I meant.
1) First of all, it grows infinitely, and I specifically excluded such types of patterns in my rant.
2) The pattern you posted has a population of less than 256 cells, but definitely doesn't have MCPS within 256, which is what I was thinking of (maybe didn't make this clear enough). As I said, figuring out the exact value of MCPS is difficult, I believe in this case it's around 350. As we know from the RCT theory, basically anything is possible within 75 cells of 15 gliders, so MCPS must be taken into consideration with this kind of thought experiments.
3) There is some sort of logarithmic reaction here, but dimensions of the bounding box grow linearly, and the Summers/Nivasch logarithmic growth which I mentioned has the bounding box that grows logarithmically, which I believe is needed.

1) It does not grow infinitely, because the loaf fuse will eventually run out and then the resulting crash destroys both guns
2) if MCPS is limited, why is the Summers/Nivash logarithmic growth existing even relevant? you can't get unbounded L/MCPS with bounded MCPS even if you do have the Summers/Nivasch growth. You explicitly asked (emphasis original) "What is the simplest way you can think of to get arbitrarily high L/MCPS?"
3) Moving the far glider out increases the number of loaves linearly, which increases the lifetime exponentially

[melwin22]

1) It does not grow infinitely, because the loaf fuse will eventually run out and then the resulting crash destroys both guns
2) if MCPS is limited, why is the Summers/Nivash logarithmic growth existing even relevant? you can't get unbounded L/MCPS with bounded MCPS even if you do have the Summers/Nivasch growth. You explicitly asked (emphasis original) "What is the simplest way you can think of to get arbitrarily high L/MCPS?"
3) Moving the far glider out increases the number of loaves linearly, which increases the lifetime exponentially

Okay, turns out I don't have enough brain cells to understand the complexity of some patterns... And this one isn't even that complex...

Now, the question is: with MCPS limited to 1024, how long of a lifespan does this produce? Because even without the far glider, it seems to exceed 256. I'm guessing the answer will be beyond the heat death of the universe or something ridiculous like that.

[EvinZL]

1) It does not grow infinitely, because the loaf fuse will eventually run out and then the resulting crash destroys both guns
2) if MCPS is limited, why is the Summers/Nivash logarithmic growth existing even relevant? you can't get unbounded L/MCPS with bounded MCPS even if you do have the Summers/Nivasch growth. You explicitly asked (emphasis original) "What is the simplest way you can think of to get arbitrarily high L/MCPS?"
3) Moving the far glider out increases the number of loaves linearly, which increases the lifetime exponentially

Okay, turns out I don't have enough brain cells to understand the complexity of some patterns... And this one isn't even that complex...

Now, the question is: with MCPS limited to 1024, how long of a lifespan does this produce? Because even without the far glider, it seems to exceed 256. I'm guessing the answer will be beyond the heat death of the universe or something ridiculous like that.

The main part of the pattern seems to have an MCPS of around 270, so with an MCPS bound of 1024 you can have the far glider around 750fd away. The only valid adjustments are multiples of 60fd (30fd if you delete the glider in the middle), so you can shift the far glider 660fd away. Running this until the fuse burns out gives 15932 loaves, each of which multiplies the lifespan by 121. The first loaf gets destroyed at 31.5 million
generations, so the total lifespan would be around 10^76423

[Dylan Chen]

Why is the soup-search methuselah record frozen at 52513M? A source-level and statistical investigation

The soup-search methuselah record has been stuck at 52513M (52,513 generations, found by apgsearch on 2021-01-16) for nearly five years, even though the b3s23/C1 census has since grown several-fold to 3.34×10^14 soups, with 63% contributed by aggregated grid computing (Charity Engine / Open Science Grid, uploaded as TechnobladeNeverDies). I checked four candidate explanations against the apgmera/apgsearch source and one empirical test.

1. Is there a hidden max-generation cap near 52k? No.
There is no explicit maxgen parameter anywhere. The only ceiling is implicit in stabilisation detection (includes/stabilise.h): phase I (naivestab_awesome, line 19) runs at most 1000 iterations (~20k generations), and phase II (line 70) runs 4000 iterations × 30 gens = 120k more. Soups not stabilised by ~142k generations print "Failed to detect periodic behaviour!" and their debris is classified normally — so there is a structural truncation, but at ~140k generations, nowhere near 52k. The methuselah reporting threshold is 25,000 gens (includes/searcher.h:93), consistent with the documented v4.54+ behaviour.
2. Are over-limit soups silently discarded? No.
Unclassifiable ("pathological") objects trigger up to 5 retries with exponential backoff (step 120→480→1920→7680, searcher.h:276-306), and are ultimately still reported to the census as PATHOLOGICAL/zz_*. Nothing is dropped silently.
3. Does the BOINC/Charity Engine client use different limits? The mechanism doesn't exist.
All the thresholds above are hardcoded in stabilise.h/searcher.h — there is no per-soup wall-clock or generation parameter for a packaged client to turn down. And even if a grid job has a wall-clock limit, killing a job mid-haul loses all soups uniformly; it does not selectively kill long-lived ones (see timing below).
4. Does a 52k-generation soup take minutes and hit memory limits? No — measured.
I compiled apgluxe v5.2-ll2.5.9 (b3s23/stdin, AVX-512) and fed it the actual 52513M soup RLE on a weak single cloud vCPU. Full pipeline, including the expensive hashlife re-run that methudetect triggers for soups lasting ≥24,000 gens: 4.8 seconds wall-clock. Final population 5,054 cells, matching the LifeWiki infobox; measured lifespan 52,511 by apgsearch's population-periodicity definition (a 2-generation definitional difference from the official 52,513). Memory is tile-based, proportional to spatial extent, not generation count. (Full disclosure: the client auto-submitted a tiny anonymous 2-soup haul after the test; the server appears to have ignored it — the methuselah_52k bin still shows 1.)
5. So what's left? Ordinary extreme-value statistics — and the census's own data supports it.
The methuselah bin counts on Catagolue (25k: 2,010,120 → 52k: 1) have a remarkably stable ratio of ≈0.55 per 1,000 generations, i.e. an exponential tail with scale λ ≈ 1,700 gens. Extrapolating from the 35 soups in the ≥45k bins, the expected number of soups exceeding 52,513 gens in the entire 3.34×10^14 sample is ≈ 0.4–0.5 — we observe 1. The record is, if anything, slightly lucky. The probability that no record-breaker has appeared since January 2021 is ≈ 65%: the drought is the likely outcome, not an anomaly. The next record should land near 52,513 + λ ≈ 54k (not 60k+), and reaching it requires the sample size to multiply by roughly e — several more years at current rates.
Conclusion: the freeze is a statistical drought, not an engineering bug. If the community wants the record to move sooner, the effective lever is not client parameters but the search distribution itself — e.g. larger soup sizes, where long-lived methuselahs are denser.

[melwin22]

Why is the soup-search methuselah record frozen at 52513M? A source-level and statistical investigation

This is a cool analysis, but I'd like to point out that the mentioned record is held by 52513M in only one metric - its lifespan. Now, L might be considered the most important metric, but because I wanted to discuss in this thread all six metrics, I need to ask: what about the other ones?

Taking into account only those mentioned in List_of_long-lived_methuselahs, current records for naturalistic methuselahs are:
- F: 5828 cells (held by 35201M) - found in 2010
- L/I: 2967.9 (held by 47487M) - found in 2019
- F/I: 396.2 (held by 24827M) - found in 2017
- L/MCPS: 1941.7 (held by Lidka predecessor) - found in 2017
- as mentioned, I believe that F/L makes no sense, but nonetheless, record here belongs to gliders by the dozen at 0.701 - found in 1971.

Why are they all frozen?