Can we substantiate this claim?

[Book]

Snarkmaker article says 2428 gliders; Book (B.2) says 2427. Truth?

Both of the actual statements are true. The Snarkmaker article includes

"1 glider (suppressed by a single cell) showing where a second Snarkmaker recipe could be safely appended".

sneaky

[Book]

On the Infinite growth page, the following are said to be "asymptotic growth rates that have been explicitly constructed in Game of Life" but there are no examples to corroborate the claim:

tlog(t)^2 (found: Hickerson)
t^(1/3) (found: Hickerson)
t^(2^(-n))
log(n)(t)

[GUYTU6J]

In 2019, Ian07 made a commit to all-rules.txt that assigned the name "Majority" to b45678s5678 in catagolue, which is not totalistic (B45678/S5678 has B4 but no S3). What was the first source that referred to the particular outer-totalistic rule as such?

It could not be Mirek's rule lexicon, because according to this page "Majority" is an alternative name to Vote, b5678s45678 (and B5678/S45678 is totalistic), and the other use of "Majority" in lexicon is a Larger than Life rule.

Not sure. That could very well be a mistake on my part, apologies if so.

...
The issues of name origins is more serious than I thought. Many outer-totalistic names/aliases from LifeWiki's List of Life-like cellular automata or catagolue's all-rules.txt is not supplied by Mirek's Cellebration lexicon. Can someone uncover their namegivers?

[confocaloid]

...
The issues of name origins is more serious than I thought. ...

Knowing where names come from is less "serious" than it may seem.
This is a recreational-mathematics volunteer community. It should be rather obvious where most names come from.

It is perfectly reasonable and sometimes fun to wonder where a name came from.
Of course it would be nice to be able to understand where something came from - although this becomes more interesting for ideas, rather than for specific ways to refer to those ideas.

But it does not seem a particularly good idea to demand explanations/substantiations from others, just to get that knowledge at all costs. And sometimes you simply do not know where it came from, and maybe nobody knows, and it's better to accept that lack of knowledge and focus on something else, instead of asking again and again and again.

IMNSHO names are best served by letting people name things however they would like to, as long as that does not become a really serious problem. Please note that simply not knowing the sources does not count as "serious problem". Repetitive demands for "explanations" and "substantiations" seem much more serious problem.

I'd venture a guess that these questions are often left unanswered because they are basically repetitive and do not add anything new. Each time a variation on essentially the same question is repeated (here's a couple of previous examples: 2022, 2016), the likelihood of getting a good answer - or any answer at all - decreases. The more you demand, the less you get.

Would you call this post a particularly good reply to your question? I wouldn't. It might be because I'm not very good at answering questions. Or it might be because there is no particularly good answer to this particular question. Or something else.

[GUYTU6J]

Request for Stephen Silver's May 1998 original report of 12470 × 1 and 5447 × 1 infinite-growth patterns. I want to improve a reference on the one-cell-thick pattern page.

[dvgrn]

Request for Stephen Silver's May 1998 original report of 12470 × 1 and 5447 × 1 infinite-growth patterns. I want to improve a reference on the one-cell-thick pattern page.

Looks like the 1 x 12470 was never actually published:

Date: Mon, 18 May 1998 11:10:14 +0100
Subject: infinite growth pattern of width 1


Many months ago Nick Gotts conjectured that there exists a 1 x N infinite growth pattern. After working on this problem for a few days I finally produced a working example on Friday. This was 1 x 12470. On Saturday I rearranged the components and removed all the slack space I could find, reducing the size to 1 x 5447.

Here's the smaller version. Like my first attempt, this produces two block-laying switch engines.

Code: Select all

#C 1 x 5447 infinite growth pattern
#C SAS, 1998 May 16
x = 5447, y = 1, rule = B3/S23
105o63b41ob3o102b8o37b3ob41o89b25ob3o383b105o118b105o154b4ob105o298b
25ob3o172b41ob3o69b8o102b3ob41o91b105ob3o5b41ob3o63b8o293b8o63b3ob41o
390b3ob105o13b41ob3o63b8o30b3ob41o266b49ob4o101b105ob5o6b105o72b105o
383b3ob25o111b41ob3o37b8o102b3ob41o63b105o!

The switch engines appear at time 6671 at about (13,+/-177) relative to the centre of the pattern.

No doubt there are much smaller 1 x N infinite growth patterns. Does there exist a 1 x N pattern with quadratic growth?

--Stephen

[hotdogPi]

Unknown discovery years:

• Line of 6 spark: Recently added as 1970 on the wiki. Do we think a line of 6 would have been checked before all 12 pentominoes or not?

