Thread for basic questions

[dvgrn]

Wasn't there a browser Golly called 'Molly' or something? I can't find it but I seem to remember it was a little thing.

Yup. A forum search for "Molly" turns up the link right away, so I'm not sure how it was hiding from you.

At the moment it's kind of the luck of the draw what Golly functionality is included in Molly and what isn't. I don't know if Andrew and/or Chris are planning to do any further updates in the foreseeable future.

[Ethanagor]

Alright, this will hopefully be my last issue. Sorry for all of these posts. Anyhoo, I don't think that my search hauls are being properly uploaded. I checked my payosha256 tag and it says I have no hauls uploaded, even though I should. What might I be doing wrong?

[Saka]

APG: Adam P. Goucher
Coincidence? OR NOT???

[BlinkerSpawn]

APG: Adam P. Goucher
Coincidence? OR NOT???

Not, unless you're referring to something other than APGsearch.

[muzik]

Have any prime quadruplet calculators been built?

[BlinkerSpawn]

Have any prime quadruplet calculators been built?

Presumably, no, but the theory behind the twin prime calculator shouldn't be *too* difficult to extend.

[muzik]

What exact sieve does it use to generate those twin primes, anyway?



Also, why is it that the waterbear is the only engineered/engineerable spaceship that runs well on hashlife on high speeds? Caterpillar and centipede alongside the engineerable families are pretty sluggish, parallel HBK runs okish but jitters a lot as you speed it up, and I can't even run Gemini well on 8^0.

[gmc_nxtman]

Also, why is it that the waterbear is the only engineered/engineerable spaceship that runs well on hashlife on high speeds?

Because it's the smallest...?

[muzik]

Also, why is it that the waterbear is the only engineered/engineerable spaceship that runs well on hashlife on high speeds?

Because it's the smallest...?

Parallel HBK is smaller in terms of cell count. It does have a bigger bounding box but I doubt that affects anything.

[gmc_nxtman]

Parallel HBK is smaller in terms of cell count. It does have a bigger bounding box but I doubt that affects anything.

Waterbear also has a much lower period, allowing hashlife to run it much more efficiently. Generally Parallel HBK is a much more complex construct and higher period that takes more hashtiles to store. I don't think the bounding box affects it that much either.

[BlinkerSpawn]

What exact sieve does it use to generate those twin primes, anyway?

It uses the regular primer but adds an extension that is activated whenever a prime p shows up and only lets through the LWSS corresponding to p+2 if it appears.
I might be wrong but I think you could just have 3 of those filters in a row with something that lets them refresh if needed.

[muzik]

Parallel HBK is smaller in terms of cell count. It does have a bigger bounding box but I doubt that affects anything.

Waterbear also has a much lower period, allowing hashlife to run it much more efficiently.

Well that settles it then.

What exact sieve does it use to generate those twin primes, anyway?

It uses the regular primer but adds an extension that is activated whenever a prime p shows up and only lets through the LWSS corresponding to p+2 if it appears.
I might be wrong but I think you could just have 3 of those filters in a row with something that lets them refresh if needed.

But wouldn't such a thing let things like {97, 101, 103, 107} through and skip the 109?

[calcyman]

Parallel HBK is smaller in terms of cell count. It does have a bigger bounding box but I doubt that affects anything.

Waterbear also has a much lower period, allowing hashlife to run it much more efficiently. Generally Parallel HBK is a much more complex construct and higher period that takes more hashtiles to store. I don't think the bounding box affects it that much either.

It's also a quantitative issue rather than a qualitative one: every oscillator/spaceship has some RAM threshold beyond which HashLife will memoize every sufficiently small tile that the simulation can 'run away' exponentially quickly. I think I've managed to do this with the Caterpillar using several gigabytes of RAM.

Also, regarding your prime quadruplet discussion, Nathaniel has already done it (8 years ago):

http://www.njohnston.ca/2009/08/generat ... e-of-life/

...but there are more efficient primers now, so you can probably find a more compact solution.

[muzik]

Not to mention that its download links seem to be dead.

[dvgrn]

It's also a quantitative issue rather than a qualitative one: every oscillator/spaceship has some RAM threshold beyond which HashLife will memoize every sufficiently small tile that the simulation can 'run away' exponentially quickly. I think I've managed to do this with the Caterpillar using several gigabytes of RAM.

Yup, bounding box and population both turn out to be very nearly irrelevant in most cases. The number of distinct hashtiles does go up as the bounding box increases, but usually in a very large pattern there's enough repetition that the increase is closer to logarithmic than linear.

A pattern that's a factor of 100 bigger might need only slightly more memory to run -- or sometimes slightly less, or occasionally a lot less. The big deciding factor is the period, as gmc_nxtman mentioned -- with weird super extra bonus points if the period and spaceship step size both happen to be an exact power of two.

