amling search program principles discussion / brain dump

[amling]

also, I would appreciate greatly if diagonal width could specify on the granularity of half- instead of full-diagonals in a future version :mrgreen: thank you

...you could draw a constraint file with a half diagonal of forced zeros to make a search effectively one thinner...

As a demo of the half-diagonal masking constraint, let's run this search but with 35 half diagonal width (so one less on each side than the 37 we get from "@zero:12").

First, let's unwind what "@zero:12" does. But before that, let's see the geometry's stats:

Code: Select all

$ rlife grid-tool geom-info c4d-f2b
Geometry: c4d-f2b
   U: Vec3(1, -1, 0)
   V: Vec3(-1, -1, 4)
   W: Vec3(0, 0, 1)
   Neighborhood sizes:
      U: 3
      W: 9
   Unique positions (2):
      #0: Vec3(0, 0, 0) => Vec3Uvw(0, 0, 0)
      #1: Vec3(0, -1, 2) => Vec3Uvw(1, 1, 0)
   WAO maximal tile masks: WaoTileMasks(2 = 0b10, 3 = 0b11)

W neighborhood size of 9 tells me a normal init grid is 8 W rows tall. "Unique positions" of 2 tells me there are two tile bits and so my init grid in UWI view needs to be 12 (U) by 8 (W) by 2 (I):

Code: Select all

$ cat 1.in.uwi
| ............ | ............ |
| ............ | ............ |
| ............ | ............ |
| ............ | ............ |
| ............ | ............ |
| ............ | ............ |
| ............ | ............ |
| ............ | ............ |

But then let's convert that to XYT view:

Code: Select all

$ rlife grid-tool from-uwi c4d-f2b < 1.in.uwi > 1.in
$ cat 1.in
|                |                |            .   |            .   |
|            ..  |            ..  |           ...  |           ...  |
|           .... |           .... |          ....  |          ....  |
|          ....  |          ....  |         ....   |         ....   |
|         ....   |         ....   |        ....    |        ....    |
|        ....    |        ....    |       ....     |       ....     |
|       ....     |       ....     |      ....      |      ....      |
|      ....      |      ....      |     ....       |     ....       |
|     ....       |     ....       |    ....        |    ....        |
|    ....        |    ....        |   ....         |   ....         |
|   ....         |   ....         |  ....          |  ....          |
|  ....          |  ....          | ....           | ....           |
| ....           | ....           | ...            | ...            |
|  ..            |  ..            |  .             |  .             |

This is what "@zero:12" is producing here.

Now I want to constrain the NE-most half diagonal to zero, but where is that? It's in the third-to-last U column, but how do the tile indices map in? Let's mark the two tile indices in a UWI view and see...

Code: Select all

$ cat 1.test.uwi
| .........1.. | .........2.. |
| .........1.. | .........2.. |
| .........1.. | .........2.. |
| .........1.. | .........2.. |
| .........1.. | .........2.. |
| .........1.. | .........2.. |
| .........1.. | .........2.. |
| .........1.. | .........2.. |
$ rlife grid-tool from-uwi c4d-f2b < 1.test.uwi
|                |                |            .   |            .   |
|            ..  |            ..  |           ...  |           ...  |
|           .... |           .... |          2...  |          2...  |
|          12..  |          12..  |         .12.   |         .12.   |
|         ..12   |         ..12   |        ...1    |        ...1    |
|        ....    |        ....    |       ....     |       ....     |
|       ....     |       ....     |      ....      |      ....      |
|      ....      |      ....      |     ....       |     ....       |
|     ....       |     ....       |    ....        |    ....        |
|    ....        |    ....        |   ....         |   ....         |
|   ....         |   ....         |  ....          |  ....          |
|  ....          |  ....          | ....           | ....           |
| ....           | ....           | ...            | ...            |
|  ..            |  ..            |  .             |  .             |

So the second tile index is the more NE of the two so the constraint should look like...

Code: Select all

$ cat 1.cstr.uwi
| WWWWWWWWWWWW | WWWWWWWWW.WW |
| WWWWWWWWWWWW | WWWWWWWWW.WW |
| WWWWWWWWWWWW | WWWWWWWWW.WW |
(...many, many lines of the same...)
| WWWWWWWWWWWW | WWWWWWWWW.WW |
| WWWWWWWWWWWW | WWWWWWWWW.WW |
| WWWWWWWWWWWW | WWWWWWWWW.WW |
$ rlife grid-tool from-uwi c4d-f2b < 1.cstr.uwi > 1.cstr
$ # 1.cstr omitted because it's diagonally huge, but it looks like...
$ head -n 30 1.cstr.uwi | rlife grid-tool from-uwi c4d-f2b
|                     |                     |            W        |            W        |
|            WW       |            WW       |           WWW       |           WWW       |
|           WWWW      |           WWWW      |          .WWWW      |          .WWWW      |
|          W.WWWW     |          W.WWWW     |         WW.WWWW     |         WW.WWWW     |
|         WWW.WWWW    |         WWW.WWWW    |        WWWW.WWWW    |        WWWW.WWWW    |
|        WWWWW.WWWW   |        WWWWW.WWWW   |       WWWWWW.WWWW   |       WWWWWW.WWWW   |
|       WWWWWWW.WWWW  |       WWWWWWW.WWWW  |      WWWWWWWW.WWWW  |      WWWWWWWW.WWWW  |
|      WWWWWWWWW.WWWW |      WWWWWWWWW.WWWW |     WWWWWWWWWW.WWWW |     WWWWWWWWWW.WWWW |
|     WWWWWWWWWWW.WWW |     WWWWWWWWWWW.WWW |    WWWWWWWWWWWW.WW  |    WWWWWWWWWWWW.WW  |
|    WWWWWWWWWWWWW.W  |    WWWWWWWWWWWWW.W  |   WWWWWWWWWWWWWW.   |   WWWWWWWWWWWWWW.   |
|   WWWWWWWWWWWWWWW   |   WWWWWWWWWWWWWWW   |  WWWWWWWWWWWWWWW    |  WWWWWWWWWWWWWWW    |
|  WWWWWWWWWWWWWWW    |  WWWWWWWWWWWWWWW    | WWWWWWWWWWWWWWW     | WWWWWWWWWWWWWWW     |
| WWWWWWWWWWWWWWW     | WWWWWWWWWWWWWWW     | WWWWWWWWWWWWWW      | WWWWWWWWWWWWWW      |
|  WWWWWWWWWWWWW      |  WWWWWWWWWWWWW      |  WWWWWWWWWWWW       |  WWWWWWWWWWWW       |
|   WWWWWWWWWWW       |   WWWWWWWWWWW       |   WWWWWWWWWW        |   WWWWWWWWWW        |
|    WWWWWWWWW        |    WWWWWWWWW        |    WWWWWWWW         |    WWWWWWWW         |
|     WWWWWWW         |     WWWWWWW         |     WWWWWW          |     WWWWWW          |
|      WWWWW          |      WWWWW          |      WWWW           |      WWWW           |
|       WWW           |       WWW           |       WW            |       WW            |
|        W            |        W            |                     |                     |

Now this can be run as...

Code: Select all

$ rlife llsss --rule 'B3/S12' c4d-f2b 1.in --constraint grid:1.cstr:none --left-edge odd --filters wcaf