• Fleet and by extension ship-tie: It feels like this would have had to appear in 1970, but I can't find any evidence.

• Teardrop: It feels like this would have had to appear in 1970, but I can't find any evidence.

• Wing: It feels like this would have had to appear in 1970, but I can't find any evidence.

• Bakery and by extension half-bakery: Lifeline says 1971, but it could have appeared in 1970. Not guaranteed, though, as fishhooks aren't that much rarer and didn't appear in 1970.

• Dove: 1971 at the latest due to a 6-cell predecessor, but can't rule out 1970.

• Very long barge: I listed most 10-bit still lifes as 1972 a few months ago. I excluded this one because it could have been earlier.

• Very long canoe: I listed most 10-bit still lifes as 1972 a few months ago. I excluded this one because it could have been earlier.

• Very long ship: I listed most 10-bit still lifes as 1972 a few months ago. I excluded this one because it could have been earlier.

• Long^3 barge: I listed most 12-bit still lifes as 1973 a few months ago. I excluded this one because it could have been earlier.

• Long^3 ship: I listed most 12-bit still lifes as 1973 a few months ago. I excluded this one because it could have been earlier.

• Long^4 canoe: I listed most 12-bit still lifes as 1973 a few months ago. I excluded this one because it could have been earlier.

• Long^4 shillelagh: I listed most 12-bit still lifes as 1973 a few months ago. I excluded this one because it could have been earlier.

• Long^6 snake: I listed most 12-bit still lifes as 1973 a few months ago. I excluded this one because it could have been earlier.

• Mirrored table: I listed most 12-bit still lifes as 1973 a few months ago. I excluded this one because it could have been earlier.

• PT8P: Could this have been found before gourmet in 1978? It seems unlikely, putting PT8P at 1978.

[Book]

Can we substantiate: "The smallest predecessor to the clock that doesn't contain a clock itself has eight cells." (wiki clock article)

[dvgrn]

Can we substantiate: "The smallest predecessor to the clock that doesn't contain a clock itself has eight cells." (wiki clock article)

I'm not sure where that statistic came from, but it's not hard to prove the statement. Here I'll do it with JLS, in the first way that occurs to me. There's probably a better way with LLS or some other tool, but this seems to be sufficient to substantiate the claim.

We need to check three cases. if the predecessor doesn't contain a clock, then at least one of the three different cell types in a clock must be OFF rather than ON in a predecessor pattern with seven cells.

In JavaLifeSearch, if we set Search > Options > Constraints to "No more than 7 ON cells in generation 0", we can set up a clock in generation 1, and a single OFF cell in generation 0.

Code: Select all

[opening clocksearch0.jdf]
Search finished: 0 solutions found.
11484 iterations in 0.045 second(s).

[opening clocksearch1.jdf]
Search finished: 0 solutions found.
6181 iterations in 0.023 second(s).

[opening clocksearch2.jdf]
Search finished: 0 solutions found.
9908 iterations in 0.030 second(s).

As a sanity check, as soon as we set the constraint to "No more than 8 ON cells", we start getting solutions:

Code: Select all

x = 8, y = 8, rule = B3/S23
$bbo$4bobo$3bo$3bobo$bo$5bo!

[Book]

From the wiki polyplet article: "King-wise connectivity is a more natural concept in Life-like cellular automata than the orthogonal connectivity of polyominoes." By natural, does this mean the wiki def of natural?

[dvgrn]

From the wiki polyplet article: "King-wise connectivity is a more natural concept in Life-like cellular automata than the orthogonal connectivity of polyominoes." By natural, does this mean the wiki def of natural?

I'd say no. "Natural" here only means "comes to mind more readily" / "less artificially or arbitrarily constrained".

[Book]

can we substantiate this "did you know"...that there are over 35.4 billion distinct strict still lifes with 34 or fewer cells?

[dvgrn]

can we substantiate this "did you know"...that there are over 35.4 billion distinct strict still lifes with 34 or fewer cells?

Sure. They've all been enumerated. The 34-bit still lifes already number over 35.4 billion all by themselves, so we could bump that bounding number up by over two-thirds, by adding the other 23,792,551,043 still lifes with less than 34 bits (which have also been enumerated).

[Haycat2009]

Keith Amling somehow proved that 30P5H1V0 is the smallest spaceship of its speed. How on earth did he prove it without enumerating all 31-cell and below patterns?(Which will take at least a quadrillion years on a supercomputer)

[confocaloid]

Keith Amling somehow proved that 30P5H1V0 is the smallest spaceship of its speed. How on earth did he prove it without enumerating all 31-cell and below patterns?(Which will take at least a quadrillion years on a supercomputer)