It's fairly easy now to build an oblique Geminoid or Orthogonoid that will use the 2^N trick to run as quickly in Golly as the waterbear does -- once Golly has seen all the hashtiles once. The simulation will crawl along for one cycle (for the Orthogonoid) or the first several cycles (for the oblique Geminoid) and then accelerate radically -- kind of like those standard space-movie shots of the Enterprise or the Millennium Falcon going into hyperdrive.

[gameoflifeboy]

The prime quadruplet calculator is still available in the LifeWiki pattern collection:

http://conwaylife.com/patterns/primequa ... ulator.rle

Based on the URL the pattern collection was moved to, this link appears to be the natural successor of the links given in the blog post. Before May 2011, the first would have led to an interactive Java applet containing the pattern, and the second to the RLE of the pattern, just like the link above.

I have alerted Nathaniel about the prospect of patterns in the collection unused on LifeWiki. Most of them seem to have been added when it was considered more of a personal pattern collection, but some of them, such as scrubber_with_blocks.rle seem to be genuine uninteresting patterns that don't belong there. As I recall, anyone could save any pattern in the online database via the Java applet before May 2011, so this isn't too surprising.

[drc]

Should this actually be described as period 8?

[muzik]

It probably should, since that's the period the whole pattern oscilltes at, right?

[Sokwe]

Should this actually be described as period 8?

The tagalong is period-8, but the orthogonal c/2 spaceship that pulls it is period-4.

[Saka]

Is there a way to find patterns that die in 1 generation? E.g.

Code: Select all

x = 8, y = 8, rule = B3/S23
3b2o$bo4bo$2b4o$ob4obo$ob4obo$2b4o$bo4bo$3b2o!

And extension by 1:

Code: Select all

x = 14, y = 14, rule = B3/S23
6b2o$4bo4bo$5b4o$3bob4obo$bo2b6o2bo$2b10o$ob10obo$ob10obo$2b10o$bo2b6o
2bo$3bob4obo$5b4o$4bo4bo$6b2o!

[Goldtiger997]

Is there a way to find patterns that die in 1 generation? E.g.

Code: Select all

x = 8, y = 8, rule = B3/S23
3b2o$bo4bo$2b4o$ob4obo$ob4obo$2b4o$bo4bo$3b2o!

...

Well, using WLS seems to work:

Code: Select all

x = 101, y = 53, rule = B3/S23
37b2obo11bobobo10bobobo12b2o$21b2o12bo16bobobo10bobobo10bo4bo4bob2obob
o$19bo16b4o11b7o8b7o9bob2obo5b4o$20b2obo11b2ob4o9b3o2b2o8b4ob2o8b8o3b
7o$4bo14b4o12b3obo10b7o10b3o2b2o7b5ob2o3b9o$4bo12b5o14b2ob3o8b5obo10b
3o2b2o8b4obo5b6o$3b3o13b2obo13b4o11b3o2b2o10b5o9b5obo3b9o$3b3o31b5o9b
7o9bob3obo9b4o5b7o$4bo30bo3bo12bobobo24bo3bo2bo4b6o$4bo34bo12bobobo14b
2o12bo6bobo2bo$95bo2bo7$80bo$2bobobo23b2o2bo12b2o17b2o10bo2bo$2bobobo
6b2o13bo4bo11bo18bo14b5o$b7o20bob5o11b2obo15b2obo9b4o$b3o2b2o4bob3obo
8b5ob2o10b4o2bo12b4o10b6o$4ob2o6b5o9b4o2bo11b3ob2o13b4obo7b5o$4ob2o5b
4obobo8b3o2b2o11b2ob3o11b5obo7b7o$b3o2b2o4b6o10b3ob3o11b6o11b5o10b4o$b
7o5bob2obo10b5o13b2obo13b3obo8bo$2bobobo6bo13bo3bo2bo10bo5bo11bo15b2ob
o$2bobobo8b2obo13bo32b2obo5$44bob2ob2ob2ob2ob2obo$26bo6bo$24bo2bob2obo
2bo9b2ob3ob2ob3ob2o$24bob8obo7b20o$26b2o4b2o11b16o$26bo2b2o2bo9b20o$
25b10o10b16o$25b10o8b20o$2bob2o2b2obo12b12o9b16o$3b8o12bob10obo9b14o$
2b10o13b10o11b14o$2b10o13b10o10b16o$b12o10bob10obo6b20o$b12o11b12o9b
16o$2b10o13b10o8b20o$2b10o13b10o10b16o$3b8o15bo2b2o2bo9b20o$2bob2o2b2o
bo14b2o4b2o11b2ob3ob2ob3ob2o$24bob8obo$24bo2bob2obo2bo8bob2ob2ob2ob2ob
2obo$26bo6bo!

