Thread for basic questions

[I6_I6]

Wow... those syntheses look like they come together using LV scripting commands. How do you even make those??

...

I was asking how the mechanism of the final step works as a whole. Thanks for the explanation anyway

[Chris857]

I know of this 3G synthesis of a constellation of eater1 and a block (plus other variants that construct the B-heptomino from different directions). Eater1 doesn't seem to show up in cheap constellations like this very often - compared to like how I can sometimes get 3 blocks in 4G, or something like a snake and tub in 5G - probably also since the cheapest eater1 is already 2G - and I don't know of systematic ways to search for whether a constellation includes a certain still life.

Code: Select all

x = 72, y = 75, rule = LifeHistory
15$24.A$22.A.A$23.2A13$38.2D$38.2D8$38.2D$38.D.D$40.D$40.2D5$23.A$23.
2A$22.A.A12$59.3A$59.A$60.A!

Are there any other similarly cheap (3G or 4G) interesting eater1 constellations?

[rabbit]

I know of this 3G synthesis of a constellation of eater1 and a block (plus other variants that construct the B-heptomino from different directions). Eater1 doesn't seem to show up in cheap constellations like this very often - compared to like how I can sometimes get 3 blocks in 4G, or something like a snake and tub in 5G - probably also since the cheapest eater1 is already 2G - and I don't know of systematic ways to search for whether a constellation includes a certain still life.

Code: Select all

x = 72, y = 75, rule = LifeHistory
15$24.A$22.A.A$23.2A13$38.2D$38.2D8$38.2D$38.D.D$40.D$40.2D5$23.A$23.
2A$22.A.A12$59.3A$59.A$60.A!

Are there any other similarly cheap (3G or 4G) interesting eater1 constellations?

This 3G synthesis piggybacks off the 2G eater to place an additional block:

Code: Select all

x = 9, y = 14, rule = B3/S23
7bo$6bo$6b3o$3bo$2bo$2b3o6$bo$2o$obo!

[WhiteHawk]

There have been several new small oscillators in the 100-200 period range discovered recently which use either uncommon active regions or common active regions emerging from unorthodox ancestors

Code: Select all

x = 139, y = 42, rule = B3/S23
15bo$14bobo$15bo$103bo8b2o14bo$60b2o41b3o6b2o12b3o$60b2o44bo18bo$105b
2o18b2o$54bo40bo$15b3o35bobo39b3o31bo$15b2obo35bo43bo29bobo$15b2o2bo77b
2o30bo$16bob2o$15b3o93b3o$110bo3bo$bo76b2o29bo5bo$obo5b3obo44b2o19b2o
29bo5bo8b2o3bob2o$bo6b5o34b2o8bobo49b3ob3o13b2obo$8bo3bo34b2o8bob2o$9b
obo46b2o$10b2o2$71b2o$30b2o38b2obo8b2o17bob2o13b3ob3o$30bobo38bobo8b2o
17b2obo3b2o8bo5bo$29bo3bo17b2o19b2o44bo5bo$29b5o6bo10b2o66bo3bo$29bob
3o5bobo78b3o$40bo$104bo30b2o$24b3o76bobo29bo$22b2obo50bo27bo31b3o$22b
o2b2o48bobo60bo$23bob2o49bo30b2o18b2o$24b3o81bo18bo$69b2o34b3o12b2o6b
3o$69b2o34bo14b2o8bo4$26bo$25bobo$26bo!

I therefore have 2 questions

1. Is there a reason behind this sudden rise in the discovery rate? Correct me if I'm wrong, but it does seem it has been a while since a SKOP rotor was discovered.
2. Is it more likely for an object hassling an uncommon object to have a higher period since the object itself is uncommon?

EDIT: Some more non-skop examples of what I am talking about

Code: Select all

x = 103, y = 53, rule = B3/S23
64b2o$53b2o9b2o$54bo19b2o$54bobo17bo26bo$55b2o15bobo24b3o$72b2o15b2o7b
o$77b2o10b2o7b2o$77bo$75bobo$12bo62b2o$12b3o10b2o$15bo9bo$14b2o7bobo29b
2o12b2o$2o21b2o30b2o10b2o2bo$bo68b2o29b2o$bobo22b2o42b2o29b2o$2b2o22b
o40b3o$24bobo59bo2bo$24b2o60bo2bo$86bo3bo$8b3o17b2o57b2obo$7bo3bo16bo
58b3o$26bobo68b2o$8b2ob2o13b2o69bo$56bo41b3o$2b2o13b2ob2o34b3o34b2o5b
o$bobo55bo33bo$bo16bo3bo29bo5b2o34b3o$2o17b3o30b3o41bo$55bo$4b2o48b2o
$3bobo57b3o$3bo22b2o34bob2o$2b2o22bobo33bo3bo$28bo34bo2bo$5b2o21b2o33b
o2bo$4bobo7b2o67b3o$4bo9bo35b2o29b2o$3b2o10b3o32b2o29b2o$17bo63bo2b2o
10b2o$82b2o12b2o3$76b2o$75bobo$75bo$53b2o7b2o10b2o$54bo7b2o15b2o$51b3o
24bobo15b2o$51bo26bo17bobo$77b2o19bo$87b2o9b2o$87b2o!