...and it's clear from the "Unique:" partials that there are 5 forced zero half diagonals on the NE side.

The "none" after "1.cstr" means that if the search exceeds the length of the constraint grid it will stop constraining it which isn't exactly desirable, but I can't think of any better way to do this without real code changes.

[amling]

I've just pushed a few weird features:

"PD" geometries which change the subtile search order to align with some period division. This would be for something like 2c4-s2s where normally the search order would be the four generations, in order, but you might want the third generation done before the second to allow a PD restriction to compare it to the first generation "earlier". I was unable to find a good quick demo of this, even though I could have sworn I had used a hack like this to make some PD project go faster somewhere in the distant past. You can compare the output of "rlife grid-tool geom-info" for "2c4-s2s" and "2c4-s2s-pd2" to see the difference. Or "4c8-s2s", "4c8-s2s-pd2", and "4c8-s2s-pd4".

I've added checks for recentering pre-reify autochoke for BIDX too big (e.g. you're using the default full jcols with u32s and you hit a bcol of would-be size > 2^32) and SSPs too big (spine store of would-be size > 2^32). Both cases are extremely unlikely for typical searches but I anticipate being useful on the 1TB RAM machine.

I added a "blocks" inertness that will consider any appropriately sized blocks cut from an input file to be inert. What "appropriately" sized means is sort of complicated and is different for inertnesses in closures versus inertnesses in SRV2. Every time it computes a set of blocks it displays the set so you can see what it sees. Probably best to just make the input grid file very large (and duplicate it for each subtile alignment!) to be sure. You could use this to allow an entire class of patterns to be considered inert hopefully without too much extra crud leaking in. For example, an appropriate grid could allow any size of chicken wire to be inert, or an appropriate grid could allow a particular seam between two agars to be considered inert.

[amling]

Unfortunately somewhere along the way LLSSS has again picked up weird technical limitations that make 10c30-s2s no longer work due to the giant tile size of 30 (I believe 16 is max for the first limitation I hit but there could be other breaks hidden behind it). I'm not sure how optimistic I would be about running a 10c30-s2s search even so.

I was able to make this (10c30-s2s searches) runnable by changing VB to u128 instead of u64 (slows down search generally) and hacking around a few more random limitations. TBD if anything useful comes of these 10c30-s2s seaches themselves.