Just fill the second generation with off cells, put some on cells in the 1st generation (or you'll just get dots), and tick find parents only.

[Saka]

Is there a way to find patterns that die in 1 generation? E.g.

Code: Select all

x = 8, y = 8, rule = B3/S23
3b2o$bo4bo$2b4o$ob4obo$ob4obo$2b4o$bo4bo$3b2o!

...

Well, using WLS seems to work:

Code: Select all

x = 101, y = 53, rule = B3/S23
37b2obo11bobobo10bobobo12b2o$21b2o12bo16bobobo10bobobo10bo4bo4bob2obob
o$19bo16b4o11b7o8b7o9bob2obo5b4o$20b2obo11b2ob4o9b3o2b2o8b4ob2o8b8o3b
7o$4bo14b4o12b3obo10b7o10b3o2b2o7b5ob2o3b9o$4bo12b5o14b2ob3o8b5obo10b
3o2b2o8b4obo5b6o$3b3o13b2obo13b4o11b3o2b2o10b5o9b5obo3b9o$3b3o31b5o9b
7o9bob3obo9b4o5b7o$4bo30bo3bo12bobobo24bo3bo2bo4b6o$4bo34bo12bobobo14b
2o12bo6bobo2bo$95bo2bo7$80bo$2bobobo23b2o2bo12b2o17b2o10bo2bo$2bobobo
6b2o13bo4bo11bo18bo14b5o$b7o20bob5o11b2obo15b2obo9b4o$b3o2b2o4bob3obo
8b5ob2o10b4o2bo12b4o10b6o$4ob2o6b5o9b4o2bo11b3ob2o13b4obo7b5o$4ob2o5b
4obobo8b3o2b2o11b2ob3o11b5obo7b7o$b3o2b2o4b6o10b3ob3o11b6o11b5o10b4o$b
7o5bob2obo10b5o13b2obo13b3obo8bo$2bobobo6bo13bo3bo2bo10bo5bo11bo15b2ob
o$2bobobo8b2obo13bo32b2obo5$44bob2ob2ob2ob2ob2obo$26bo6bo$24bo2bob2obo
2bo9b2ob3ob2ob3ob2o$24bob8obo7b20o$26b2o4b2o11b16o$26bo2b2o2bo9b20o$
25b10o10b16o$25b10o8b20o$2bob2o2b2obo12b12o9b16o$3b8o12bob10obo9b14o$
2b10o13b10o11b14o$2b10o13b10o10b16o$b12o10bob10obo6b20o$b12o11b12o9b
16o$2b10o13b10o8b20o$2b10o13b10o10b16o$3b8o15bo2b2o2bo9b20o$2bob2o2b2o
bo14b2o4b2o11b2ob3ob2ob3ob2o$24bob8obo$24bo2bob2obo2bo8bob2ob2ob2ob2ob
2obo$26bo6bo!

Just fill the second generation with off cells, put some on cells in the 1st generation (or you'll just get dots), and tick find parents only.

Thanks!

Code: Select all

x = 47, y = 36, rule = B3/S23
7bo6b2obo$3bo5b2ob5o2bo$3bo4b6o3b2o19bo$8b9ob2o3bo11bobo$3bo5bob2o2b2o
2b3o3bo10b3o$o2bo5bo5b2obob5o12bobo$2b4ob5obob2o3b5obo10bo$ob2o5bo4bo
2b3o3b2obo12bo$b5ob12obo4b3o$2bob6ob2ob2o9b3o$2bo13bo9bo$4b2ob2ob2ob2o
9bo2bo10$3bo15b2obob2obo$4bo12bo$3b4o10bob2obob2obo$3b2o11b6o$4b2obo8b
4o2b2ob2o3b2ob2ob2ob2ob2obo$3b3obo6bob4o2b7o$3b6o5bo2b2o4bo3b5ob2ob3ob
2ob2o$2b3ob3o3b17ob17o$2b6o6b2ob2ob3ob2ob5o3bo4b2o2bo$3bob3o22b7o2b4ob
o$3bob2o6bob2ob2ob2ob2ob2o3b2ob2o2b4o$6b2o29b6o$4b4o23bob2obob2obo$6bo
34bo$7bo23bob2obob2o!

[muzik]

If we let this run infinitely, will it ever become periodic, or will it grow chaotically forever, eventually producing negatives of basically every pattern known like gemini?

Code: Select all

x = 1, y = 1, rule = B123478/S01234678
o!

[drc]

If we let this run infinitely, will it ever become periodic, or will it grow chaotically forever, eventually producing negatives of basically every pattern known like gemini?

Code: Select all

x = 1, y = 1, rule = B123478/S01234678
o!

Considering it's running B3/S238 instead of life, I doubt gemini will even function properly

[BlinkerSpawn]

If we let this run infinitely, will it ever become periodic, or will it grow chaotically forever, eventually producing negatives of basically every pattern known like gemini?

Code: Select all

x = 1, y = 1, rule = B123478/S01234678
o!

If you look at it even in LifeViewer you'l notice that the corners start producing a sort-of-agar basically right away, so no.