"30P5H1V0" isn't really a thing as far as I know.
30P5H2V0 was confirmed to be the smallest 2c/5o spaceship, according to the post quoted below. I cannot claim understanding all the details, but if you know that your desired answer is going to be a 2c/5o spaceship in Conway's Game of Life (as opposed to an arbitrary <=31-bit pattern) then that knowledge can be used to avoid generating and testing everything.

2c/5 pop 32 died in what I suspect is the worst phase search. After that I went back and ran pop 31 which squeaked by, running ~6h on the fanciest machine and maxing out at 119.89GB RAM. It found only the known pop 30 ship. This confirms that ship is smallest and there are no ships with minpop 31.

I have completed some extremely sketchy hacks for LLSSS that allow a carefully constructed inefficient search to nonetheless, in some cases, exhaust all ships below a certain population in finite time. That is barring mistakes or bugs, which of course there could be at many levels.

[...]

For complex technical reasons the "in finite time" business breaks when the population bound allows for two independent ships, so pop 49 for c/3 is as far as I can go. It also means pop 9 is as far as I could go in c/4d and pop 17 in 2c/4 which I assume both aren't even worth running. I'll probably move on to c/2, c/4, and 2c/5 unless someone tells me something I don't know.

[confocaloid]

Snark64 says:

It is made up of a fishhook, chucklebait, two blocks, eater bridge eater, and a catalyst equivalent to BTS.

What is the intended meaning of "equivalent to BTS"?

I can replace xs17_39c8a6z0356 with BTS in Snark64 (top row in the pattern below). However, I could not replace BTS with xs17_39c8a6z0356 in the "typical catalysis" example shown on the BTS page (bottom row in the pattern below).

Code: Select all

x = 72, y = 60, rule = B3/S23
18bo39bo$17bobo37bobo$17bob3o35bob3o$14b2obo4bo31b2obo4bo$14bobobobobo
31bobobobobo$16bobob2o4b2o28bobob2o4b2o$8b2o5bobo8bo21b2o5bobo8bo$8b2o
6bo7bobo21b2o6bo7bobo$24b2o38b2o3$13b2o38b2o$12bo2bo36bo2bo$13b2o38b2o
4$b2o38b2o$obo37bobo$2bo18b2o19bo19b2o$8b2o10bobo25b2o10bo2bo$4b2obobo
10b2o22b2obobo10b3o$4bob2obobo32bob2obobo$10b2o3b2o3b4o26b2o3b2o3b2obo
b2o$15b2o4bo2bo30b2o4bob2obo$19bo3b2o36bo$19b2o39b2o10$bobobobobobobob
obobobobobobobobobobobobobobobobobobobobobobobobobobobobo13$15b2o38b2o
$17bo39bo$17bo39bo$15b3o2b2o33b3o3b2o$19bobo37bo2bo$19b2o38b3o2$19b4o
36b2obob2o$20bo2bo36bob2obo$18bo3b2o36bo$18b2o39b2o!

[Haycat2009]

bounding diamond area is nowhere near as easy to calculate as the bounding box.

How to proof? We can just tilt the whole thing by 45 degrees, tilt each indivisual cell 45 degrees and do the same thing as the bounding box calculation.

[confocaloid]

https://conwaylife.com/w/index.php?diff ... did=144079 claims "A gun optimised for population, such as Simkin glider gun..."
Actually, that gun is not "optimised for population" - it just happened to be small. So the claim is misleading.

bounding diamond area is nowhere near as easy to calculate as the bounding box.

How to proof? We can just tilt the whole thing by 45 degrees, tilt each indivisual cell 45 degrees and do the same thing as the bounding box calculation.

What is the bounding diamond area of this pattern?

Code: Select all

x = 7, y = 7, rule = B3/S23
5bo$4bo$4b3o$bo$obo$obo$b2o!

[Haycat2009]

https://conwaylife.com/w/index.php?diff ... did=144079 claims "A gun optimised for population, such as Simkin glider gun..."
Actually, that gun is not "optimised for population" - it just happened to be small. So the claim is misleading.

bounding diamond area is nowhere near as easy to calculate as the bounding box.

How to proof? We can just tilt the whole thing by 45 degrees, tilt each indivisual cell 45 degrees and do the same thing as the bounding box calculation.

What is the bounding diamond area of this pattern?

Code: Select all

x = 7, y = 7, rule = B3/S23
5bo$4bo$4b3o$bo$obo$obo$b2o!

33

[confocaloid]

What is the bounding diamond area of this pattern?