In the meantime I am sketching some changes that should fix the main limitation for normal builds, making something like 21 generations just work and 43 work for VB=u128 (the main limitation is an entire W neighborhood of one spine's bits must fit in VB which for typical s2s geometries is 3 Y rows is 3 times the generation count). I want to make sure there is no major perf regression (it's definitely going to be theoretically slower for the code in question but I think it's generally only a very small part of searches and not that much slower) and then I will probably push the changes later today.

[mscibing]

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 prefix node in LSSS might look something like the following:

Code: Select all

struct JcolPrefixNode {
    bcol_prefix_node_index: u32,
    joined_bcol_prefix_node_index: u32,
    children_jcol_node_indexes: Vec<usize>,
}

The jcols are only instantiated for the current path through the bcol prefix tree as the tree is walked. This means the bcol_prefix_node_index can be left implicit and not physically realized. (The bcol_prefix_node_index would always match the `tp` member of `struct Level`) And the algorithm never needs to go from parent to to children for the jcol nodes once the children are created so children_jcol_node_indexes doesn't need to be physically realized either. JcolPrefixNode can thus be collapsed down to a single u32 for joined_bcol_prefix_node_index, and it is these u32's that are stored in `matches` in `struct Level`.

This does mean the work of applying the CA rules to create the jcol's needs to be re-done for every pass. But there are too many jcols to reify them all at the same time.

[amling]

Is any of this like what LSSS means/does?

As I understand it yes this is like what LSSS does...

Yes! Thank you for checking in here and helping me out.

I may try to reify the tree version of the bcol and see if that helps. I suspect I'm losing a lot of time bisecting down where the ranges split and I think I could maybe store a more quickly-walkable version of the tree.

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? I'm regularly having searches with just hundreds of gigabytes of state have bcols that are more than 2^32 long although these are for LLSSS recentering searches where there is just one giant, unified bcol for the whole state.

[LaundryPizza03]

You know what would be helpful? A way to cut off search at a specified depth. With this, I could run a systematic search for spaceships of a given speed and width in a given list (e.g. OT B0 where spaceships cannot be ruled out).

[amling]

You know what would be helpful? A way to cut off search at a specified depth. With this, I could run a systematic search for spaceships of a given speed and width in a given list (e.g. OT B0 where spaceships cannot be ruled out).

This was added some time back. `--halts w_pos:N` will halt the search if ever that step is run when the integer w_pos value is greater than or equal to the specified limit.

[mscibing]

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 into the in-memory tree(s) at a time. In my current run I reached almost 300 billion bcols for an X position at one point, far too many for a u32 if loaded in all at once. What you can do is iterate over the patterns in the one-column intersection region between overlapping bcols, and load in only the bcols matching the current pattern in the intersection region as a unit of work. What LSSS is doing is a bit messier, but this is the basic idea it is taking advantage of. That said, I suspect it is nearing the limit of u32s.

[amling]

I've reworked how the nfa/regex stuff works, ultimately dropping the extremely difficult to use "nfa" ends (which I assume no one but me has ever even considered using) and changing the "regex" ends to put the regex itself as colum headers in the grid. I've also changed it to be able to interpret wildcards according to similar rules to state init code.

Regexes here allow only asterisk to repeat, parens to group, and plus sign to union (pipe is taken by grid parser unfortunately). Columns that are regex metachars should be filled with underscores. Other columns that are tagged anything other than "u" will be checked for consistently (so use non-"u" for common columns you believe are the same if you want it to verify, otherwise just "u" everywhere).

As an example here is a very silly demo of finding one of two possible c/3 slices:

Code: Select all

$ cat ends1.grid
| (Z)*(uuuuuu+uuuuuuu)(Z)* | _.___***..._...**..__.__ | _.___****.._.*.**..__.__ |
| _.___*.**.._**.**..__.__ | _.___*..**._...*.*.__.__ | _.___*...*._.*....*__.__ |
| _.___..**.*_.*...*.__.__ |                          |                          |
$ rlife grid-tool to-uwi c3-f2b < ends1.grid
| (Z)*(uuuuuu+uuuuuuu)(Z)* |
| _.___***..._...**..__.__ |
| _.___****.._.*.**..__.__ |
| _.___*.**.._**.**..__.__ |
| _.___*..**._...*.*.__.__ |
| _.___*...*._.*....*__.__ |
| _.___..**.*_.*...*.__.__ |
$ rlife llsss-recentering-wao c3-f2b '@zero' --ends regex:ends1.grid 07
...
20250404 18:18:39 [INFO] End [thinnest] ():
20250404 18:18:39 [INFO] |            |            | ZZZZZZZZZZ |
20250404 18:18:39 [INFO] | .......... | .......... | .......... |
20250404 18:18:39 [INFO] | .......... | .......... | .......... |
20250404 18:18:39 [INFO] | ...*...... | ..**...... | ..***..... |
20250404 18:18:39 [INFO] | ..****.... | ..*.**.... | ..*..**... |
20250404 18:18:39 [INFO] | ..*...*... | ....**.*.. |            |
...
20250404 18:18:39 [INFO] End [thinnest] ():
20250404 18:18:39 [INFO] |             |             | ZZZZZZZZZZZ |
20250404 18:18:39 [INFO] | ........... | ........... | ........... |
20250404 18:18:39 [INFO] | ........... | ........... | ........... |
20250404 18:18:39 [INFO] | ...*....... | ...*....... | ..***...... |
20250404 18:18:39 [INFO] | ...***..... | ..**.**.... | .....**.... |
20250404 18:18:39 [INFO] | ...*.**.... | ..**.**.... | .....*.*... |
20250404 18:18:39 [INFO] | ...*....*.. | ...*...*... |             |
...

With wildcards you could implement quite a few of the existing ends from scratch (although generally the builtin implementations perform better). As an example hacking up GS odd ends in 2c4-s2s:

Code: Select all

$ cat ends2.grid
|  (u)* |  (u)* | (u)*  | (u)*  |
|  _y__ |  _y__ | _y__  | _y__  |
|  _W__ |  _W__ | _W__  | _W__  |
|  _Y__ |  _Y__ | _Y__  | _Y__  |
$ rlife llsss-recentering-wao 2c4-s2s '@zero' --ends regex:ends2.grid 07
...
20250404 18:21:32 [INFO] End [thinnest] ():
20250404 18:21:32 [INFO] |  ZZZZZZZZZ |  ZZZZZZZZZ | ZZZZZZZZZ  | ZZZZZZZZZ  |
20250404 18:21:32 [INFO] |  ......... |  ......... | .........  | .........  |
20250404 18:21:32 [INFO] |  ......... |  ......... | .........  | .........  |
20250404 18:21:32 [INFO] |  ......... |  ......... | ....**...  | ...*..*..  |
20250404 18:21:32 [INFO] |  ...**.... |  ..****... | ...****..  | ..*......  |
20250404 18:21:32 [INFO] |  ..**.**.. |  ..*...*.. | ..**.**..  | ..*...*..  |
20250404 18:21:32 [INFO] |  ...****.. |  ..*...... | ...**....  | ..****...  |
...
20250404 18:21:36 [INFO] End [thinnest] ():
20250404 18:21:36 [INFO] |  ZZZZZZZZZZ |  ZZZZZZZZZZ | ZZZZZZZZZZ  | ZZZZZZZZZZ  |
20250404 18:21:36 [INFO] |  .......... |  .......... | ..........  | ..........  |
20250404 18:21:36 [INFO] |  .......... |  .......... | ..........  | ..........  |
20250404 18:21:36 [INFO] |  .......... |  .......... | ..........  | .....*....  |
20250404 18:21:36 [INFO] |  .......... |  .......... | ....***...  | ...*...*..  |
20250404 18:21:36 [INFO] |  ...**..... |  ..*****... | ...*****..  | ..*.......  |
20250404 18:21:36 [INFO] |  ..**.***.. |  ..*....*.. | ..**.***..  | ..*....*..  |
20250404 18:21:36 [INFO] |  ...*****.. |  ..*....... | ...**.....  | ..*****...  |
...

I also reworked materially the API the between edges and the rest of the code. This made it easy for the agar edge to output a WARNING if it drops slices. Now when trying to run an input file where one edge does not end in enough zeros to extend you'll get a WARNING somewhere in there:

Code: Select all

$ cat bad.in
|       |       |       |       |
|       |       | uuRRR | ..... |
| uuRRR | ..... | ..... | ..... |
| ..... | ..... | ..... | ..?.. |
| ..... | ..?.. | ..?.. | *.?.. |
| ..?.. | ..?.. | ..?.. | ..?.. |
| ..?.. | ..?.. | ..?.. |       |
| ..?.. |       |       |       |
$ rlife llsss-recentering 2c4-f2b bad.in 10
...
20250404 18:25:49 [WARNING] LlsssEdgeAgar dropped 1/1 left edge slices due to not ending with zero agar
...

It's sort of buried in a lot of other output but hopefully operators that are suspicious of too-quickly-terminated searches will find it in the last round of expansion and find it helpful.



I added regex edges as well that are configured in a very similar fashion to regex ends. Namely rows are tagged with the regex on their left sides and it can handle some wildcards (namely those that are intratile, so for default config "W" and "2" through "9"). Partials are only forced to match a prefix of a valid match of the regex (which they could theoretically go on to be) so it can still "put off engaging your regex forever". Performance of this feature may get interesting for sufficiently large and complex edges. Maybe let me know if you're trying it for something.

Here is an example of searching for a c/4 back for a moon wave in seeds (using WAO to directly put the wave on the top would be better but this is just a demo). The regex forces it to receive exactly one (well, or zero as a prefix) copy of the wave whereas trying to do this sort of thing with the kgram edge would be unable to avoid partials that are receiving many.

Code: Select all

$ cat edge1.grid
| (__ | u.. | )__ | *__ |
| u*. | u.* | u.. | u*. |
| u.* | u.. | u.. | u*. |
| u.* | u.. | u.. | u.. |
| u*. | u.* | (__ | u.. |
| )__ | *__ |     |     |
$ rlife grid-tool to-uwi c4-f2b < edge1.grid
| (__ |
| u.. |
| )__ |
| *__ |
| u*. |
| u.* |
| u.. |
| u*. |
| u.* |
| u.. |
| u.. |
| u*. |
| u.* |
| u.. |
| u.. |
| u.. |
| u*. |
| u.* |
| (__ |
| u.. |
| )__ |
| *__ |
$ rlife llsss-recentering-wao c4-f2b --rule 'B2/S' '@zero' --left-edge regex:edge1.grid 08
...
20250404 18:36:24 [INFO] Shortest partial:
20250404 18:36:24 [INFO] |              |              |              | ZZZZZZZZZZZZ |
20250404 18:36:24 [INFO] | ............ | ............ | ............ | ............ |
20250404 18:36:24 [INFO] | ............ | ............ | ............ | ............ |
20250404 18:36:24 [INFO] | ....*....... | .....*...... | ....*....... | ...*.*...... |
20250404 18:36:24 [INFO] | ......*..... | .....*.*.... | *...*....... | .*.*..*..... |
20250404 18:36:24 [INFO] | .......*.... | *.....*..... | .*...*.*.... | ..*.*.*..... |
20250404 18:36:24 [INFO] | ............ | *........... | .*.......... | ..*...*..... |
20250404 18:36:24 [INFO] | ............ | ............ | *........... | .*....**.... |
20250404 18:36:24 [INFO] | ..*..*...... | ............ | ......**.... | ............ |
20250404 18:36:24 [INFO] | ........*... | ......**.... | ............ | .....**.*... |
20250404 18:36:24 [INFO] | .......*.... | ............ | ....*...*... | ............ |
20250404 18:36:24 [INFO] | ...*..**.... | ....**..*... | ............ | ...**....... |
20250404 18:36:24 [INFO] | .....*...... | ............ | ...*........ | ....*....... |
20250404 18:36:24 [INFO] | .....*.**... | ....*....... | .....*...... | .......**... |
20250404 18:36:24 [INFO] | ............ | ......*..*.. | .....*.**... | ............ |
20250404 18:36:24 [INFO] | ........*... | .......*.... | .....*...... |              |
...

Hopefully it goes without saying, but if you find yourself using (or trying to use) any of this we might all benefit from you dropping your plans/files/whatever here for a consult. Nothing about these implementations are set in stone and I might be able to help you make your search work and you might be able to help me make the features better.

[amling]

I was thinking about optimizing patterns systematically and finally sketched some of my ideas. Unfortunately I'm not quite sure I can make it work...

The basic idea is that for a given pattern viewed as a given LLSSS geometry you could take a UVW prism out and run an LLSSS fixed board search constraining the top, sides, and bottom to match the existing boundary. Once it has reached the bottom you can analyze what's left in the state file for the minimum solution according to some notion of weight.

I sketched something to do this although there are a lot of questions:

*) What weight? I chose count of cells in all generations since it was easy to implement and corresponds roughly with bigger/smaller pattern.
*) What UVW prisms? I chose to have a specified minimum size (default of AF2 by one W overlap) and consider all UVW prisms, partially ordered by inclusion, and run them in some total order extending that where I break ties by the maximum memory used in any of their child rectangles' searches. This corresponds roughly to running them in order of maximum memory required which seems reasonable. This partial order is enormous so I did some tricks to only build parts of it as they are reached.
*) What to do after update? I chose to invalidate all rectangles that overlap any changed cell, requeuing them, and thereby sort of start over.
*) How to constrain search additionally? Especially how to prevent it from being replaced globally with zero? The boundary AF1/W overlap of course can never be changed and for now I've added "f" and "F" markers to force a cell off/on. If this project works out eventually we might make more general constraints (like allow a separate grid, allow PD wildcards there, allow implicit forcing of existing non-PD cells, allow implicit forcing of PD-ness where it already exists, etc.).

