Sokwe wrote: February 22nd, 2025, 7:14 pm
Completely unrelated to the above discussion, I was looking for a p7 oscillator that could activate the odd traffic stop to reduce the p35 gun. Consider the following partial result:
Code: Select all
x = 28, y = 63, rule = B3/S23
8bo$7bobo$8bo2$6b5o$5bo4bo$4bo2bo$bo2bob2o$obobo5bo$bo2bo4bobo8bo$4b2o
2bo2bo6b3o$9b2o6bo$13bo3b2o$13bo$13bo2$15b3o2$8b2o3bo7bo$7bobo3bo5b3o$
7bo5bo4bo$6b2o7b2o2bo$14bo2b2obo$12b2o6b3o$8bo2bobo3b3o3bo$8b4obobo4bo
bo$12bo2bo2b3ob2o$10b2o3bo7bo$10bo4bob4obo$8bobo4bo4bob2o$8b2o4b2ob2ob
o2bo$13b2o2bob2obo$12b2o3bo3bo$11b2o2b2ob2o$11b2obo3bo$12bo2b2o3bo$7b
2obobo4b3obo$7bob2obo2b2o4bo$13b2obo2b2o$14bobobo$13b2obobo$8b2ob2obob
ob2o$9bob2o2bo4bo$8bo7b4o2b2o$9b2ob4o4b2o2bo$10bobo2bobobo2b3o$10bo2bo
2b3o2bo$11b2o4b3o2bo$17b3ob2o2$17b3ob2o$15bo6bo$14bob6o4b2o$15bo6b3o2b
o$19bobo3b2o$21bob2o$21b2obo$21bo$19b2o$22b2o$19bo$20b2obo$20b2obo!
Notice that there are points where the rotor gets fairly thin. Is there a way to use LLSSS to search for extensions in which the rotor stays thin while the stator is unrestricted?
Normally when using JLS I will restrict the width of the rotor to some small amount, bounded by two columns of period-1 cells, which are themselves bounded by "don't care cells". something like this:
Code: Select all
XXXX11777711XXXX
XXXX11777711XXXX
XXXX11777711XXXX
XXXX11777711XXXX
XXXX11777711XXXX
XXXX11777711XXXX
This prevents the search from wasting time finding numerous functionally equivalent stators within the 'X' cells.
Let's fix a slice to discuss trying to solve, say this width 3 rotor pulled from the middle (r/R are rotor cells off/on):
Code: Select all
| ...**.*.*rr..***.*... | ...**.*.*Rr..***.*... | ...**.*.*rr..***.*... | ...**.*.*rr..***.*... | ...**.*.*rR..***.*... | ...**.*.*rR..***.*... | ...**.*.*rr..***.*... |
| ...*.**.*.rR*....*... | ...*.**.*.RR*....*... | ...*.**.*.rr*....*... | ...*.**.*.rR*....*... | ...*.**.*.RR*....*... | ...*.**.*.rr*....*... | ...*.**.*.Rr*....*... |
You can search something like what you suggest with fixed board and edges "pd" and "any". The exact semantics of CA checks near the boundary may or may not match JLS, but presumably it's close.
Code: Select all
$ cat 1.pre # still r/R
| .*rr..** | .*Rr..** | .*rr..** | .*rr..** | .*rR..** | .*rR..** | .*rr..** |
| .*.rR*.. | .*.RR*.. | .*.rr*.. | .*.rR*.. | .*.RR*.. | .*.rr*.. | .*.Rr*.. |
$ cat 1.in
| .*....** | .**...** | .*....** | .*....** | .*.*..** | .*.*..** | .*....** |
| .*..**.. | .*.***.. | .*...*.. | .*..**.. | .*.***.. | .*...*.. | .*.*.*.. |
$ rlife llsss p7 1.in --left-edge pd:7:any --right-edge pd:7:any
...
The "any" edge is unrestricted (other than CA checks) while the "pd" edge wraps another edge and restricts it to further demand all cell cohorts meet some period division. In this case division in 7 makes them still lifes.
This however is not generally how I would approach limiting rotor cells. I've not had great luck with "any" in any form and you lose recentering. Also I'm not convinced for LSSS descendants that deduping stators is super valuable due to how partials are split into strips and each strip is only kept once even if there are ridiculously many legal combinations of them.
How would I do it? For starters, let's talk about input files. As is this could be...
Code: Select all
$ cat 2.pre
| LLLuuuuuuuuuuuuuuuRRR | LLLuuuuuuuuuuuuuuuRRR | LLLuuuuuuuuuuuuuuuRRR | LLLuuuuuuuuuuuuuuuRRR | LLLuuuuuuuuuuuuuuuRRR | LLLuuuuuuuuuuuuuuuRRR | LLLuuuuuuuuuuuuuuuRRR |
| ...**.*.*rr..***.*... | ...**.*.*Rr..***.*... | ...**.*.*rr..***.*... | ...**.*.*rr..***.*... | ...**.*.*rR..***.*... | ...**.*.*rR..***.*... | ...**.*.*rr..***.*... |
| ...*.**.*.rR*....*... | ...*.**.*.RR*....*... | ...*.**.*.rr*....*... | ...*.**.*.rR*....*... | ...*.**.*.RR*....*... | ...*.**.*.rr*....*... | ...*.**.*.Rr*....*... |
$ cat 2.in
| LLLuuuuuuuuuuuuuuuRRR | LLLuuuuuuuuuuuuuuuRRR | LLLuuuuuuuuuuuuuuuRRR | LLLuuuuuuuuuuuuuuuRRR | LLLuuuuuuuuuuuuuuuRRR | LLLuuuuuuuuuuuuuuuRRR | LLLuuuuuuuuuuuuuuuRRR |
| ...**.*.*....***.*... | ...**.*.**...***.*... | ...**.*.*....***.*... | ...**.*.*....***.*... | ...**.*.*.*..***.*... | ...**.*.*.*..***.*... | ...**.*.*....***.*... |
| ...*.**.*..**....*... | ...*.**.*.***....*... | ...*.**.*...*....*... | ...*.**.*..**....*... | ...*.**.*.***....*... | ...*.**.*...*....*... | ...*.**.*.*.*....*... |
$
If you really want to let it pick its own starting stator you can wildcard it (with default wildcard config "7" is a 7-fold PD wildcard, i.e. stator here):
Code: Select all
$ cat 3.pre
| LLLLLuuuuuuuRRRRR | LLLLLuuuuuuuRRRRR | LLLLLuuuuuuuRRRRR | LLLLLuuuuuuuRRRRR | LLLLLuuuuuuuRRRRR | LLLLLuuuuuuuRRRRR | LLLLLuuuuuuuRRRRR |
| ..777.*rr..*777.. | ..777.*Rr..*777.. | ..777.*rr..*777.. | ..777.*rr..*777.. | ..777.*rR..*777.. | ..777.*rR..*777.. | ..777.*rr..*777.. |
| ..777.*.rR*.777.. | ..777.*.RR*.777.. | ..777.*.rr*.777.. | ..777.*.rR*.777.. | ..777.*.RR*.777.. | ..777.*.rr*.777.. | ..777.*.Rr*.777.. |
$ cat 3.in
| LLLLLuuuuuuuRRRRR | LLLLLuuuuuuuRRRRR | LLLLLuuuuuuuRRRRR | LLLLLuuuuuuuRRRRR | LLLLLuuuuuuuRRRRR | LLLLLuuuuuuuRRRRR | LLLLLuuuuuuuRRRRR |
| ..777.*....*777.. | ..777.**...*777.. | ..777.*....*777.. | ..777.*....*777.. | ..777.*.*..*777.. | ..777.*.*..*777.. | ..777.*....*777.. |
| ..777.*..**.777.. | ..777.*.***.777.. | ..777.*...*.777.. | ..777.*..**.777.. | ..777.*.***.777.. | ..777.*...*.777.. | ..777.*.*.*.777.. |
$
Note even though it's only seemingly 3 columns of wildcards it's really any width in the state as all width 3 slices are generated and allowed to combine in any way (that pass those pesky init CA checks long input files have problems with). Key in that is that "u"s are distinct from each other (they are special cased in the code) while "L"s are not. If you find this generating bad stators that you can't solve northward you might add more rows northward or more specified columns of stator outwards. Beware that initialization with wildcards is going to expand the wildcard for 3 columns at a time so if you make this 10 rows tall it's going to make a pile of the 2^(3*10) combined cell values before trying to join it with itself and restrict it down. Maybe not too dangerous here but can get dangerous quickly with full "W" wildcards.
Now let's talk about steps. mid_steps are arbitrary steps and represent how much full p7 stuff you get. You probably want to add extra closures/inertness to get stator that doesn't count towards it.
The biggest choice is to include "--inertness pd:7". With this, stator is limitless and looks likes zeros to most features. Before any mid_steps are counted stator is fully closured, SRV2 looks for chokes and splits only counting rotor, etc.
Smaller is to include a fixed number of PD steps on the sides. For example "--left-closure pd:7:4 --right-closure pd:7:4" to include 4 stator steps on each side. What "4" covers is complicated both in terms of the difference between steps and columns but also the inexactness of the process where all sorts of extra chimerism will almost certainly occur. I've often used around 4 but still gotten fairly large stators.
For PD projects I've usually just run separate lines of increasing mid_steps for a few fixed values for PD steps. Something like one line for PD inertness, one line for 4 steps, one line for 8 steps, and maybe one line for 12 steps. For some projects I've run PD inertness with increasing mid_steps until I figure out the minimum viable mid_steps and then run with that mid_steps fixed and increasing PD steps one by one. You should of course play around with it and figure out what works for your geometry, partial, memory constraints, etc.
I would make sure to include `pd_lite` ends to know the moment the partial is reduced to just a stator (but presumably re-include `bg` just in case).
Actual fully-specified searches you could run with the above input files:
Code: Select all
$ rlife llsss-recentering p7 2.in --inertness pd:7 --ends bg,pd_lite:7 04
$ rlife llsss-recentering p7 3.in --left-closure pd:7:08 --right-closure pd:7:08 --ends bg,pd_lite:7 04
thank you