Code: Select all

x = 7, y = 7, rule = B3/S23
5bo$4bo$4b3o$bo$obo$obo$b2o!

33

(1) Why 33?

(2) Why not 27?

Code: Select all

x = 7, y = 7, rule = LifeHistory
4.DC$3.DC2D$2.2D3C$.C4D$CDC2D$CDCD$.2C!

(3) Why not 39?

Code: Select all

x = 9, y = 9, rule = LifeHistory
5.D$4.2DC$3.2DC2D$2.3D3CD$.DC5D$DCDC3D$.CDC2D$2.2CD$3.D!

(4) Considering these questions and answers (whatever they are), compare the degree of difficulty and degree of intuitiveness of the puzzle with that of calculating the bounding box area of the same pattern (which is obviously 7 x 7 = 49).

[azulavoir]

(1) Why 33?

Code: Select all

x = 9, y = 9, rule = LifeHistory
6.D$5.DCD$4.DC3D$3.2D3C$2.C4D$.CDC2D$DCDCD$.D2C$2.D!

33 is the value you get if you declare that bounding diamonds must have all four of their corners be at the center of a cell, which as far as I'm aware is the convention, and do so with the smallest possible expansion from the more strict 27.

[confocaloid]

[...]
33 is the value you get if you declare that bounding diamonds must have all four of their corners be at the center of a cell, which as far as I'm aware is the convention, and do so with the smallest possible expansion from the more strict 27.

Yes, 33 is the minimum that could be attained, if the bounding diamond must have single-cell corners.
However, I'm not sure about the part "is the convention". The wiki entry "bounding diamond" currently says "The diamond is diagonal lines meeting up with a side length of 1 or 2 depending on the size." (hence I think the example pattern above has bounding diamond area 27, according to that definition). The illustration in the embedded viewer also supports the definition where either 1 or 2 cells can be at each corner.

Either way, I believe it is fair to say that bounding diamond area is a significantly more complicated idea (and a more complicated calculation), in comparison to the bounding box area.

[dvgrn]

Yup, the bounding diamond article doesn't seem to agree with the width-1-corners idea. On the other hand, the bounding diamond article doesn't seem to line up with (what I think of as) the convention, in another way: it doesn't seem to allow for diamonds with two different side lengths. If "oblong diamonds" are not allowed, it doesn't seem like bounding diamonds would really be particularly useful for the stated purpose of "seeing how close a glider can be to an object without colliding".

The area count of 27 is what you get for another likely metric for glider guns, the "bounding octagon". Like the bounding diamond, the bounding-octagon area would theoretically be a "good" way of measuring the size of a gun (and, to some extent, its ability to pack multiple copies near each other). But it is more something you'd be likely to retrieve by running a script, especially for medium-sized patterns like glider guns, rather than by direct inspection of the RLE as can often be done to get the bounding box.

(Even when you don't bother to figure out the actual area -- by multiplying out the RLE width by the length -- you can often figure out how to adjust the components of a gun to make it a little less square, and thereby guarantee a new record. You can also make diamonds a little more oblong and get the same guarantee without doing the explicit calculation... but it gets quite a bit trickier when you start dealing with arbitrary octagonal shapes.

At some point you just have to calculate out all of the options and compare the actual areas, which can be kind of annoying -- at least right now, without tools to define standardized diamonds and measure their area. Pointless Optimization Game players are already used to bounding boxes.

[Haycat2009]

Pointless Optimization Game players are already used to bounding boxes.

Can someone give me a list of guns by smallest population? I want to help stop this Pointless Optimization (Which, by my opinion, is actually making it larger)

[dvgrn]

Can someone give me a list of guns by smallest population? I want to help stop this Pointless Optimization (Which, by my opinion, is actually making it larger)

This might be an interesting question to look at briefly, because there have been some new discoveries that might possibly have changed the standard answer -- like the new G-to-R. I'm not sure if that's true or not -- the G-to-R catalyst is pretty bulky, so maybe old Spartan stuff is still lighter-weight -- but there are other recent discoveries that might help, so maybe it's worth checking.

@Haycat2009, this topic comes up regularly every couple of years. There's a really good explanation for why people have been sticking with bounding box as the primary optimization metric for two or three decades now.

Start by reviewing Sphenocorona's response to the last iteration of this question.

There's not much need for a "list of guns by smallest population", because there's no need for a collection of them -- 99%+ of them (depending on how high you bother to go) are simple adjustable guns. So please don't take any steps to try to "help stop this Pointless Optimization" -- it's a fun game just the way it is, and it would be really annoying if someone tried to stop the fun.