For testing this I considered trying to optimize this obviously-silly c/2 arm (from the very first completion of the 4c/8 tub puffer):

Code: Select all

| .................................... | .................................... |
| .................................... | .................................... |
| .................................... | .................................... |
| .................................... | .................................... |
| ..........*......................... | .........***........................ |
| .........***........................ | ........*...*.............*....*.... |
| .......**.***............***..***..* | .......**....*...........***.**.**.* |
| ........*..*.**....*....*...*.***.*. | ......*.*.**.**...***..**.**.......* |
| .....**.*....*.*.**.**.**.....*.*... | .....**.*....*.**.***.*....**.*.*.** |
| .....**.*.*..*.*.......***.**.....** | ....*....*...*....*.*....*.......... |
| .....*........***.*.*.**............ | ................*.....**............ |
| ....**.......**..................... | ....**.......**..................... |
| .................................... | .................................... |
| .................................... | .................................... |
| .................................... | .................................... |
| .................................... | .................................... |

There are reasons why you might prefer f2b or s2s, but neither really does very well. The both do eventually optimize it down but they spend a ridiculous amount of time running endless very tiny searches and LLSSS search just doesn't scale down well (between various startup overheads and parallelization overheads), even with all the hacked optimizing I did for this prototype. In the end f2b runs 456,719 searches here which is just silly (ending in a run of the entire board, although ~300K of the searches are run before it finds its final update). It's hard to say what to make of the time since it's on a highly loaded, not particularly impressive computer but even so I think the ~14h (~10h before final update) is not good and bodes poorly for real world use.

One possible trick would be to force all windows to be full W width or full U width. This is more analogous to what rstatoropt does and skips a bunch of small searches. For this particular case the various combinations of s2s/f2b and full U/full W run in 2m to 20m or so which is better but I'm concerned real world cases will not be tenable this way.

I guess I'm mostly just musing into the void. I'm perhaps most interested in as-small-as-possible real world test cases if anyone can think of anything that might be in range. Otherwise I might just shelve this.

[amling]

I was running some more seeds 3c/5 searches to try to figure how best to use (recentering) pre-reify-autochoke. For simplicity I was searching just odd and trying to see what I could get with less memory and less human intervention than how the original 3c/5 ship was found.

Based on my notes when I ran these on the big 1TB RAM machine mid_steps=47 had completed with no results, using 161 GB. Testing more recently mid_steps=46 did not complete with 60 GB on the laptop I was doing this on.

I ran a line of searches of increasing mid_steps limited to pre-reify-autochoke 1 GB and they tended to fall into that pyramidal failure mode where they get wide real fast at the bottom and are clearly never going to solve.

I restarted the line of searches limited to pre-reify-autochoke 24 GB which is about what I thought I could afford for 60 GB of actual memory. mid_steps=46 and 47 completed with about 55 GB memory and a few days total, but then for mid_steps=48 the search really took off and even though it would bounce against the memory ceiling often it always retained enough good-enough stuff in the state to continue, again maxing around 55 GB. This continued a little over a month until it finally got lucky last night and found some back rakes and then on to this morning when it found a complete ship.

So what does it mean for pre-reify-autochoke? I guess my best current theory/hope is that that pyramidal failure mode is what happens when you don't have enough memory and when you have enough memory a sufficient mid_steps search (or an unlimited one) may get lucky. I'm still a little unsure on the difference between large fixed mid_steps like 48 and unlimited although I am hesitant to run another month of searches to find out...

I have some ideas about other experiments to run so perhaps more on this later.

[amling]

Perhaps I understated it in the previous post, but I think finding a 3c/5 seeds ship this way is a huge deal, having used vastly, vastly less time (a month instead of many months), human intervention (none!), and memory (55 GB versus multiple TB) than the previous 3c/5 result.

For further testing, I ran a bunch of asymmetric one-arm searches starting from the known common 3c/7 front, of the sort that will find 232P7H3V0. Unbelievably these days it takes not even 2 GB and not even 10 minutes to find it this way so maybe this sort of test isn't big enough to draw representative conclusions from, but here is what I got...

Inspecting the arm of 232P7H3V0 carefully in UWI view, it should take mid_steps=09 for the normal lower bound of what is guaranteed to be found by searches to cover it. Empirically mid_steps=08 does not find it while mid_steps=09 does in 653 MB max estimated pre-reify memory and about 8 minutes (on this laptop).

Running mid_steps=09 searches with pre-reify-autochoke 128 MB does not find it, 256 MB does (in 380s), and then 192 MB and 224 MB do not. The property of finding it is not necessarily monotone, but in practice I assume it is probably mostly monotone so I infer "224 MB is not enough" and "256 MB is".

At this point I'm mostly trying to decide if I should be running projects with unlimited mid_steps or with increasing fixed mid_steps so next I ran 256 MB with unlimited mid_steps. This finds it as well (in 1010s). After this I ran 224MB with mid_steps=12 through 16 and then unlimited mid_steps as well. Unlimited mid_steps ultimately looks like a doomed pyramid and mid_steps=12 through mid_steps 16 sort of look like progressively longer prefixes of that same pyramid. I guess I infer both increasing fixed mid_steps and unlimited mid_steps cover about the same ground although maybe reveal it in a different order. For 224 MB unlimited mid_steps took about the same amount of time as mid_steps=15 and 16 combined which suggests the total time for unlimited mid_steps is lower but with 256 MB mid_steps=09 found the target faster that unlimited mid_steps so I guess it comes down to what you want to prioritize...

I think my plan for future real search projects is to try more unlimited mid_steps runs and make subjective calls by eye to terminate them when they are getting too badly pyramid-shaped. I don't really like this required subjective human intervention but I'm not sure what else to do and I think pre-reify-autochoke is valuable enough to merit further use and testing.