[WhiteHawk]

Another question

Yet I have no idea what the single-channel recipe for "push a block (3, 3)" or "extend elbow (3, 3)" is, or how I can even search for such a thing...

"extend elbow (3, 3)" -- i.e., push an elbow 3 full diagonals, which might be "(-3,-3)" in the usual coordinate system for these things -- can be found in slmake source, pp.txt -- line 21, I think? Or line 117, 135, 137, 149, but those recipes are longer so I don't know why they'd ever be used.

"push a block (3,3)" ... (or any other numbers -- I think what's really wanted is (3,-3) in the same coordinate system as above) can be done with a standard slmake compile. Use a LifeHistory input, and place just an output block at the appropriate offset from the input "hand" block. slmake should produce the single-channel salvo that makes the slow salvo that moves the block from input location to output location.

I could be confused about details here, but I usually un-confuse myself by experimentally adding recipes to see what happens, rather than by thinking too hard. No matter how hard I think I usually get something wrong on the first try anyway.

As a side note, it looks like a couple of the outer shells of the new almost-spiral-growth can be removed, since they're completely empty when the recipe is packed the tightest. This is going to be an impressively compact pattern when it's done!

Gosh... why are scripts just so difficult to use?! (No wonder why I have to do almost everything by hand.)

I tried to use slmake to generate a construction for such a block. At first, I ran into multiple problems trying to just compile slmake, but even after a successful compilation, I still could not for the life of me get slmake to not spit out a segmentation fault.

Then, I tried completing this without using slmake. Problem was, I knew very little about single-channel or even slow-salvo construction — and there wasn't even a place that I knew where I could get all the recipes for things like "(3, 3) block push". Eventually, I decided to steal a part of Hydra and Thessalonic Demonoid, which did the job, but this increased the total amount of gliders to 536, where almost half of them (261) were used just to get the blocks in place, and only half of them were the actual Snarkmaker.

Okay, here's that working spiral growth. There's probably something way more efficient out there for the first part, but I am not the one who has the ability to find it, at least for now.

Code: Select all

EDIT: for a comparison, the Snarkmaker-based extruder below only needs a storage of period 32768, whereas the spiral growth above needs a period of 65536:

Code: Select all

I think the original Snarkmaker may have needed less clearance for it's snarks, which I think begs the question: At what generation does the new spiral growth become larger than the old design in terms of BB? (and at that point how many snarks have been produced by each design)

[NNlk05]

How do I make something Hashlife optimised? I know the main thing is to make the pattern replete in steps of powers of two in both space and time. But if there's any other tips, that will be greatly appreciated.

[Chris857]

How do I make something Hashlife optimised? I know the main thing is to make the pattern replete in steps of powers of two in both space and time. But if there's any other tips, that will be greatly appreciated.

I seem to remember that you should also avoid having streams of gliders moving antiparallel (opposite directions) close to each other.

[EvinZL]

How do I make something Hashlife optimised? I know the main thing is to make the pattern replete in steps of powers of two in both space and time. But if there's any other tips, that will be greatly appreciated.

Yep Chris857's reply is correct. I'll give a conceptual overview of how HashLife works and why various HashLife-friendliness things exist.

Let's define a level-n metatick to be a step of 2^n generations. Now if we divide the grid into 2^n-by-2^n chunks every level-n metatick, then call each of those blocks a level-n hashtile. So for example every cell is a level-0 hashtile, and a level-1 hashtile is a 2x2 block on an even generation whose top left (x,y) coordinates are even. The general way to make something HashLife-friendly is to reduce the number of hashtiles.

Let's say you load up something like a loopship in Golly, which is one of the most HashLife-friendly large patterns out there. Let's say you set the step size to 2^10 and make one step. This is one level-10 metatick, and HashLife tries to run this by treating everything as a rule that operates on level-10 metatiles.

Most of the universe is empty space and gets ignored. But now HashLife doesn't know the transition rule when some of the hashtiles are nonempty, because it hasn't seen anything yet. To find it, HashLife recurses. Break down everything it doesn't know into level-9 metatiles and see if it knows the transition rule. It still doesn't, so keep on breaking down. Eventually this reaches the base case and it finally knows the transition rule. After doing everything HashLife has successfully ran the pattern for 2^10 generations.

Now let's say you run another step of 2^10. Most of the pattern consists of glider streams, which have moved (2^8,2^8) after stepping. So when HashLife does the recursion again once it reaches the size of level-8 hashtiles the vast majority of all the hashtiles look familiar. So it just remembers all of these results and runs everything quickly. When you run the third 2^10 step, the glider streams have moved (2^9,2^9) so now for most of the tiles the recursion stops when reaching level 9. Now this is even faster.

You continue and run it through an entire cycle. Let's say that this loopship is running at 2^16c/2^24 orthogonal. This is wonderfully HashLife-friendly. When you run it through the second cycle, all of the level-16 hashtiles are the same, so HashLife remembers their results and runs the next cycle extremely quickly.

This is a good example of power-of-two periodicity in space and time being good. Power-of-two periodicity allows many, many hashtiles to be reused. That's the entire point of HashLife. This is why on engineered patterns where periodicity is everywhere hashLife runs so well but on highly random patterns it's no better than QuickLife.

Now let's consider what happens when you have some antiparallel glider streams. For the small hashtile sizes everything works fine. The problem happens when the hashtiles get large enough to include portions of both streams. A hashtile large enough to contain both streams basically needs to store an arbitrary slice of one stream and an arbitrary slice of the other streams (subject to some power-of-two alignment). This makes the number of hashtiles needed quadratic in the stream length. Making the streams farther out helps, because then this problem shows up at larger hashtile sizes, and there are fewer large hashtiles. If you consider two streams of length l and distance d, then this problem shows up when the hashtile size reaches ~d. Then there are ~l^2 possible combinations, but since hashtiles are power-of-two aligned in space and time this cuts the number of hashtiles down to around ~(l/d)^2. Of course the best way to cut down hashtile usage is to avoid close antiparallel streams altogether, as in loopships.

[dvgrn]

I think the original Snarkmaker may have needed less clearance for it's snarks, which I think begs the question: At what generation does the new snarkmaker become larger than the old design in terms of BB? (and at that point how many snarks have been produced by each design)

Probably best to write some monitoring code for that in Golly. Could even display the two patterns in overlapping layers, and run them alternately 32768 ticks at a time until the new spiral growth gets bigger than the old spiral growth (I assume that's what "new snarkmaker" means.)

It wouldn't take too terribly long, since "old spiral growth" is an old slowpoke, only building a new elbow every 262144 ticks I think, whereas "new spiral growth" adds almost four elbows in that amount of time. Even if the clearance had been the same, the old pattern is going to get outgrowth-ed pretty quick.

[ThePlayzr]

I've never figured out how to do this; how do you make pattern tags automatically create a 2-state fill in generations rules?

[B468S02357]

Is golly finite

[I6_I6]

I've never figured out how to do this; how do you make pattern tags automatically create a 2-state fill in generations rules?

Use [[ RANDOMIZE2 ]]:

Code: Select all

#R /2/3
!
[[ RANDOMIZE2 ]]

EDIT:

Is golly finite

No, but you can make it finite:
https://golly.sourceforge.io/Help/bounded.html

[B468S02357]

What stable LWSS dupes & reflectors are there?

[dvgrn]

What stable LWSS dupes & reflectors are there?

There aren't any elementary LWSS reflectors. Direct X-to-LWSS converters are rare enough that we only have a few of them, with varying degrees of awkwardness -- needs a sparker, or output lane crosses input lane, or slow recovery time.

So a direct LWSS reflector is super improbable. An elementary stable LWSS duplicator is that level of improbability squared.

If you're okay with composite duplicators and reflectors, just string together whatever you need from the LWSS section of the Stable signal converters thread.

[WhiteHawk]

xs24_g88bbgz122bkhe2 in 16G, xs24_g88q5he8z1qq221 in 20G.

Code: Select all

Isn't the 3rd steps actually just restoring the original SL?

Code: Select all

x = 278, y = 43, rule = B3/S23
123bo6bo$124b2o2bobo$123b2o4b2o$249bo$250b2o$249b2o2$21bo$20bo$20b3o$
251bo$249bobo$17bo232b2o$17bo$17bo3$13b2o$12bo2bo136b2o118b2o$12bo2bo
135bo2bo113b2obo2bo$9b2obob2obo133bo2bo113b2obo2bo$9b2obo3bobo129b2ob
ob2obo114bob2obo$13b2o3bo129b2obo3bobo113bo3bobo$15b3o134b2o3bo114b2o
3bo$15bo138b3o117b3o$20b2o132bo119bo$19bo2bo$20b2o2$130b2o$25b3o101bo
bo$25bo105bo$26bo4$5b2o122b2o$5b2o123b2o$129bo$243b2o4b2o$3o241b2o2bo
bo$2bo240bo6bo$bo!

[Chris857]

Isn't the 3rd steps actually just restoring the original SL?

Kind of force-of-habit with that particular transformation. I figure to always include it in case coming from the other direction is ever somehow much cheaper, which I concede is unlikely in this case being already so cheap.

[NNlk05]

Can someone please explain what the do the Mateon symmetries do anyways?

[PK22]

Can someone please explain what the do the Mateon symmetries do anyways?

The Mateon1_(size)_Test symmetries generate soups of the given size - e.g Mateon1_32x32_Test generates 32x32 soups, and Mateon1_8k_Test generates 8192x8192 soups. They are avaliable in apgsearch v5 by default.

The Mateon1_Glider(a)_(b)_(c)_Test symmetries generate arrangements of gliders, where a is the number of gliders approaching from each direction, b is the 'width' (a wider width probably means the gliders are on more lanes), and c is the 'shift' (a larger shift means more distance between gliders).
By default, apgsearch only supports Mateon1_Glider6_5_6_Test and Mateon1_Glider8_4_5_Test, but it is trivial to modify samples.py and hashsoup.h in lifelib to support any test symmetry - e.g Mateon1_Glider3_3_3_Test.

[I6_I6]

Do [R]History rules behave differently in LV and Golly?
When running this pattern in LV...

Code: Select all

x = 8, y = 7, rule = LifeHistory
2.A$A.A$.2A$4.2E$4.E.E$6.E$6.2E!

...it evolves into this:

Code: Select all

x = 8, y = 7, rule = LifeHistory
.2B$B.2B$.3B$3.B2E$3.BE.E$6.E$6.2E!

But when running it in Golly, it evolves into this:

Code: Select all

x = 8, y = 7, rule = LifeHistory
.2B$B.2B$.3B$3.BCE$3.BE.E$6.E$6.2E!

This doesn't happen with [R]Super rules. Somehow, in LV, the state 4 (mark off) cells are remembering whether they used to be state 3 (mark 1) or state 5 (mark 2). In Golly, however, if a birth happens on a mark off cell, it will turn into mark 1 no matter what, even if the original mark off cell used to be mark 2.

It can't be that the rule definitions are different for the two programs, because when testing this pattern (which is gen. 2 of the first pattern in this post)...

Code: Select all

x = 8, y = 7, rule = LifeHistory
.BA$B.BA$.A2B$3.BDE$3.AE.E$6.E$6.2E!

...it behaves as expected in Golly.

[PK22]

Do [R]History rules behave differently in LV and Golly?
(...)

Yes. It's a performance optimisation.

[Citation needed]

Is this a soup?

Mine:

Code: Select all

x = 20, y = 20, rule = B3/S23
bob2obo2b5o4b2o$ob2obob2o4b3o2b2o$o2bo2b4obob2ob2obo$o2bo2bobo6bobo$o
3bo3bo$8b5ob2o2bo$bo4b2obob4o$3o2bo3bobo2b2o2b2o$bobo7bo2b2o2bo$2obo14b
o$3bobo2b2o4bo3b2o$b2o5b2o9bo$3ob2o3bob3o$o2bobo2b2obo2b2o2b2o$2b2o4b
2o4b4o$ob3o3b3o5bo$o2bo4b2obo4b2obo$3bobo2b2o3bo3bobo$bo6bo3bo2bob3o$
2obo2bo4bo3bobo!

[NNlk05]

Is this a soup?

Most likely no. They likely used backtracking software to generate a soup-looking pattern.

[WhiteHawk]

A 2c/5 orthogonal partial

Code: Select all

x = 6, y = 3, rule = B3/S23-a5
o2bo$2b3o$b2o2bo!

For a second I thought you accidentally posted in a thread intended for CGoL since that exact same 2c/5o tagalong works in CGoL. That being said, is there any spaceship here that supports it?

Is there a completion in life? (EDIT: Yes)

Code: Select all

x = 6, y = 3, rule = B3/S23
o2bo$2b3o$b2o2bo!

Also, what is the rulespace in which this reaction works?