ConwayLife.com

I've been running a (3,1)c/8 search in the background for the past year or so. The latest partials:

x = 120, y = 50, rule = B3/S23
10bo39bo49bo$8b4o37bob2o45b4o$7bo3bo37bo3bo43bo3bo$6b2o40bo47b2o$5bo3b
2o4bo32b3o2bo41bo3b2o4bo$8b2obo2bob2o29bo4b2o44b2obo2bob2o$6b2obo4bo2b
o30bobobo43b2obo4bo2bo ...

I'm amazed that indices in the bcol trees can be mere u32s for the sort of giant searches I have heard of people running with LSSS. I guess maybe having them split out per X position is enough of a difference?

It's that but also that LSSS only loads a small fraction the bcols for an X position ...

Is any of this like what LSSS means/does?

As I understand it yes this is like what LSSS does. However LSSS never reifies the full jcol prefix tree at once and leaves some of the relations implicit. I'm going to think about how I can improve the code comments to explain what is going on.

A jcol ...

Could there be any improvement on LSSS to make full use of CPU?
I tried to improve the performance through modifying [profile.release] in Cargo.toml but it only improved little and didn't make CPU fully used

Sorry I've been away from the forums for some time.

The difficulty is that LSSS can use ...

It looks like I'm finally getting close to disproving 4 row high gardens of eden, but I had to move the "rails" further apart. With the rails separated by 8 rows it looks like I will converge to a proof set sometime in the next couple of weeks.

A (3,1)c/8 partial that's been about a year in the making:

x = 28, y = 52, rule = B3/S23
10bo$10bo5bo$10b8o$8bo2b2o4bo$6b2ob2o4bo2b2o$6b2o4bobob2obo$6b2ob4ob2o
2bo$7bobo5b2ob3o2$3b5obo6b3obo$2bob4obo6bo$2bo3bo2bo7b3o$7bobo2bo2bo3b
2o$o3bob2obo2b2o3b2obo$b2o2bob2o2bo5bo$5b2o5b2obo$4bo10b3o ...

I am working on extending the proof to Gardens of Eden, i.e. cells outside the four rows in the target are specified as dead.

If I take a typical parent pattern that produces a given four row high sub-pattern it will often have a few stray live cells produced outside the four target rows. But if I ...

I should probably call out a distinction between live cells and specified cells. I haven't quite disproved Gardens of Eden where the live cells are restricted to four (consecutive) rows. But when the specified cells in the target generation, both alive and dead, are restricted to four consecutive ...

The proof consists of showing that there exists a set consisting of two columns from the parent generation and six "context" columns from the orphan candidate where any partial solution to an orphan candidate that matches an element of the set in it's last two columns and candidate context can be ...

They mutually annihilate gliders on a lot of lanes (the six adjacent lanes in the middle) and the other possible lanes get you pi explosions, honeyfarms, and (2,1) block moves -- none of which release any gliders, as long as there's enough space around the block.

In addition the results of pi ...

I've added some armor to the ash clearing. And it does work fairly well, I'm down to 1-2 stray gliders per 100,000 cells cleared. But it is also horribly slow. Despite the slowness of the current approach I think the evidence is strong that clearing ash at fairly large scales is possible. What I see ...

I was testing out some cleanups to the slice search program as well as a fix to a very silly bug in search.sh which caused it to fail almost immediately.

Anyway, the search seemed to be going well so I kept it going and found a 2c/7 spaceship:


x = 23, y = 42, rule = B3/S23
11bo$11bo$10bobo$11bo ...

Please try updating to the latest version of rust.

The command "rustup update" should update the version of the compiler.

Hi May13,

I've pushed out a fix for the bug. It impacted searches where k+1 == p (1c/2, 2c/3, 3c/4, etc.) and could cause spaceships to be missed. It might also cause inconsistent partials to be printed. It's not impossible to have a spurious "Potential Spaceship found" message even in the absence ...

May13 wrote: February 6th, 2022, 2:34 am I found a more serious bug.
LSSS fails after 0012/done with "No spaceship found for seedcolumn 02" for rule B2567/S4568, speed 2c/3, seedcolumn 02, margin 32 and odd-midline.

Thanks. I've reproduced the problem and am looking into it.

May I ask how you profiled your program and made the search CPU bound instead of I/O bound, namely analyzing I/O patterns and stuff?

I used the unix perf program for cpu profiling, and tweaked the compilation options so I had source information for perf to work with. With regards to I/O had an ...

I've made some additional progress in ash clearing, I now have a volley that can advance the eight corners of an octogon.

The is the probe volley:

x = 268, y = 179, rule = LifeHistory
214.C$164.C48.C.C48.2C$64.2C47.3C48.C48.C.C47.C2.C$64.2C98.C49.C49.2C
19$4.3A47.3A47.3A47.3A47.3A47.3A$6.A49.A49 ...

I'm not sure why it missed the original ship, but this search isn't nearly as long as the Soba one was, so maybe figuring out why it is missing things could be easier with this search


Hi AforAmpare, thanks for the report. Unfortunately I think in this case the discrepancy is probably just due ...

Right now NFTs seem to be about speculation, gambling on the future value of tokens. Gambling is not something I want a part in encouraging, and so I will not be participating in NFTs.

I've made some progress in clearing ash. Sending volleys along the face of the ash wasn't working out, but probing the ash in a raster scan is working much better. "Probe" is maybe not the right word as the volley doesn't return enough information to tell you want you encountered; it returns only ...

I have thought about this problem before, and it is a lot harder than it seems. The issue is that one needs to constrain what the "ash" is allowed to be with a set properties, and ensure that whatever interaction with it one considers, these must guaranty that these properties are retained ...

I was thinking about ways constructed patterns could clear the ash around them, and I have a partial strategy. It has some limitations:

It needs some free space around the ash field to work in.
It can't completely prevent secondary gliders/spaceships from being produced as the ash is being ...

Some more (3,1)c/8 partials


x = 113, y = 44, rule = B3/S23
7bo49bo29bo$6b4o45b4o27bobo$6bob2o45bo3b2o24b2obo$9bo45bobo3bo24b2o5bo
$8bobo40bo4b2o3bo22bo8b2o$4b2ob3o40b3o4bo3bo22bo8bob2o$5bo43bo2bo4bo2b
o23bo2b3o5b2o$3b2o4bob3o35b3o6bobo24b2o3bo2b2obo$2b2o4bo40bobo5b3o27bo
5b2obo ...

I've fixed up the use of the threads variable in the latest search.sh

Whereas before you would need to use the non-obvious:

threads="--threads 8"

It's now just:

threads=8

If you don't specify anything it defaults to the number of hardware threads.

Compiling the program now requires the latest ...

LaundryPizza03 wrote: April 28th, 2021, 10:55 am LSSS no longer works as is in macOS Big Sur.

It looks like the executable doesn't exist. Try running the command:
cargo build --release
before running the search script.