EDIT: Before I forget some more, Sokwe, can you give any sort of summary of your use of/experience with this feature? How are you structuring your search projects that have used it?

[Sokwe]

Sokwe, can you give any sort of summary of your use of/experience with this feature? How are you structuring your search projects that have used it?

I probably don't have any particularly special insight. I find it most useful when there are not too many partial results at a low width. If there are too many low-width partials, then the autochoke quickly reduces the width so low that there are no viable solutions.

I typically start by running a search at a particular width using a very low autochoke memory limit so that the search will finish quickly (usually 10MB to 50MB). I then increase the memory limit (typically to between 100MB and 500MB) to see if I get better looking results. If I don't perceive an improvement in the partial results when increasing the memory limit, I will then increase the width while continuing to use the higher memory limit.

I tend to find autochoke most effective when there are very few viable front ends up until some fairly large width at which point there are so many that the search quickly fills up memory. This is demonstrated with a 2c/2 search in B2357/S3678, as discussed here.

[amling]

I was thinking some more about this whole same ship multiple rule search business. Previously I had given up on any hope of finding a ship that behaves differently in two rules but matches in (possible just) one generation. Today I was thinking about how we could possibly jam multiple bit states into LLSSS to do this when I realized we maybe don't actually need to.

Instead we can run these in the style of the catalyst "unwrap V" searches, namely: run in a doubled geometry with W forced to Y (e.g. c/2 f2b becomes 2c/4 with w=Y which is raw:1:0:0:0:-2:4:0:1:0), add a constraint to force the first generation to match the generation V/2 off from it, and, finally, rig the CA checks to depend on the generation with the first half running in one rule and the second half run in another. This last step is the most complicated but it is still way easier than trying to ready all the code for dealing with multi-bit cell states.

I've sketched this locally and will probably try (B35/S23, B3/S23) first but we sort of anticipate only negative results and so I am in the market for some test cases. Does anyone have an easy, ideally small example of a velocity and a pair of rules where there are known shared ships but only in this weak sense (match in one generation)?

[confocaloid]

[...] I've sketched this locally and will probably try (B35/S23, B3/S23) first but we sort of anticipate only negative results and so I am in the market for some test cases. Does anyone have an easy, ideally small example of a velocity and a pair of rules where there are known shared ships but only in this weak sense (match in one generation)?

If I understand correctly, the spaceships must have the same period, the same speed, and a shared phase?

Without further restrictions, here's a pair of p5 orthogonal 2c/5 spaceships where the shared phase is oriented the same way relative to the direction of movement:

Code: Select all

x = 4, y = 7, rule = B3-jn4nz5-ae6ckn/S1e2-ek3-ejnq4kn5iq6a7e
2o$obo$o2bo$bobo$o2bo$obo$2o!
#C [[ GRID ]]

Code: Select all

#C This is the glider 3736: https://conwaylife.com/forums/viewtopic.php?f=11&t=5886
x = 4, y = 7, rule = B35/S23
2o$obo$o2bo$bobo$o2bo$obo$2o!
#C [[ GRID ]]

If the difference between two rulesets needs to be "small" (under some metric, such as the number of differing outer-totalistic rules or the number of differing isotropic rules), I don't currently have realistic examples where people attempted to find shared spaceships but found none, but there were some spaceships with a shared phase.

edit: removed incorrect example.

EDIT 2.5: the following example might be better; it's two slightly different p3 orthogonal c/3 spaceships; the only difference between the two rulesets is the survival rule S2k (in the former case) vs. the death rule D2k (in the latter case):

Code: Select all

x = 3, y = 4, rule = B3aij4a5r/S2k3a4aqr
2bo$3o$3o$2bo!
#C [[ GRID ]]

Code: Select all

x = 3, y = 4, rule = B3aij4a5r/S3a4aqr
2bo$3o$3o$2bo!
#C [[ GRID ]]

and I couldn't find any p3 orthogonal c/3 spaceships that would exist (with identical evolution) in both B3aij4a5r/S2k3a4aqr and B3aij4a5r/S3a4aqr.

[amling]

The following example might be better; it's two slightly different p3 orthogonal c/3 spaceships; the only difference between the two rulesets is the survival rule S2k (in the former case) vs. the death rule D2k (in the latter case):

Code: Select all

x = 3, y = 4, rule = B3aij4a5r/S2k3a4aqr
2bo$3o$3o$2bo!
#C [[ GRID ]]

Code: Select all

x = 3, y = 4, rule = B3aij4a5r/S3a4aqr
2bo$3o$3o$2bo!
#C [[ GRID ]]

and I couldn't find any p3 orthogonal c/3 spaceships that would exist (with identical evolution) in both B3aij4a5r/S2k3a4aqr and B3aij4a5r/S3a4aqr.

Perfect! This completes with no results:

Code: Select all

rlife llsss-recentering-wao c3-f2b '@zero' --rule 'B3aij4a5r/S3a4aqr!2k' XX

But the sketched hacks programmed with the two rules find (first) this:

Code: Select all

20250427 21:40:05 [INFO] End [thinnest] ("LlsssEndsAgar", "zero"):
20250427 21:40:05 [INFO] |          |          |          | ZZZZZZZZ | ZZZZZZZZ | ZZZZZZZZ |
20250427 21:40:05 [INFO] | ZZZZZZZZ | ZZZZZZZZ | ZZZZZZZZ | ........ | ........ | ........ |
20250427 21:40:05 [INFO] | ........ | ........ | ........ | ........ | ........ | ........ |
20250427 21:40:05 [INFO] | ........ | ........ | ........ | ........ | ...**... | ...**... |
20250427 21:40:05 [INFO] | ........ | ...**... | ...**... | ..****.. | ...**... | ..****.. |
20250427 21:40:05 [INFO] | ..****.. | ...**... | ..****.. | ...**... | ..*..*.. | ........ |
20250427 21:40:05 [INFO] | ...**... | ..*..*.. | ........ | ...**... | ...**... | ...**... |
20250427 21:40:05 [INFO] | ...**... | ...**... | ........ | ........ | ........ | ........ |
20250427 21:40:05 [INFO] | ........ | ........ | ........ | ........ | ........ | ........ |
20250427 21:40:05 [INFO] | ........ | ........ | ........ |          |          |          |

[Katrina]

How does one put partials that have been output from llsss-recentering-wao and use that as a .in file for a wider search?
Example:

Code: Select all

|                            |                            |                            |     SS                     |     SS                     |
|     SS                     |     SS                     |     SS                     | ZZZZZZZZZZZZZZZZZZZZZZZZZZ | ZZZZZZZZZZZZZZZZZZZZZZZZZZ |
| ZZZZZZZZZZZZZZZZZZZZZZZZZZ | ZZZZZZZZZZZZZZZZZZZZZZZZZZ | ZZZZZZZZZZZZZZZZZZZZZZZZZZ | .......................... | .......................... |
| .......................... | .......................... | .......................... | .......................... | .......................... |
| .......................... | .......................... | .......................... | .......................... | .......................... |
| .......................... | .......................... | .........*................ | ........*................. | .......****............... |
| .........**............... | ........***............... | .......***................ | ......******.............. | ......*.**..*............. |
| ........***............... | .......**.*............... | ......**..***............. | ......**....**............ | .....**...****............ |
| ......**.*...**........... | ......**.*.***............ | .....*...******........... | ......*.**..**............ | .....**.**.*.............. |
| ......**.*.***............ | .....***.*..***........... | .....*...*....*........... | ....**..**..****.......... | ....****.**.*..**......... |
| .....*...**...*........... | ......********............ | .....***.***...*.......... | ....**.*.*....***......... | ....***..****...*......... |
| .....*..*....*............ | ....*....*...***.*........ | .....***.*.*...**......... | .....*...*.**.***......... | ....**.*.**..*...*........ |
| ....*...*....**.***....... | .....*.*.*...***.......... | ......*.*...*..**......... | .....**.**....**.*........ | ......*******.*........... |
| .....*..*.....*........... | .......*.....**...*....... | ........*....*..**........ | .......*.*..**..*......... | ......**.**.**.***........ |
| ......*......*.****....... | .....*.*......****........ | ........*....***.......... | .......***..**.*.*........ | ......**...****.*......... |
| ......*...*.....**........ | .....*.*......*........... | .......**....**.**........ | .......*....*...*......... | ......**...**.....*....... |
| ......*..*.*...****....... | .......**.*.*.**..*....... | ......*....**.**.......... | .......*....********...... | ..............*****....... |
| .......**...**.*.*........ | ...........****..*.*...... | ...........*....*.***..... | ..........*****..*.*...... | ...........*.......**..... |
| ............**....***..... | ............***.*..***.... | ...........*..**..*.*..... | ............*******.*..... | ..........*...*****.**.... |
| ...............*....***... | ............**........*... | ............****...*...... | ...........**...*..***.... | ...........*.........*.... |
| ............*.......***... | ................*..**.*... | ............*.**....*.**.. | ...........**.********.... | ..........*...**.......... |
| ...........*...*.**..*.... | ............*****...***... | ...........**...***.**.... | ...........***.*.**.****.. | ...........*.***..*...*... |
| ............*****......... | ...........******.**...... | ...........*......**..*... | ............*...*...**.... | ...........***.**.**...... |
| ...........**.*..**.*..... | ............*...***.**.... | ................***.*..... | ............*...**..**.... | ...................*.*.... |
| .............**.*.****.... | ...........***.*....*..... | ............**.*.*.***.... | ...................**..... | ............*****.****.... |
| ............*....**....... | .............****...*..... | ................**.*...... | ............****...*...... | ..............***.**...... |
| ..............**.***...... | .............**.***....... | .............**.****...... | ...............**..**..... | ............*...***.*..... |
| .............*.*......*... | .................*.*...... | .............*..*..**..... | ............*****.***..... | .............*....*..*.... |
| ..............****.*...... | ............*....**.**.... | .............*..*...*..... | ............*.****.***.... | ...........**.*.**...*.... |
| ............***.**.***.... | .............**.***.*..... | ...........**..**...**.... | ..........**......***..... | .........*..**............ |
| .............*............ | ..........**...*.****..... | .........***********...... | ........**...***.*****.... | .......****.......*.*..... |
| .........******...*....... | ........*.**..*........... | .......**.**.....*..*..... | .......**................. | ......**.**.***..*...*.... |
| .......**..***.*.......... | .......***........***..... | .......**..*********...... | ......**.*.*.*....***..... | ......*...*.*....**.*..... |
| .......**..*..*...****.... | ......*..***.******.*..... | .......*.*.*.****.*..*.... | ......**..**.*..*.***..... | .....*...**...*..**....... |
| ......****.*...*.****..... | ......*..*.****.**....*... | .....*.*...*......*..*.... | ......**.*...*..*...***... | .....*..*.*.**.*.*.***.... |
| .......*..**.**..**..**... | ......*....*.****....*.... | .......***.*.**.**...**... | ......**.....***.......... | ......**.**.**.**....*.... |
| .......***.*.**.*.**.*.... | ........**.*....*....**... | .......*.*.*.***.......... | .......*.**..***.*........ | ............*....**....... |
| .........**..***.*****.... | ......*..****............. | ........*...*...**........ | ......***...**.****....... | .....**........*.**....... |
| ......***...*.***.**...... | .....*...***....**........ | ....**.*.....*.*.**....... | ...**.*.******.*..*....... | ..***...***..**.**........ |
| ....**....*...**...*...... | ....*******.***.*.**...... | ..**.*...***.***.**....... | ..**.***...**............. |                            |
| ...*.*...****..*...***.... |                            |                            |                            |                            |

This gives the following error:

Code: Select all

thread 'main' panicked at src/lat/geom.rs:575:32:
no entry found for key
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[Sokwe]

How does one put partials that have been output from llsss-recentering-wao and use that as a .in file for a wider search?
Example:

First I will give working input. Since the start_file is large, you will first need to set the environment variable LLSSS_INIT_CA_CHECKS to false. On Linux, this can be done by running:

Code: Select all

export LLSSS_INIT_CA_CHECKS=false

After that, the following gives technically working input, although you will need to shorten the partial for it to be useful (I'll explain this at the bottom of the post):

Code: Select all

./rlife llsss-recentering --rule B34/S34 c5k-1 extension-example.in XX

extension-example.in:

Code: Select all

|                              |                              |                              | LLLZZZZZZZZZZZZZZZZZZZZZZRRR | LLLZZZZZZZZZZZZZZZZZZZZZZRRR |
| LLLZZZZZZZZZZZZZZZZZZZZZZRRR | LLLZZZZZZZZZZZZZZZZZZZZZZRRR | LLLZZZZZZZZZZZZZZZZZZZZZZRRR | ............................ | ............................ |
| ............................ | ............................ | ............................ | ............................ | ............................ |
| ............................ | ............................ | ............................ | ............................ | ............................ |
| ............................ | ............................ | ..........*................. | .........*.................. | ........****................ |
| ..........**................ | .........***................ | ........***................. | .......******............... | .......*.**..*.............. |
| .........***................ | ........**.*................ | .......**..***.............. | .......**....**............. | ......**...****............. |
| .......**.*...**............ | .......**.*.***............. | ......*...******............ | .......*.**..**............. | ......**.**.*............... |
| .......**.*.***............. | ......***.*..***............ | ......*...*....*............ | .....**..**..****........... | .....****.**.*..**.......... |
| ......*...**...*............ | .......********............. | ......***.***...*........... | .....**.*.*....***.......... | .....***..****...*.......... |
| ......*..*....*............. | .....*....*...***.*......... | ......***.*.*...**.......... | ......*...*.**.***.......... | .....**.*.**..*...*......... |
| .....*...*....**.***........ | ......*.*.*...***........... | .......*.*...*..**.......... | ......**.**....**.*......... | .......*******.*............ |
| ......*..*.....*............ | ........*.....**...*........ | .........*....*..**......... | ........*.*..**..*.......... | .......**.**.**.***......... |
| .......*......*.****........ | ......*.*......****......... | .........*....***........... | ........***..**.*.*......... | .......**...****.*.......... |
| .......*...*.....**......... | ......*.*......*............ | ........**....**.**......... | ........*....*...*.......... | .......**...**.....*........ |
| .......*..*.*...****........ | ........**.*.*.**..*........ | .......*....**.**........... | ........*....********....... | ...............*****........ |
| ........**...**.*.*......... | ............****..*.*....... | ............*....*.***...... | ...........*****..*.*....... | ............*.......**...... |
| .............**....***...... | .............***.*..***..... | ............*..**..*.*...... | .............*******.*...... | ...........*...*****.**..... |
| ................*....***.... | .............**........*.... | .............****...*....... | ............**...*..***..... | ............*.........*..... |
| .............*.......***.... | .................*..**.*.... | .............*.**....*.**... | ............**.********..... | ...........*...**........... |
| ............*...*.**..*..... | .............*****...***.... | ............**...***.**..... | ............***.*.**.****... | ............*.***..*...*.... |
| .............*****.......... | ............******.**....... | ............*......**..*.... | .............*...*...**..... | ............***.**.**....... |
| ............**.*..**.*...... | .............*...***.**..... | .................***.*...... | .............*...**..**..... | ....................*.*..... |
| ..............**.*.****..... | ............***.*....*...... | .............**.*.*.***..... | ....................**...... | .............*****.****..... |
| .............*....**........ | ..............****...*...... | .................**.*....... | .............****...*....... | ...............***.**....... |
| ...............**.***....... | ..............**.***........ | ..............**.****....... | ................**..**...... | .............*...***.*...... |
| ..............*.*......*.... | ..................*.*....... | ..............*..*..**...... | .............*****.***...... | ..............*....*..*..... |
| ...............****.*....... | .............*....**.**..... | ..............*..*...*...... | .............*.****.***..... | ............**.*.**...*..... |
| .............***.**.***..... | ..............**.***.*...... | ............**..**...**..... | ...........**......***...... | ..........*..**............. |
| ..............*............. | ...........**...*.****...... | ..........***********....... | .........**...***.*****..... | ........****.......*.*...... |
| ..........******...*........ | .........*.**..*............ | ........**.**.....*..*...... | ........**.................. | .......**.**.***..*...*..... |
| ........**..***.*........... | ........***........***...... | ........**..*********....... | .......**.*.*.*....***...... | .......*...*.*....**.*...... |
| ........**..*..*...****..... | .......*..***.******.*...... | ........*.*.*.****.*..*..... | .......**..**.*..*.***...... | ......*...**...*..**........ |
| .......****.*...*.****...... | .......*..*.****.**....*.... | ......*.*...*......*..*..... | .......**.*...*..*...***.... | ......*..*.*.**.*.*.***..... |
| ........*..**.**..**..**.... | .......*....*.****....*..... | ........***.*.**.**...**.... | .......**.....***........... | .......**.**.**.**....*..... |
| ........***.*.**.*.**.*..... | .........**.*....*....**.... | ........*.*.*.***........... | ........*.**..***.*......... | .............*....**........ |
| ..........**..***.*****..... | .......*..****.............. | .........*...*...**......... | .......***...**.****........ | ......**........*.**........ |
| .......***...*.***.**....... | ......*...***....**......... | .....**.*.....*.*.**........ | ....**.*.******.*..*........ | ...***...***..**.**......... |
| .....**....*...**...*....... | .....*******.***.*.**....... | ...**.*...***.***.**........ |                              |                              |

To create this input, I had to modify the start_file like so:

• Remove each occurrence of "SS". These indicate the seed slice used to construct the random partial result and do not belong in the start_file.
• Add a single column of OFF cells (denoted by periods) to each side of every block in the start_file (you will want a text editor that allows column editing for this). There needs to be three total empty columns on each side of every block, but notice that the file that you gave only has two columns on some sides of some blocks.
• At the top in the root labels, replace the leftmost "ZZZ" with "LLL" and the rightmost "ZZZ" with "RRR". These should be above the aforementioned empty columns.
• Remove the bottom rows so that every block has the same number of specified rows. In this case, this means removing the bottom rows in the first and fourth blocks (from the left).

The problem is that running the above input will finish instantly with no solutions, despite the fact that it uses mid_steps of "XX" for arbitrary width. This means that this partial cannot be continued at any width, so you will need to remove some more rows to find a partial that can be extended. To do this, simply remove the same number of rows from the bottom of each block. For example, I had to remove three rows in order to get the search to not immediately terminate when using mid_steps "XX":

Code: Select all

|                              |                              |                              | LLLZZZZZZZZZZZZZZZZZZZZZZRRR | LLLZZZZZZZZZZZZZZZZZZZZZZRRR |
| LLLZZZZZZZZZZZZZZZZZZZZZZRRR | LLLZZZZZZZZZZZZZZZZZZZZZZRRR | LLLZZZZZZZZZZZZZZZZZZZZZZRRR | ............................ | ............................ |
| ............................ | ............................ | ............................ | ............................ | ............................ |
| ............................ | ............................ | ............................ | ............................ | ............................ |
| ............................ | ............................ | ..........*................. | .........*.................. | ........****................ |
| ..........**................ | .........***................ | ........***................. | .......******............... | .......*.**..*.............. |
| .........***................ | ........**.*................ | .......**..***.............. | .......**....**............. | ......**...****............. |
| .......**.*...**............ | .......**.*.***............. | ......*...******............ | .......*.**..**............. | ......**.**.*............... |
| .......**.*.***............. | ......***.*..***............ | ......*...*....*............ | .....**..**..****........... | .....****.**.*..**.......... |
| ......*...**...*............ | .......********............. | ......***.***...*........... | .....**.*.*....***.......... | .....***..****...*.......... |
| ......*..*....*............. | .....*....*...***.*......... | ......***.*.*...**.......... | ......*...*.**.***.......... | .....**.*.**..*...*......... |
| .....*...*....**.***........ | ......*.*.*...***........... | .......*.*...*..**.......... | ......**.**....**.*......... | .......*******.*............ |
| ......*..*.....*............ | ........*.....**...*........ | .........*....*..**......... | ........*.*..**..*.......... | .......**.**.**.***......... |
| .......*......*.****........ | ......*.*......****......... | .........*....***........... | ........***..**.*.*......... | .......**...****.*.......... |
| .......*...*.....**......... | ......*.*......*............ | ........**....**.**......... | ........*....*...*.......... | .......**...**.....*........ |
| .......*..*.*...****........ | ........**.*.*.**..*........ | .......*....**.**........... | ........*....********....... | ...............*****........ |
| ........**...**.*.*......... | ............****..*.*....... | ............*....*.***...... | ...........*****..*.*....... | ............*.......**...... |
| .............**....***...... | .............***.*..***..... | ............*..**..*.*...... | .............*******.*...... | ...........*...*****.**..... |
| ................*....***.... | .............**........*.... | .............****...*....... | ............**...*..***..... | ............*.........*..... |
| .............*.......***.... | .................*..**.*.... | .............*.**....*.**... | ............**.********..... | ...........*...**........... |
| ............*...*.**..*..... | .............*****...***.... | ............**...***.**..... | ............***.*.**.****... | ............*.***..*...*.... |
| .............*****.......... | ............******.**....... | ............*......**..*.... | .............*...*...**..... | ............***.**.**....... |
| ............**.*..**.*...... | .............*...***.**..... | .................***.*...... | .............*...**..**..... | ....................*.*..... |
| ..............**.*.****..... | ............***.*....*...... | .............**.*.*.***..... | ....................**...... | .............*****.****..... |
| .............*....**........ | ..............****...*...... | .................**.*....... | .............****...*....... | ...............***.**....... |
| ...............**.***....... | ..............**.***........ | ..............**.****....... | ................**..**...... | .............*...***.*...... |
| ..............*.*......*.... | ..................*.*....... | ..............*..*..**...... | .............*****.***...... | ..............*....*..*..... |
| ...............****.*....... | .............*....**.**..... | ..............*..*...*...... | .............*.****.***..... | ............**.*.**...*..... |
| .............***.**.***..... | ..............**.***.*...... | ............**..**...**..... | ...........**......***...... | ..........*..**............. |
| ..............*............. | ...........**...*.****...... | ..........***********....... | .........**...***.*****..... | ........****.......*.*...... |
| ..........******...*........ | .........*.**..*............ | ........**.**.....*..*...... | ........**.................. | .......**.**.***..*...*..... |
| ........**..***.*........... | ........***........***...... | ........**..*********....... | .......**.*.*.*....***...... | .......*...*.*....**.*...... |
| ........**..*..*...****..... | .......*..***.******.*...... | ........*.*.*.****.*..*..... | .......**..**.*..*.***...... | ......*...**...*..**........ |
| .......****.*...*.****...... | .......*..*.****.**....*.... | ......*.*...*......*..*..... | .......**.*...*..*...***.... | ......*..*.*.**.*.*.***..... |
| ........*..**.**..**..**.... | .......*....*.****....*..... | ........***.*.**.**...**.... | .......**.....***........... | .......**.**.**.**....*..... |
| ........***.*.**.*.**.*..... | .........**.*....*....**.... | ........*.*.*.***........... |                              |                              |

You may need to remove more rows to actually get any interesting partials at reasonable widths. I find a good rule of thumb is to remove rows back to the beginning of a thin section.

[Katrina]

This definitely helped a little bit, but I am getting a new error that I haven't seen before:

Code: Select all

assertion failed: bits_per_lu <= VB::SIZE

I also occasionally get this error:

Code: Select all

In grid #0 there is a disagreement about key tile values for root LatGridRootFancy { c: 'Z', lu: None, extra_unique: None }: 10 versus 0

[Katrina]

This definitely helped a little bit, but I am getting a new error that I haven't seen before:

Code: Select all

assertion failed: bits_per_lu <= VB::SIZE

I also occasionally get this error:

Code: Select all

In grid #0 there is a disagreement about key tile values for root LatGridRootFancy { c: 'Z', lu: None, extra_unique: None }: 10 versus 0

Okay, so I managed to quickly fix these two errors:
The second error (the more important one) is caused from using llsss-recentering-wao instead of llsss-recentering (because I forgot to change that)
The first error is caused by having "--filters bcaf" instead of "--filters wcaf".

[Sokwe]

The first error is caused by having "--filters bcaf" instead of "--filters wcaf".

I don't think you should be using "--filters wcaf" or "--filters bcaf" for an extension search. These will prevent the search from forever extending the all-empty solution, when starting from all-empty rows, but you aren't starting from all-empty rows, you're starting from your partial result. Notice that the input I gave in my previous post does not include either of these options.

[amling]

To the above I would add only that using all Zs for root labels in this case is probably fine, but in the general case it will allow partial to be built chimerically from any vertical strips that fit together and pass CA checks. If you want to force a partial as-is you can use all "u" instead (which are replaced with unique root labels when the grid is loaded).

[Katrina]

Does anyone know how wickstretchers and agar crawlers can be found with LLSSS? I tried searching for how Amling got his results on the forums but couldn't get any meaningful answers.

[amling]

Does anyone know how wickstretchers and agar crawlers can be found with LLSSS? I tried searching for how Amling got his results on the forums but couldn't get any meaningful answers.

The very short answer is "more of the same". It's all the same engine(s), just with but different boundary conditions.

If you're looking for finite perturbations of background agars with sufficiently small spatial periods it's mostly just --bg-agar. Sokwe's tutorial mentions this in its B0 section but it's really just add "--bg-agar <whatever>" and use the "@bg" starting conditions. If your agar isn't one of the built-in ones you'll have to write a file to define it (although maybe just dump a copy of it here and I can write it if the examples in src/gol/agar-config.json don't make sense). If it's not sufficiently small spatial period it won't work (will panic) and there may or may not be other tricky ways to rig a search.

For wickstretchers I generally search in a direction more b2f-like (so the cycle of the wick is at the W top of the search and W bottom proceeds towards the front of the stretcher) and use WAO. An awful lot of cases have involved all the various PD tricks discussed elsewhere to reduce a wick's higher period to something lower and more searchable (e.g. 2c/8d -> c4/d). Depending on how things go and what unhelpful non-results exist in the search space I might split up WAO indexes into separate searches, I might switch geometries, or I might even switch off WAO if the geometry is sufficiently more f2b-like that the cycle of the wick is no longer a problem (i.e. the search can't/won't just repeat and extend it forever). I almost always have separate "engagement" and "solution" searches. The former to start finding any sort of, well, engagement with the wick and not really worrying about making a complete pattern. The latter to take partials from that and try to actually complete them.

I guess I will go try to make up some small and fast examples...

EDIT: I couldn't really produce any examples I liked for either of these. Finite perturbations really are just add `--bg-agar` and then "@bg" for start and the default edges and ends will do the right thing. This post is my last best effort to explain anything about WAO and includes an example of finding a wick back (where it searches f2b to find a wick back you'd want to search b2f to find a wick front).

[Katrina]

Does anyone know how wickstretchers and agar crawlers can be found with LLSSS? I tried searching for how Amling got his results on the forums but couldn't get any meaningful answers.

The very short answer is "more of the same". It's all the same engine(s), just with but different boundary conditions.

If you're looking for finite perturbations of background agars with sufficiently small spatial periods it's mostly just --bg-agar. Sokwe's tutorial mentions this in its B0 section but it's really just add "--bg-agar <whatever>" and use the "@bg" starting conditions. If your agar isn't one of the built-in ones you'll have to write a file to define it (although maybe just dump a copy of it here and I can write it if the examples in src/gol/agar-config.json don't make sense). If it's not sufficiently small spatial period it won't work (will panic) and there may or may not be other tricky ways to rig a search.

For wickstretchers I generally search in a direction more b2f-like (so the cycle of the wick is at the W top of the search and W bottom proceeds towards the front of the stretcher) and use WAO. An awful lot of cases have involved all the various PD tricks discussed elsewhere to reduce a wick's higher period to something lower and more searchable (e.g. 2c/8d -> c4/d). Depending on how things go and what unhelpful non-results exist in the search space I might split up WAO indexes into separate searches, I might switch geometries, or I might even switch off WAO if the geometry is sufficiently more f2b-like that the cycle of the wick is no longer a problem (i.e. the search can't/won't just repeat and extend it forever). I almost always have separate "engagement" and "solution" searches. The former to start finding any sort of, well, engagement with the wick and not really worrying about making a complete pattern. The latter to take partials from that and try to actually complete them.

I guess I will go try to make up some small and fast examples...

EDIT: I couldn't really produce any examples I liked for either of these. Finite perturbations really are just add `--bg-agar` and then "@bg" for start and the default edges and ends will do the right thing. This post is my last best effort to explain anything about WAO and includes an example of finding a wick back (where it searches f2b to find a wick back you'd want to search b2f to find a wick front).

Oops, I meant to say "Agarships" (like grayships, etc.). Anyways, I might have figured out how puffers work.

What I'd like the most is an easier way to construct grids. I think a Golly script would work for this.