amling search program principles discussion / brain dump

[LuveelVoom]

The command you include also drops the constraint files; is this intended to remove the no-axis-wandering constraint?

I dropped the constraint files because they would have no effect in that search. The left edge of "pic(bg)" is already forcing the edge (i.e. leftmost two columns) to be zero and the constraints do strictly less than that.

Huh, weird, it seemed to have an effect for me. Maybe I just got confused because both searches were affected by the hanging bug. I'll check again tonight.

It was always my plan to include a both option (now sketched), even if the code when I wrote that above did not yet have it. It (both) certainly is more voluminous and I guess arguably more intelligible since you can quickly triage by eyes, just scanning the grid parts.

I've pushed the current cut as 02738751b00a although I maybe wouldn't consider it set in stone. It can be "false", "true", or "both". In JSON it can be boolean or string, interpretted in the obvious fashion. If HOME env var is set (as it is on e.g. Linux), .llsssrc is read out of there so you can e.g. set it globally like:

[...]

EDIT: I should maybe stress that the LLSSS env system was very much built to allow this sort of user preference and so while I might not personally like this change in output, it's totally sensible, at least so long as someone likes it. The default log is generally changed to be what I want to see and so sort of by construction I cannot guess what else people might want. This is all to say, if you (or others) have other ideas about output variations, do chime in here.

yayyy! thank u!!! (this outputs the final normals as an RLE, I presume?)
Hmmmm... I did not know about this HOME thing. I guess I can stop setting LLSSS_HALT_ON_ENDS=true in every new terminal, then.

...Also, what's your timezone?? I see you responding to messages (from my PST perspective) at times such as 1 AM, 8 AM, 11 AM, 2 PM, and 7 PM. I assume you have to sleep at some point, and I also assume that you don't debug programs at three in the morning... ...unless the rumors going around the discord that you are a robot have some truth to them...

It's shockingly easy to get Gemini to say where I live, although I'm not even sure how it has it. It's not exactly a secret, although I mostly try to avoid spilling my personal life into the forum needlessly. I am in the Pacific time zone, I am not a robot, and I do sleep. Without getting too deep into the particulars of my situation, my sleep and leisure schedules are not particularly regular and under the right circumstances I can indeed be found posting pretty late or pretty early. I suspect if you charted the times you'd find a trough ~3 AM to ~6 AM or so.

I'm guessing that it looks at your post dates and extrapolates from there. Also, are you actually debugging at 1 AM???? That is an incredible level of dedication .

I am not a robot

This is exactly what a robot would say...
someone on the discord claims this is a rude joke, so, uh, I hope I didn't offend you

Anyway, I would love it if you tested the partial generator to see how much it screws up on more complex cases. (Feel free not to, though.) If v8 fails, go back to v7 (I haven't tested v8 yet.)

[AforAmpere]

Is there a way to get a search like this to not get stuck on various repeating components that significantly slow down things and make it difficult to tell if it has other paths besides them? It's probably not just them causing the eventual slowdown, but I imagine it contributes. I assume wcaf doesn't work here to do so because of the geometry in some way.

Code: Select all

./rlife llsss-recentering-wao --rule B2-k3knq4aeirwy5-kq6cek78/S1c2cen3enr4-ijqtw5ejny6-i78 --filters wcaf --wao-left-edge-errors --left-edge bg raw:1:0:0:-1:-7:8:0:1:0 '@bg' 25

[amling]

Is there a way to get a search like this to not get stuck on various repeating components that significantly slow down things and make it difficult to tell if it has other paths besides them? It's probably not just them causing the eventual slowdown, but I imagine it contributes. I assume wcaf doesn't work here to do so because of the geometry in some way.

Code: Select all

./rlife llsss-recentering-wao --rule B2-k3knq4aeirwy5-kq6cek78/S1c2cen3enr4-ijqtw5ejny6-i78 --filters wcaf --wao-left-edge-errors --left-edge bg raw:1:0:0:-1:-7:8:0:1:0 '@bg' 25

Ah, here is the other boot drop on what I was answering just above. Mostly probably see that post, although some of the questions I had are now answered. I still don't have a good subjective feeling of the rule / search space and without one it's gonna be hard to give much more specific advice about the options. I guess add to the questions: how do you feel about the c/2d back edges and large all-on sections? Some variants of forbidden transitions or forbid_block would be reasonably effective at avoiding them if you don't mind losing (all partials with) them.

WCAF specifically only works if the cycle repeats along a multiple of the W vector. I think the above linked one might be a multiple of -X+Y so if you point W that way you could maaaaybe do it. It also requires starting from the cycle and is a pain to use. Add to it how long this cycle is and the implication above that there are "various" cycles and I don't think it's probably the right pick.

I am tickled enough by the problem ("find any (7, 1)c/8" and perhaps "in this rule") that I might be interested in taking a look myself. If you are okay with that (and the risk of getting partly scooped), please let me know, unambiguously, and I shall try to restrain myself otherwise.

EDIT: I might add about that command: --filters wcaf is doing nothing as WAO does a better job of keeping stuff out. --left-edge bg is more or less the default and is doing nothing. --wao-left-edge-errors is only making more confusing WAO indices that will all die on the first row when the all-background edge refuses to expand the edge into them. --wao-tile-error-mask MAX is applicable here and if added I would expect to reduce memory for otherwise-comparable searches.

[amling]

(LLSSS_RLE_ENDS)

yayyy! :mrgreen: thank u!!! :D (this outputs the final normals as an RLE, I presume?)
Hmmmm... I did not know about this HOME thing. I guess I can stop setting LLSSS_HALT_ON_ENDS=true in every new terminal, then.

Most shells will also have a facility for setting environment variables on each shell instance, although details vary immensely between shells and OSes. I don't know what "final normals" means. Hopefully you will be able to answer your own question by running it and/or ask again with more detail if you need.

I am not a robot

This is exactly what a robot would say...
someone on the discord claims this is a rude joke, so, uh, I hope I didn't offend you

Anyway, I would love it if you tested the partial generator to see how much it screws up on more complex cases. (Feel free not to, though.)

To respond to this fairly will require writing a somewhat longer post, but I thought I should put in this placeholder with a commitment to do so. The short, and sort of unfair, version is that you are unlikely to offend me without specifically trying, I am not keen on this particular LLM project and I will probably not be looking at it, and I hate, hate, hate single generation partials. I guess stay tuned...

[LuveelVoom]

Most shells will also have a facility for setting environment variables on each shell instance, although details vary immensely between shells and OSes. I don't know what "final normals" means. Hopefully you will be able to answer your own question by running it and/or ask again with more detail if you need.

The final results in the search, at least with LLSSS_HALT_ON_ENDS=true (I called them final normals because LLSSS outputs "results: 1 normal" when it finds an end, but it probably has some different name).

Anyway, I would love it if you tested the partial generator to see how much it screws up on more complex cases. (Feel free not to, though.)

I am not keen on this particular LLM project and I will probably not be looking at it, and I hate, hate, hate single generation partials. I guess stay tuned...

Awh, ok... may I ask why? Is it too facile? Is it because I'm relying too much on the LLM? Does it hinder development of LLSSS in some way (if so, I'll halt the project)? Don't hold back any punches, I would love to know how to use these in a more responsible and effective way

I can see why you hate 1gp's, even though I don't know much about the internal workings of LLSSS, because there's no way to tell how the back of the partial should evolve, whereas in a full generation partial there's no ambiguity.

I have now noticed you are carrying on two conversations at once... I might be a bit too talkative

[AforAmpere]

Ah, here is the other boot drop on what I was answering just above. Mostly probably see that post, although some of the questions I had are now answered. I still don't have a good subjective feeling of the rule / search space and without one it's gonna be hard to give much more specific advice about the options. I guess add to the questions: how do you feel about the c/2d back edges and large all-on sections? Some variants of forbidden transitions or forbid_block would be reasonably effective at avoiding them if you don't mind losing (all partials with) them.

Oh, sorry, I probably should have looked further up-thread and seen LP03's post. The C/2d backends were on purpose (not my idea or discovery, credit goes to NimbleRogue) to try to encourage there to be some way to attach a backend found with LLS to a frontend also found with LLS. Extending these things to any reasonable depth is often also difficult otherwise.

Add to it how long this cycle is and the implication above that there are "various" cycles and I don't think it's probably the right pick.

That makes sense, I suppose. There do seem to be a significant amount of different sections that repeat in some fashion, but they connect to each other in a bunch of ways.

EDIT: I might add about that command: --filters wcaf is doing nothing as WAO does a better job of keeping stuff out. --left-edge bg is more or less the default and is doing nothing. --wao-left-edge-errors is only making more confusing WAO indices that will all die on the first row when the all-background edge refuses to expand the edge into them. --wao-tile-error-mask MAX is applicable here and if added I would expect to reduce memory for otherwise-comparable searches.

The --left-edge was a remnant from just reusing a command for some other searches so I didn't end up getting rid of it. I for some reason had been under the impression that the wao-left-edge-errors was always necessary, but I see now that it's just needed if there's an imposed symmetry, at least if the wiki page is still accurate.

I am tickled enough by the problem ("find any (7, 1)c/8" and perhaps "in this rule") that I might be interested in taking a look myself. If you are okay with that (and the risk of getting partly scooped), please let me know, unambiguously, and I shall try to restrain myself otherwise.

I'd be happy personally if you were able to figure out some other ways of attacking this, although I am only one of the people working on the problem (and arguably not the primary), and I can't speak for everyone. NimbleRogue, yujh and LP03 have also been working on it, with NimbleRogue coming up with the ideas for these specific searches.

[amling]

The short, and sort of unfair, version is that you are unlikely to offend me without specifically trying, I am not keen on this particular LLM project and I will probably not be looking at it, and I hate, hate, hate single generation partials. I guess stay tuned...

I guess let's start with the offense. At this point in my life one of my highest values is not telling others how to live their lives. When I see people do something I would not do or would not enjoy I am mostly able to smile and exalt in the joy of human variation rather than roil in the despair of distaste (as I might have in my youth). What this means is it's not easy to offend me with how you choose to spend your own limited time and sanity. The unfortunate dark reflection of this, and maybe you can see it coming, is that probably the greatest remaining path to offending me is burning my time and sanity by telling me how to spend it or by forcing me to spend it in some way I don't want. I think it's still mostly a pretty high bar to clear, and offering me an idea of how I could spend my time, as distinct from telling me how to do so, absolutely does not reach it. E.g. almost no variant of "could LLSSS be made to do XXX?" is going to upset me, although the answer to the question may not always be positive. Perhaps more on this later...

Now those wacky, wacky LLMs... I promise it's related and I swear I'll get back to them, but I think it's easiest to understand my perspective by understanding my history as a software developer. Have you seen Pulp Fiction? I'm The Wolf, but for software. Something goes wrong and I have to come in from outside, figure it out, figure out how to fix it, and then bury all the bodies. The engineers who made the mess have either fled to greener pastures or are not up to the task. When it's done management will not be grateful and will move on to the next shiny thing without so much as a "thank you". Do this for decades and every time someone says "look at this cool new XXX" or "I'm gonna write XXX", you stop thinking "neat" and start thinking "what will this look like when I am cleaning up its twisted pieces off the floor?". I have my own vague notions of what LLMs might be good for, but, really, every time someone says "I made an LLM do XXX" all I think is "how do I avoid being caught in this blast radius"?

As for what I think they might be good for, I've had some luck (or rather a friend has on my behalf) pointing them at the rlife codebase and asking them to find bugs or refactors. You can see some of it in the history if you search for "LLM". These I think are a good fit because they're weird fuzzy matching that is hard to do with existing tools and, crucially, their outputs are quite verifiable ("is this a bug?" and "will this proposed refactor make the code better?"). It's unironically on my radar to try to find some time to see what they can do debugging (e.g. I wonder if they could have figured out that hang). I also think some open questions with existing answers all over the training data might be okay ("what can I make with a leftover bottle of white wine?" "where should I go in Tokyo when visiting?" "how do I use software library XXX?").

I think the big problem with the question we're discussing here ("extend this symmetric partial") is that it's sort of uncertain what is meant. If I was asked to do it (as I more or less have been), I would be strictly obligated to invent exact semantics before then going on to program them. With the LLM it seems like it just went straight to writing something and I have no idea what semantics you got. I think this unspecified-ness and its seeming willingness to blaze on without sorting it first, makes this a particularly bad problem for them.

I had thought I would write more about one generation partials (and my hate) with the asymmetric case to illustrate this progression of problem from uncertain/unspecified, to specified, to written, which that problem ("extend this asymmetric partial") went through, but I think maybe it's not needed. I think at this point the symmetric semantics have reached specified in previous posts and I just need to buckle down and go finish writing it.

The bottom line for your webpage partial wrangler is that while I wonder what semantics it chose, I'm not optimistic enough about the project to want to spend my time dissecting it. I'm not offended by your having, uh, "written" it, but I would rather prefer it not somehow become a support burden for me, which in my mind is its greatest risk.

[NimbleRogue]

I am tickled enough by the problem ("find any (7, 1)c/8" and perhaps "in this rule") that I might be interested in taking a look myself. If you are okay with that (and the risk of getting partly scooped), please let me know, unambiguously, and I shall try to restrain myself otherwise.

Please feel free to help with searches. I mainly just want to see a complete ship; We could always use more eyes and brains on this.

Oh, sorry, I probably should have looked further up-thread and seen LP03's post. The C/2d backends were on purpose (not my idea or discovery, credit goes to NimbleRogue) to try to encourage there to be some way to attach a backend found with LLS to a frontend also found with LLS. Extending these things to any reasonable depth is often also difficult otherwise.

Although I was the one to think of using the c/2d backends for INT searches, the idea was based on May13's lifelike (2,1)c/3s.

[amling]

There do seem to be a significant amount of different sections that repeat in some fashion, but they connect to each other in a bunch of ways.

This reasonably strongly prevents effective attack with forbid_grid or WAO.

The C/2d backends were on purpose

This mostly rules out forbid_block and forbidden rule transition. Maybe you could still pick some collection of blocks to refuse some known recurring front bits?

It also suggests using fixed board searches to force a more-south-like bend is going to be undesireable for general lengthening searches as the desired back has the same slope as the undesired fronts. You could do it anyway and turn SE (W=X+Y) and use the existing pattern as one side of the search. Unclear if this is any better than just searching W=X+Y from zeros instead. Hard to set up and a lot of annoying knobs to twiddle (top pad, which side slices, etc.).

Of what I had named already, you're pretty much just down to "bigger search and pray". Without having felt the search space personally, I'd say my best, first guess would be an unlimited width search with --pre-reify-autochoke the highest you can afford and "--partials srv2". Then read the SRV2 outputs and pray it finds something good-looking along the way.

If you like the c/2d back maybe try including it (with "blocks") as a right side unlimited steps closure to encourage it (not inertness, as you probably still want it counted by SRV2). It's going to make the varied repeating fronts more findable so even if I did this I would almost certainly still do the run without it as well.

It's more obscure, but you could take just the front edge to LGOL. It can detect and prune cycles, although it is vastly inferior to LLSSS in every other way and it's unclear what ends you would use (like what change in the front edge would you be hoping for?).

Please feel free to help with searches. I mainly just want to see a complete ship; We could always use more eyes and brains on this.

Cool, I will take a quick look and see what I can squeeze in on free smaller machines immediately. Bigger searches ... eventually.

[LuveelVoom]

The short, and sort of unfair, version is that you are unlikely to offend me without specifically trying, I am not keen on this particular LLM project and I will probably not be looking at it, and I hate, hate, hate single generation partials. I guess stay tuned...

(I removed some parts of these quotes which aren't relevant to my reply to reduce the space of this)

[...] The unfortunate dark reflection of this, and maybe you can see it coming, is that probably the greatest remaining path to offending me is burning my time and sanity by telling me how to spend it or by forcing me to spend it in some way I don't want. I think it's still mostly a pretty high bar to clear, and offering me an idea of how I could spend my time, as distinct from telling me how to do so, absolutely does not reach it. E.g. almost no variant of "could LLSSS be made to do XXX?" is going to upset me, although the answer to the question may not always be positive. Perhaps more on this later...

Hmm, I see the issue here, it's that the LLM is going to turn up "problems" which end up being nonissues but waste your time.

[...] Something goes wrong and I have to come in from outside, figure it out, figure out how to fix it, and then bury all the bodies. [...] Do this for decades and every time someone says "look at this cool new XXX" or "I'm gonna write XXX", you stop thinking "neat" and start thinking "what will this look like when I am cleaning up its twisted pieces off the floor?". I have my own vague notions of what LLMs might be good for, but, really, every time someone says "I made an LLM do XXX" all I think is "how do I avoid being caught in this blast radius"?

Yep, that's about what I expected; this is a particularly big issue if LLSSS needs some component for the LLM-thingy to work, which would be a very bad situation and I am going to attempt to avoid that at all costs. Thankfully the open codebase plus the good scanning capabilities you mention below mean that it's able to locate useful (components?) pretty quickly.

The other obvious issue is strange bugs appearing when attempting to use the output of the vibe-partialer, which I will hopefully be able to address myself once I learn how LLSSS actually works; in the meantime I will find workarounds. If a bug is pervasive enough I might report it here, as that ended up being very useful in the case of this hang bug,

Please do not feel the need to support whatever weird behavior the LLM's glob turns up. If it ends up stumbling into weird behavior I will attempt to fix it "myself". This is an especially good reason for me to go learn the intricate details of LLSSS! Now I have an excuse to go do that.

[...] crucially, their outputs are quite verifiable ("is this a bug?" and "will this proposed refactor make the code better?"). It's unironically on my radar to try to find some time to see what they can do debugging (e.g. I wonder if they could have figured out that hang). [...]

Now we get to the issue with the partial builder, where there is no pattern to prove, since it's a generalized object... This is all coming back to "I have to learn LLSSS for this to be viable", which does click with my framework of how vibecoding becomes functional (you have to understand it to do it well), and I should probably not have embarked on this foolhardy venture without doing this...

I think the big problem with the question we're discussing here ("extend this symmetric partial") is that it's sort of uncertain what is meant. If I was asked to do it (as I more or less have been), I would be strictly obligated to invent exact semantics before then going on to program them. With the LLM it seems like it just went straight to writing something and I have no idea what semantics you got. I think this unspecified-ness and its seeming willingness to blaze on without sorting it first, makes this a particularly bad problem for them.

Ah, I have to learn LLSSS (at least its terminology) for this to be viable.

I had thought I would write more about one generation partials (and my hate) with the asymmetric case to illustrate this progression of problem from uncertain/unspecified, to specified, to written, which that problem ("extend this asymmetric partial") went through, but I think maybe it's not needed. I think at this point the symmetric semantics have reached specified in previous posts and I just need to buckle down and go finish writing it.

The bottom line for your webpage partial wrangler is that while I wonder what semantics it chose, I'm not optimistic enough about the project to want to spend my time dissecting it. I'm not offended by your having, uh, "written" it, but I would rather prefer it not somehow become a support burden for me, which in my mind is its greatest risk.

Well, if the partial usage elements are being written into LLSSS, this makes some of the stuff I was planning a lot more convenient to do, since the bot can hopefully figure out how to hook into the new, specifically designed, code, instead of messing around with weird screwed up input files. I just hope you didn't decide to do this because of my blind rampage through LLSSS's workings...

This post has been extremely helpful, thank you for writing it.

It has given me a clear and comprehensive action plan for me to follow to make this project likely to succeed:
1. Learn how LLSSS works.
2. Explain how LLSSS works (particularly the terminology) to the robot.
3. Guide the robot into producing a program that actually works "with" (not inside the codebase, but rather as in building structures that LLSSS is designed to handle) LLSSS.
4. Refine the program until it produces functional, effective, and --non-amling-pestering outputs.
5. Refine the front end of the program to make it easy to use.
6. Release the program to the community, get feedback from them, and fix as many bugs as possible myself before resorting to asking you
7. As LLSSS develops, I can then go back to the program myself and "personally" update it to work with the new versions of LLSSS, since it will now be building on the previous framework we developed.

And if the above 7 steps don't reach some failure point somewhere along the line:

8. Potentially "construct" more user-facing interfaces via the same methodology.
9. Potentially repeat the same process except replace "LLSSS" with another enigmatic program with complex behavior (Uh, are there any as deep as LLSSS at the moment? I can't recall so)

Ideally, people won't go begging you for help. If they start spamming this thread I will probably discontinue development, or pause releases and work out as many kinks as I can.

The goal here wasn't really ever to f**k with LLSSS's systems until 232p7h3v0 behavior could be constructed, that was just the case I was most interested in doing; the goal is to make a system or set of systems that can be used with LLSSS to make it easier to use for people who aren't Keith Amling (no offense intended, this is a great program, but I don't think anyone besides you understands the depth of it enough to do the sorts of constructions you have done with it before.)

I feel that this is a major issue that the CA community faces that larger communities do not: most programs do not support GUIs and other easy to use components. (You'll notice me saying occasionally that I am not a big fan of Golly's controls.) As a community grows, newbies accumulate faster and faster, and thus more and more effort must be expended in educating them, so at a certain point members of the community decide to make this process easier by constructing user-friendly systems.

I'm not sure why I thought it would be a good idea to embark on the journey of making LLSSS user-friendly without understanding how LLSSS works. I must have convinced myself that I could use that user-friendliness immediately instead of having to understand the backend first.

I suppose it turns out LLMs can help you learn, but not in the way they advertised

Thanks a ton for your support.


EDIT: Happy to report that LLSSS_RLE_ENDS works:

Code: Select all

x = 141, y = 55, rule = LifeHistory
F27.F27.F27.F.5B2A18B.F.3B4A18B.F$F.2BA3BA18B.F.2BABABA18B.F.4BAB2A
17B.F.4BA2BA17B.F.5B2A18B.F$F.3BA2BA18B.F.5B3A17B.F.5B3A17B.F.25B.F.
25B.F$F.6BA18B.F.25B.F.6BA18B.F.7BA17B.F.25B.F$F.25B.F.25B.F.5BA19B.F
.5BA19B.F.4B3AB2A15B.F$F.5BA19B.F.4B3A18B.F.4BA3B2A15B.F.4B2A2B3A14B.
F.3BA2BABABA14B.F$F.4B3AB2A15B.F.4B7A14B.F.4BA4B2A14B.F.3B3A2B3A14B.F
.3BA2B2A2B2A13B.F$F.3BA4BAB2A13B.F.6B3A2BA13B.F.4BA6BA13B.F.4B2A2BA3B
A12B.F.6B3A2BA13B.F$F.5BA4B2A13B.F.4BA4BA2BA12B.F.5BAB2AB3A12B.F.3BAB
A2BA3BA12B.F.3BAB2AB2A15B.F$F.4BA6BA13B.F.4BA6BA13B.F.3B2A4B3A13B.F.
3BA2BABA16B.F.4BA2BA17B.F$F.4B2A3BA15B.F.3BA4BABA14B.F.3B3A4B2A13B.F.
25B.F.8BA16B.F$F.4B4ABA15B.F.4BABA2B2A14B.F.4B2A3B2A14B.F.3BA3B2A16B.
F.7B3A15B.F$F.9BA15B.F.5BA19B.F.5B4ABA14B.F.4BA3BABA14B.F.10B2A13B.F$
F.7B4A14B.F.7B2ABA14B.F.6B2A17B.F.8B4A13B.F.5BAB2A16B.F$F.6BA3BA14B.F
.6BA18B.F.6BA3B2A13B.F.5B2A2B3A13B.F.6B2A3BA13B.F$F.7B2AB2A13B.F.6B3A
B2A13B.F.6BABABA14B.F.7BA17B.F.6BA4BA13B.F$F.5BA2BA16B.F.8B2A15B.F.9B
2A14B.F.11BA13B.F.25B.F$F.6B2A17B.F.6B2A17B.F.7B4A14B.F.8BA2BA13B.F.
9B4A12B.F$F.12BA12B.F.10B2A13B.F.10BA2BA11B.F.8BABA2B2A10B.F.10BA3BA
10B.F$F.9B3A13B.F.10B5A10B.F.13B2A10B.F.10B5A10B.F.9B2A3B2A9B.F$F.13B
3A9B.F.11BABABA9B.F.10B2A3BA9B.F.11B2A3BA8B.F.15BA9B.F$F.9B2A3B2A9B.F
.13BA2BA8B.F.12BAB3A8B.F.11B2A3BA8B.F.13BA11B.F$F.15BA9B.F.16BA8B.F.
13B2ABA8B.F.12BA12B.F.12B2A2B2A7B.F$F.12B3ABA8B.F.13B2AB2A7B.F.13B2AB
2A7B.F.12BA3B2A7B.F.12B2ABABA7B.F$F.16B2A7B.F.13B2A3BA6B.F.13B3A2BA6B
.F.13BAB3A7B.F.13B3ABA7B.F$F.15BAB2A6B.F.18BA6B.F.25B.F.14BA10B.F.14B
3A8B.F$F.12BA4BA7B.F.25B.F.25B.F.19BA5B.F.13BA4B2A5B.F$F.16B3A6B.F.
12B2ABA3BA5B.F.12B2AB2AB3A4B.F.12B2A3B2ABA4B.F.12B2A3B2ABA4B.F$F.12B
2AB2AB2A5B.F.13B4AB3A4B.F.12BA5B3A4B.F.12B2A2BA3BA4B.F.12B2A2BABAB2A
3B.F$F.14BA5B2A3B.F.14BAB2A3BA3B.F.17BA7B.F.17BA2BA4B.F.16B4A5B.F$F.
12B2A2BA3B2A3B.F.13BABA3BA5B.F.18BA2BA3B.F.17B2A6B.F.17B2A6B.F$F.16BA
3BA4B.F.15B3A2B2A3B.F.17BA2BA4B.F.25B.F.18BA6B.F$F.16BA8B.F.15B2A8B.F
.14BA10B.F.15B3A7B.F.15BABA7B.F$F.16BABA6B.F.15B2ABA6B.F.14BAB2A7B.F.
14BAB2A7B.F.13B2A3BA6B.F$F.14BA2B2A6B.F.14BA4BA5B.F.13B2ABA8B.F.12BAB
AB2A7B.F.13B2A2BA7B.F$F.13BAB4A6B.F.12B2ABA9B.F.12B2A11B.F.11BA3BA9B.
F.10B2A3B2A8B.F$F.12B2A2B2A7B.F.11BABA11B.F.10B2ABA2BA8B.F.10B2AB2A
10B.F.10B2ABA2BA8B.F$F.10B2ABAB3A7B.F.10B2ABABABA7B.F.11BABA11B.F.11B
ABAB2A8B.F.10B2A3B3A7B.F$F.9BA4BA10B.F.9BABA2BA10B.F.9BA3B3ABA7B.F.
12B2A3B2A6B.F.12B3A3BA6B.F$F.10BA4B3A7B.F.10B3A3B2A7B.F.14B5A6B.F.17B
2A6B.F.17BABA5B.F$F.11B5A2BA6B.F.11B3ABAB2A6B.F.10BA2B2A10B.F.19BA5B.
F.19BA5B.F$F.13BA5BA5B.F.13BA4B3A4B.F.13B2A2B3A5B.F.13B2A2B3A5B.F.17B
A2BA4B.F$F.19B2A4B.F.25B.F.18BA6B.F.17B3A5B.F.17BA2BA4B.F$F.18B3A4B.F
.18BA6B.F.25B.F.19BA5B.F.19B2A4B.F$F.18BAB2A3B.F.18BA2BA3B.F.18BABA4B
.F.19BA5B.F.18B2A5B.F$F.20BA4B.F.19B2A4B.F.19BA2BA2B.F.15BA3B3A3B.F.
14B3AB2AB2A2B.F$F.15BABA3BA3B.F.15B2A3B3A2B.F.14B3A4BA3B.F.14B3ABA2B
2A2B.F.14BAB3A2B2A2B.F$F.14BABA4B2A2B.F.13B2AB4A5B.F.13BA2B3A3BA2B.F.
14BA3BA6B.F.14BABA8B.F$F.13B2A3B5A2B.F.13B2A4B2ABA2B.F.16B2A7B.F.16BA
8B.F.15B2A8B.F$F.14BA10B.F.14B2A3B3A3B.F.19BABA3B.F.16B2A2BA4B.F.15B
3A7B.F$F.14BA10B.F.13B3A9B.F.13BA2BA3BA4B.F.14BA5BA4B.F.15BA9B.F$F.
14BA2BA7B.F.14B2A9B.F.13BABA9B.F.14BA10B.F.25B.F$F.15BA9B.F.25B.F.25B
.F.25B.F.25B.F$F.25B.F.25B.F.25B.F.25B.F27.F$F.25B.F27.F27.F27.F27.F!

Edit 2: More results from fooling around with the partial cutter. This is a (2,1)c/5, the approximate positions of the cuts are indicated (the partial cutter cannot cut diagonally, that's just around where it is):

Code: Select all

x = 27, y = 88, rule = B2e3-ejnr4ejkn5ajkn6-i/S2-ci3-kry4qw5acei6-i78History
11.2A$10.A.A$5.2A3.2A3.A$4.A.A.2A3.A.A$4.2A3.5A$3.A4.3A.A.A$4.A4.2A.A
$2.2A3.A.4A$2.2A4.5A$.A5.5A$2A.3A.6A$.4A3.6A$2.6A.5A$3.6A.4A$2A.5A.A.
2A.A$2.A.5A.A.A$3.2A.A.A$5.2A.A2.2A$8.5A$8.2A.A.2A$13.2A$11.A$6.4DA6D
$10.2A.A$7.A$7.A.A2.2A$8.A3.2A$8.2A.A4.A$10.A4.4A$9.A.2A.2A.2A$11.2A$
7.2A2.2A.2A$7.A2.2A2.A$7.A.A2.A.3A$7.A2.A2.A.A.A$9.A2.A.A2.2A$9.A7.A$
10.A.A4.A.2A$13.A.A.5A$13.A.3A2.A$12.2A8.3A$11.A2.4A2.2A.3A$11.2A4.A.
A.A.3A$13.A5.A2.A$12.2A.A3.4A$11.A2.2A4.2A3.A$20.A.A.A$15.D5.A2.3A$16.
D.3A$17.D2A.A.A$15.3AD4.2A$14.A3.AD4.A$13.A.3A2.D$14.A.A.A2.D$15.2A$15.
A$13.2A2.3A$12.A2.A3.A$11.A3.A2.A.A$12.2A3.3A$13.3A.3A$14.A$12.A.A.3A
2.A$11.A.A.A.2A$10.A.A$10.3A2.A$10.4A$8.8D$12.A$9.3A$9.A4.A$9.A3.A$11.
2A.A$10.A$12.A$14.2A$14.2A$12.2A$11.3A.2A$11.A.A.2A$14.A$13.2A.A$13.3A
$15.3A$18.A$15.2A$15.2A.2A$16.2A!

Top section was mid-steps 18, upper middle section was mid-steps 17, lower middle section was mid-steps 15, and bottom was mid-steps 11. This would have taken unbearably long on my computer without the partial cutter.

P.S. You were right about the constraint files being useless, the search had the exact same output without them.

[LuveelVoom]

How should I go about learning how LLSSS operates? Should I just start at the front of the thread and read forwards?

Edit: I'm curious to know how you would have gone about finding the above spaceship

[amling]

How should I go about learning how LLSSS operates? Should I just start at the front of the thread and read forwards?

Mmm, that is a good question. At this point it has gotten so long that reading the entire history is probably not an efficient use of time and enough has changed over the years that even a guided tour of just the core posts is going to require a mountain of errata. I'll try to find some time today to write a "state of the union" summary...

[amling]

LLSSS 20260930 Core Engine State of the Union

This document attempts to explain the workings of the core engine of LLSSS, sort of from a hypothetical user perspective, as it stands today (20260930). I'm going to simplify quite a few things and not discuss all (or even most) features. I will try very hard to mark any such simplifications.

The very first thing we have to discuss is UVW geometry. LLSSS can build patterns "in any direction" although most common are orthogonal and diagonal. To do this, it picks three vectors in XYT space, named "U", "V", and "W". V is the translation of the pattern and any two coordinates in XYT space that are separated by an integral multiple of V are identical. W is the direction the search is progressing and nearly anywhere I use top/up/bottom/down in this document I mean along W (top/up being negative W, bottom/down being positive W). U is some other vector that completes a basis for 3-space and nearly anywhere I use left/right in this document I mean along U (left being negative U, right being positive U). As |det(UVW)| is not necessarily 1, it is possible for UVW coordinates of integer XYT points to not themselves be integers. We think of all of space as being broken into rows (collections of coordinates that all have the same integer floor(W)) and being broken into columns (collections of coordinates that all have the same integer floor(U)). The code and a lot of prior writing call the intersections of rows and columns "tiles" and focus more on them, although it won't come up much here as this division into tiles is a little less important for users.

When searching c2-f2b (c/2 north, front-to-back), V=(0, -1, 2), U=X, W=T, the rows are:

Code: Select all

| 000000 | 111111 |
| 222222 | 333333 |
| 444444 | 555555 |

The columns are:

Code: Select all

| 012345 | 012345 |
| 012345 | 012345 |
| 012345 | 012345 |

When searching 2c4-f2b (2c/4 north, front-to-back), V=(0, -2, 4), U=X, W=T, the rows are:

Code: Select all

|        |        | 000000 | 111111 |
| 000000 | 111111 | 222222 | 333333 |
| 222222 | 333333 | 444444 | 555555 |
| 444444 | 555555 |        |        |

Notice especially that each row has two horizontal lines of cells!

The columns are:

Code: Select all

|        |        | 012345 | 012345 |
| 012345 | 012345 | 012345 | 012345 |
| 012345 | 012345 | 012345 | 012345 |
| 012345 | 012345 |        |        |

When searching c4d-down (c/4d NW, building south), V=(-1, -1, 4), U=X, W=Y, the rows are:

Code: Select all

| 000000 | 000000 | 000000 | 000000 |
| 111111 | 111111 | 111111 | 111111 |
| 222222 | 222222 | 222222 | 222222 |
| 333333 | 333333 | 333333 | 333333 |
| 444444 | 444444 | 444444 | 444444 |
| 555555 | 555555 | 555555 | 555555 |

The columns are:

Code: Select all

| 012345 | 012345 | 012345 | 012345 |
| 012345 | 012345 | 012345 | 012345 |
| 012345 | 012345 | 012345 | 012345 |
| 012345 | 012345 | 012345 | 012345 |
| 012345 | 012345 | 012345 | 012345 |
| 012345 | 012345 | 012345 | 012345 |

When searching c4d-f2b (c/4d NW, actually front-to-back), V=(-1, -1, 4), U=X-Y, W=X+Y, the rows are:

Code: Select all

|         |         |      0  |      1  |
|      02 |      13 |     024 |     135 |
|     024 |     135 |    024  |    135  |
|    024  |    135  |   024   |   135   |
|   024   |   135   |  024    |  135    |
|  024    |  135    | 024     | 135     |
| 024     | 135     | 24      | 35      |
|  4      |  5      |         |         |

Note that each row is two HDs, one in each of two generations opposite each other. The columns are:

Code: Select all

|         |         |      5  |      5  |
|      55 |      55 |     455 |     455 |
|     445 |     445 |    344  |    344  |
|    334  |    334  |   233   |   233   |
|   223   |   223   |  122    |  122    |
|  112    |  112    | 011     | 011     |
| 001     | 001     | 00      | 00      |
|  0      |  0      |         |         |

Note that each column is two HDs.

A common concern in discussing geometry is the CA check sizes. The CA check sizes (called "nh_w_size" and "nh_u_size" in the code) are the greatest number of rows/columns a single CA neighborhood can span, i.e. the size of strips (of rows/columns) of the world you have to be looking at to be able to adjudicate CA checks locally. One less than each of these are the overlap sizes, i.e. the number of rows/columns that two half planes most agree on to be able to patch together and be guaranteed to meet CA checks. Most relevant for below are (1) the U CA check size, which for all named geometries is 3, and (2) the W overlap size, which is, well, it's complicated. For named orthogonal-aligned geometries the W overlap size is what users would probably think of as "2 rows of cells in each generation". For named diagonal-aligned geometries the W overlap size is what users would probably think of as "4 HDs in each generation".

The core objects in LLSSS are strips of partial pattern whose widths are a compile-time-specified constant, "AF2", which must be at least as wide as the U CA check size (so these strips' contents can adjudicate all CA checks), and whose height is whatever the height/depth of the search is so far. By default AF2 is 3 and below here I'm going to simplify under that assumption. I think it's worth repeating and restating that all state is made up of these 3-wide strips and that their shape in XYT space is determined by the geometry.

LLSSS search states are probably best thought of as built from collections of these 3-wide strips. Each such collection is called a "jcol", short for "join column". Historically these have been called (insanely confusingly, I know) "columns" and I have been trying to switch to calling them "jcols". The states actually include collections of 2-wide strips ("bcols") that are the boundaries between neighboring jcols. In the code bcols have primacy and jcols are "just" the CA compatibility relationships between neighboring bcols, but from the user perspective I think it's easier to focus on the 3-wide strips.

In "fixed board" mode, the state is some fixed-length array of jcols and each adjacent pair of jcols in the array are considered to be neighbors. It is required that each strip in each jcol have a valid neighbor strip both to the left and to the right and thus have a path (of strips) all the way to either edge. "Valid neighbor strip" here means agreeing on the overlapping 2-wide strip.

In "recentering" mode, the state is just a single jcol and also some extra data tracking what 2-wide strips are considered to be the left edge and what 2-wide strips are considered to be the right edge. It is required that each strip in the jcol have a path (of any length) to the left edge and also to the right edge. It is unlikely to matter for typical searches, but it is possible for the left edge and right edge to agree on (include) a 2-wide strip that is not present in the jcol anywhere (this sort of thing is part of the problem of thinking in jcols instead of bcols...).

It is probably not worth dwelling too hard on how the state extension happens (one-bit-at-a-time versus one-tile-at-a-time, how recentering mid_steps limits it, etc.), other than to say the edge-reachability invariants are preserved and all 3-wide strips always meet CA checks. Fixed board searches can really put in whatever cell values they want in the middle, while recentering searches are in some ways limited to trying to keep apparent widths of the bottom edge of partials down, but the semantics are exceptionally complicated and mostly not worth knowing.

Now, about boundary conditions. The board has 4 sides and each is its own distinct concern/configuration (although left/right are similar)...

The top side of the board is dictated by how the state is initialized. For fixed board, we take the provided grid, chop it into 3-grams of columns to make strips, and make one jcol for each such strip. For recentering, we take the provided grid, chop it into 3-grams of columns, and shovel them all into one jcol. Recentering edges are initialized with just the left-most 2-gram and the right-most 2-gram. This hides a lot of details like wildcards (uncovered), multiple boards (ditto), CA checks (we do them), recentering roots (see below), and question marks ("picture mode", see below).

The left and right sides of the board are their own bag of worms and features. Such extension behaviours ("edges") act on the outermost 2-grams and essentially restrict the extension choices in each new row. Typically they are either extended with the background agar only, or extended according to a specified symmetry. Note that these restrictions mean searches' effective widths may be thinner than the board itself, by amounts varying by edge (background agar is 2 U thinner, symmetry edges vary depending on where they place the axis in the edge).

The board doesn't have a bottom boundary condition per se, in that the extension could continue forever. Usually though, the operator will have some sense of what constitutes a success (called "ends"). The default ends is "bg", i.e. does the last W overlap size of rows match the background agar. It checks one W overlap (as do most ends) as that is what is needed to guarantee validity of patching together with an imagined half plane of background agar below it. After each round of expansion, ends run their checks and print out any successes.

That I think completes a whirlwind tour of the core engine. Nearly every part of this is extensible and there are a wealth of features that did not make this summary, although I think they should be possible to explain independently, building on what's written here. It's possible I may do (some of) them later and I will edit in links somewhere in this post. Even limited more or less to things relevant to intermediate branch solving, candidates include at least all of:

(*) Extension semantics, especially recentering mid_steps and probably one-bit-at-a-time (versus one-tile-at-a-time) and tile order.

(*) Recentering closures/inertnesses. Alter recentering's measurement of what constitutes width of a partial.

(*) Pre-reify autochoke. Discards part of the state when it seems the state would become "too big".

(*) Pre-partials. Status reports shown at the top of each extension round.

(*) Partials. Interesting bits shown at the end of each round (or at least most). Distinction from ends questionable. I think just SRV2 right now.

(*) Constraints. Rules cell values must obey that are extremely local and checked during extension.

(*) Filters. Rules cell values must obey that are less local and are enforced after the fact.

(*) Ends. Other things that could constitute success. PD, symmetry, EDBV3.

(*) Recentering fuzzy edges.

(*) WAO.

(*) Grid editing. Mostly from-uwi/to-uwi?

(*) mgp-tool and/or @yolo_1gp.

(*) MDSE V2.

For starters, let's complete the couple of things I foreshadowed above:



Recentering roots. A problem that came up in actually using recentering is that allowing all 3-grams to recombine according to just cell values is too permissive. Consider what happens when we try to solve a simple still life edge. We'll include 3 columns of zeros on each side so they can be recombined endlessly and we'll put our target in the middle (center two columns):

Code: Select all

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

The problem is, this is a valid partial (as the edges match):

Code: Select all

| .. |
| .. |
| .. |

So too is this, even though it has also skipped the prompt:

Code: Select all

| ..... |
| ..... |
| ..... |

To solve this we allow (where by "allow", I mean "require") special markers on the top of each column which are considered part of the column for matching purposes. Specifically, we rip off the first W row of inputs and require that each column within it have all-identical characters and each character value determines a distinct root. We can solve this case like:

Code: Select all

| LLLMMRRR |
| ........ |
| ........ |
| ...**... |

The only valid way to recombine 3-grams is some string of L's at least 2 long, followed by MM, followed by some string of R's at least 2 long. Unfortunately, this also breaks down for sufficiently weird inputs, e.g. if I try this:

Code: Select all

| LLLMMMMMMRRR |
| ............ |
| ............ |
| ...**..**... |

With this, there are these (among endless others) undesired recombinations of 3-grams:

Code: Select all

| LLLMMRRR |
| ........ |
| ........ |
| ...**... |

Code: Select all

| LLLMMMMMMMMMMRRR |
| ................ |
| ................ |
| ...**..**..**... |

Finally I settled on making the M's unique:

Code: Select all

| LLL123456RRR |
| ............ |
| ............ |
| ...**..**... |

Now the only possible recombinations of 3-grams are the ones you expect (2+ L's, then 123456, then 2+ R's). To make it easier, the code special-cases that "u" roots are considered distinct from each other (acting as if you had picked a new letter for each) and so we can (should) do this as:

Code: Select all

| LLLuuuuuuRRR |
| ............ |
| ............ |
| ...**..**... |

For typical searches you should have a string of u's in the center and edges depending on desired behavior. If you want a fixed-like edge, because you care about clearance, the edge is a symmetric edge, etc., it should just be u's all the way to the edge. If you want an unrollable edge you should have a complete cycle of the agar with some distinct-per-side labels, including all 3-gram transitions. For zero agar and b0 agar in typical geometries, this is just 3 of the same letter, but for other agars/geometries it can get a little more interesting.

These examples above are all in the very simple "p1" geometry, but when you go to other geometries each root marker is repeated |det(UVW)| times. E.g. 2c4-f2b:

Code: Select all

|     |     |     |     |
|     |     | 123 | ... |
| 123 | ... | ... | ... |
| ... | ... | ... |     |
| ... |     |     |     |

Or p3:

Code: Select all

| 123 | 123 | 123 |
| ... | ... | ... |
| ... | ... | ... |

Or c4d-f2b:

Code: Select all

|        |        |        |        |
|        |        |   3    |   .    |
|   3.   |   ..   |  2..   |  ...   |
|  2...  |  ....  | 1....  | .....  |
| 1..... | .....  | .....  | ....   |
|  ....  |  ...   |  ...   |  ..    |
|   ..   |   .    |   .    |        |

Picture mode(s). All of the above is written for initializations that are some strict W prefix of space and which are input as a complete UVW prism of cell values (periods and asterisks) (and also one W row of root markers iff recentering). For finding a spaceship in a single shot (or a series of shots, each extending a partial which is a strict prefix of W space), this is maybe fine, but when solving tougher problems there will often be surrounding parts (e.g. sibling branches) that need to be respected. In these cases we use a slightly different input format where, again, we have a complete UVW prism of stuff, but now we mark out (with question marks) where the search will go, a UVW sub-prism extending to the W bottom.

In this mode the search is initialized with just (the 3-grams drawn from) the W overlap above the question marks (instead of the entire board) and the edges will extend first with cell values drawn from the U overlaps left/right of the question marks, and then fall back to the background agar once you've walked off the end of the board.

E.g. you might do a fixed board search extending this still life:

Code: Select all

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

Your state starts with exactly that picture, namely 5 rows deep and 10 columns wide (6 of which can vary as the edges are fixed). If you drew in question marks to do similar in picture mode, it's not quite the same:

Code: Select all

| .......... |
| .......... |
| ....*..... |
| ...*.*.... |
| ...*.*.... |
| ..??????.. |
| ..??????.. |
| ..??????.. |
| ..??????.. |

You get the same effective search, but it only starts with the two rows above it so your starting state is just this:

Code: Select all

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

The real benefit of picture mode is you could shrink the search window and fill in a side:

Code: Select all

| .......... |
| .......... |
| ....*..... |
| ...*.*.... |
| ...*.*.... |
| ...*???... |
| ..**???... |
| ....???... |
| ....???... |

Your start is effectively:

Code: Select all

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

And the left edge will be extended like:

Code: Select all

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

For convenience you can pass --top-pad, --left-pad, and --right-pad to extend the question marks (by W steps up, U steps left, and U steps right, respectively), without having to do the editing yourself. E.g. adding --top-pad 1 --left-pad 1 --right-pad 1 changes from this:

Code: Select all

| .......... |
| .......... |
| ....*..... |
| ...*.*.... |
| ...*.*.... |
| ...*???... |
| ..**???... |
| ....???... |
| ....???... |

Into effectively this:

Code: Select all

| .......... |
| .......... |
| ....*..... |
| ...*.*.... |
| ...?????.. |
| ...?????.. |
| ..*?????.. |
| ...?????.. |
| ...?????.. |

Code: Select all

| ...*..... |
| ..*.*.... |
| ..?????.. |
| ..?????.. |
| .*?????.. |
| ..?????.. |
| ..?????.. |

For an initial state of:

Code: Select all

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

And a left edge extended with:

Code: Select all

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

Picture mode for recentering is more or less the same, only the roots are preserved separately. E.g. you could start with:

Code: Select all

| LLLuuuuuRRR |
| ........... |
| ........... |
| .....*..... |
| ....*.*.... |
| ....*.*.... |
| ...**???... |
| .....???... |
| .....???... |
| .....???... |

And add --top-pad 1 --left-pad 1 --right-pad 1 to get effectively:

Code: Select all

| LLLuuuuuRRR |
| ........... |
| ........... |
| .....*..... |
| ....*.*.... |
| ....?????.. |
| ...*?????.. |
| ....?????.. |
| ....?????.. |
| ....?????.. |

Code: Select all

| LuuuuuRRR |
| ...*..... |
| ..*.*.... |
| ..?????.. |
| .*?????.. |
| ..?????.. |
| ..?????.. |
| ..?????.. |

I.e. initial state:

Code: Select all

| LuuuuuRRR |
| ...*..... |
| ..*.*.... |

And left edge extended with:

Code: Select all

| Lu |
| .. |
| .. |
| .. |
| .* |
| .. |
| .. |
| .. |
| .. |
| .. |
| .. |
| .. |
| .. |
| .. |
| .. |

Note that "LuuuuuRRR" does not strictly meet the above guidance on roots, but it is effectively "uuuuuuRRR" which does (fixed left edge, unrollable right edge).

[LuveelVoom]

Whew, what a read. An hour later and I have three full pages of notes (in blue pen) (and I skipped diagonal geometries because I started getting a headache when trying to figure them out)! Thanks a ton for writing this

It better not rain before I get the opportunity to OCR these...

Edit: I just realized diagonal is basically just orthogonal rotated 45*. (Is that right?)

One major question: How does recentering compress the pattern into one jcol???

Edit 2: Curious to know what technique you would use to find something like this:

More results from fooling around with the partial cutter. This is a (2,1)c/5, the approximate positions of the cuts are indicated (the partial cutter cannot cut diagonally, that's just around where it is):

Code: Select all

x = 27, y = 88, rule = B2e3-ejnr4ejkn5ajkn6-i/S2-ci3-kry4qw5acei6-i78History
11.2A$10.A.A$5.2A3.2A3.A$4.A.A.2A3.A.A$4.2A3.5A$3.A4.3A.A.A$4.A4.2A.A
$2.2A3.A.4A$2.2A4.5A$.A5.5A$2A.3A.6A$.4A3.6A$2.6A.5A$3.6A.4A$2A.5A.A.
2A.A$2.A.5A.A.A$3.2A.A.A$5.2A.A2.2A$8.5A$8.2A.A.2A$13.2A$11.A$6.4DC6D
$10.2A.A$7.A$7.A.A2.2A$8.A3.2A$8.2A.A4.A$10.A4.4A$9.A.2A.2A.2A$11.2A$
7.2A2.2A.2A$7.A2.2A2.A$7.A.A2.A.3A$7.A2.A2.A.A.A$9.A2.A.A2.2A$9.A7.A$
10.A.A4.A.2A$13.A.A.5A$13.A.3A2.A$12.2A8.3A$11.A2.4A2.2A.3A$11.2A4.A.
A.A.3A$13.A5.A2.A$12.2A.A3.4A$11.A2.2A4.2A3.A$20.A.A.A$15.D5.A2.3A$16.
D.3A$17.D2A.A.A$15.3AD4.2A$14.A3.AD4.A$13.A.3A2.D$14.A.A.A2.D$15.2A$15.
A$13.2A2.3A$12.A2.A3.A$11.A3.A2.A.A$12.2A3.3A$13.3A.3A$14.A$12.A.A.3A
2.A$11.A.A.A.2A$10.A.A$10.3A2.A$10.4A$8.8D$12.A$9.3A$9.A4.A$9.A3.A$11.
2A.A$10.A$12.A$14.2A$14.2A$12.2A$11.3A.2A$11.A.A.2A$14.A$13.2A.A$13.3A
$15.3A$18.A$15.2A$15.2A.2A$16.2A!

Top section was mid-steps 18, upper middle section was mid-steps 17, lower middle section was mid-steps 15, and bottom was mid-steps 11. This would have taken unbearably long on my computer without the partial cutter.

[amling]

I just realized diagonal is basically just orthogonal rotated 45*. (Is that right?)

It is true that you could see it as rotating the (U, W) frame from essentially (X, Y) (W can be a fraction of Y) to ((X-Y), (X+Y)) and in that sense "yes", it is rotated 45 degrees. It's sort of more complicated though in terms of how now you now have to pack two HDs into each W row and two HDs into each U column.

How does recentering compress the pattern into one jcol???

I haven't really expanded the internals of how we store cell values in computer memory, but I don't think that's what you're asking. In fixed board the jcols have other, distinct jcols as neighbors whereas in recentering that lone jcol is (considered) looped to itself, indefinitely. In fixed board a given 3-wide strip in a given jcol must have a 3-wide strip in the next jcol to the left where the left 2-wide strip of the former (right) 3-wide strip is the right 2-wide strip of the latter (left) 3-wide strip. In recentering a given 3-wide strip in the jcol must (either be at the edge or) have a 3-wide strip in that same jcol (the only one) "to the left" where again the left 2-wide strip of the former is the right 2-wide strip of the latter.

Curious to know what technique you would use to find something like this:

(c/5k ship snipped)

This post is already in progress in the background, but there are a bunch of searches I have to wait out to complete it. Hopefully more on this later. In the mean time I sort of wonder how you did it, especially did you run full mid_steps=17 and 18 searches? Such seems quite large to me. I'm guessing you used some version of --pre-reify-autochoke, but so far I have been trying to reproduce it without.

[LuveelVoom]

This post is already in progress in the background, but there are a bunch of searches I have to wait out to complete it. Hopefully more on this later. In the mean time I sort of wonder how you did it, especially did you run full mid_steps=17 and 18 searches? Such seems quite large to me. I'm guessing you used some version of --pre-reify-autochoke, but so far I have been trying to reproduce it without.

I did a mid-steps 18 search (earlier mid-steps got nowhere), it started consuming absurd amounts of memory and barely made any progress. After about 20 minutes I noticed the frontend, the big blob in front of the ship, which had a narrow section. Since a fully mid_steps 18 search seemed very unlikely to succeed on my computer, I figured I would try the partial cutter. (It helps that it can accept raw (iirc these are XYT grids right?) grids from the output log.)

I took the cut frontend and stuck it into another search. Mid-steps up to 16 got basically nowhere, and mid-steps 17 started extending, but as it got deeper it started using more and more memory (up to 50 gigs at one point according to activity monitor, which confused me somewhat since my computer only has 48gb, but this is probably some weird computer trick I don't know about.) I noticed another thin section, again after about 20 min, and cut it there, as indicated by the diagonal line.

This cut was easier to do, since mid-steps 15 already produced viable results; however, it again started to slow down and accumulate disturbing amounts of RAM and time (less than the last two steps, though; around 20 gigs.) I noticed two thin segments appearing often in the randomish partials, so I grabbed them, cut them, and got two new files.

I took the first one in and upped the mid-steps. Mid-steps up to 10 terminated with no results, mid-steps 11 gave the final end indicated there after around a minute. I didn't end up testing the second file.

Since mid-steps 17 terminates quickly iirc due to not finding any viable frontends and mid-steps 18 takes way way too long on my computer, the fact this worked speaks towards the viability of this strategy. No autochoke was used.

Edit: I have been standardizing all the terminology in the partial cutter. Claude has 14 terms that it cannot find a name for in this thread or the source code, and I would appreciate it if you could give what you consider the standard names for these (or at least the significant ones; a few of them are just tiny visual details or terminology for descriptions of what searches "look like" to the human eye):

Code: Select all

Phrases I couldn't find a term for. These are described in plain words, or kept as names of builder features:

Mode names: "Recentering: extend and let it widen", "Fixed board: extend at a fixed width", "Split into branches, axis constraint", "Split into branches, empty columns at the axis", "Solve a branch beside its sibling (fuzzy left edge)", "Back only (narrow question marks)", "Cut along a drawn line". They use sourced words, but the modes have no LLSSS names.
Tool names: "partial builder", "Stitcher" (the thread says "stitching", but has no tool by that name) and "grid workbench". ||| Luveel note: the partial stitcher is a really terrible tool that the AI has repeatedly said it will fix but which it has consistently failed to do, just ignore that for now. It is intended to combine a found continuation to the initial frontend into a full ship by linking them together, which is irritating to do manually.
The start file format: amling says it has no name ("we should really name this format").
Both halves versus the branch alone: his plan A and plan B are close, but his plan B for recentering drops the question marks, so I don't reuse the names.
The branch further from the axis in the fuzzy-left-edge mode. The other branch is the sibling branch, which is sourced.
Cells a constraint file sets to the partial's values in cut-line mode (previously "pinned").
The part of the partial above the drawn line (previously "known side").
The layout checks my validator ports from rlife (previously "shape rules").
Lines to keep: an option name. "Line" itself is sourced.
Backtrack: LuveelVoom uses it in this sense in the thread; amling doesn't. ||| Luveel note: the LLM has my personal name as the account name so it doesn't know who LuveelVoom is
Extra columns: the wiki uses this for width beyond the ship, a slightly different sense.
Padding left/right in Back-only mode: written into the file rather than passed as --left-pad or --right-pad.
The bracketed percentages on Completed lines.
"Blows up" for a search that doubles each row: amling uses it once, for output size.
The Stitcher's merge terms: "rewritten by the search", and cells that agree or differ.

Edit 2: I did not even notice, but it added this disclamer to the "guide tab" (which I will have to go thoroughly fact-check before publicly releasing this...) after I uploaded this new thread page of stuff into the little "amling thread database" I've been keeping (it presumably did this due to your statement about AI use earlier above):

Screenshot 2026-09-30 3.01.27 PM.png (70.1 KiB) Viewed 307 times

I will tell it to make a copy of it on the main page, since I don't think it just being in the guide tab is enough.

[amling]

Code: Select all

x = 27, y = 88, rule = B2e3-ejnr4ejkn5ajkn6-i/S2-ci3-kry4qw5acei6-i78History
11.2A$10.A.A$5.2A3.2A3.A$4.A.A.2A3.A.A$4.2A3.5A$3.A4.3A.A.A$4.A4.2A.A
$2.2A3.A.4A$2.2A4.5A$.A5.5A$2A.3A.6A$.4A3.6A$2.6A.5A$3.6A.4A$2A.5A.A.
2A.A$2.A.5A.A.A$3.2A.A.A$5.2A.A2.2A$8.5A$8.2A.A.2A$13.2A$11.A$6.4DA6D
$10.2A.A$7.A$7.A.A2.2A$8.A3.2A$8.2A.A4.A$10.A4.4A$9.A.2A.2A.2A$11.2A$
7.2A2.2A.2A$7.A2.2A2.A$7.A.A2.A.3A$7.A2.A2.A.A.A$9.A2.A.A2.2A$9.A7.A$
10.A.A4.A.2A$13.A.A.5A$13.A.3A2.A$12.2A8.3A$11.A2.4A2.2A.3A$11.2A4.A.
A.A.3A$13.A5.A2.A$12.2A.A3.4A$11.A2.2A4.2A3.A$20.A.A.A$15.D5.A2.3A$16.
D.3A$17.D2A.A.A$15.3AD4.2A$14.A3.AD4.A$13.A.3A2.D$14.A.A.A2.D$15.2A$15.
A$13.2A2.3A$12.A2.A3.A$11.A3.A2.A.A$12.2A3.3A$13.3A.3A$14.A$12.A.A.3A
2.A$11.A.A.A.2A$10.A.A$10.3A2.A$10.4A$8.8D$12.A$9.3A$9.A4.A$9.A3.A$11.
2A.A$10.A$12.A$14.2A$14.2A$12.2A$11.3A.2A$11.A.A.2A$14.A$13.2A.A$13.3A
$15.3A$18.A$15.2A$15.2A.2A$16.2A!

I'm curious to know how you would have gone about finding the above spaceship

I assume you're asking more about how one could set up searches to have found and followed the path you took in terms of partials, and less about how I would find a c/5k ship in the rule in general. As they say, hindsight is 20/20, and it is often easier to follow a given string of chokes than to originate it and so what I'm about to do is very cheating. Unclear if you want to know all the details of the cheating itself or just the searches, but here is my journey...

Aligned how --wao-tile-error-mask MAX will want to find it the goal is:

Code: Select all

x = 171, y = 96, rule = B2e3-ejnr4ejkn5ajkn6-i/S2-ci3-kry4qw5acei6-i78History
F33.F33.F33.F.31B.F.31B.F$F.31B.F.31B.F.31B.F.31B.F.31B.F$F.31B.F.31B
.F.31B.F.31B.F.31B.F$F.31B.F.31B.F.14BA16B.F.13B2A16B.F.12B3A16B.F$F.
14BA16B.F.13B3A15B.F.13B2ABA14B.F.12BABA16B.F.12B3A16B.F$F.13B3A15B.F
.13B4A14B.F.8BA3BABABA14B.F.7B2A3B2A3BA13B.F.6B3A4B2A16B.F$F.8BA5B3A
14B.F.7B3A3BA2BA14B.F.7B2ABABAB3A14B.F.6BABAB2A3BABA13B.F.6B3ABABAB2A
15B.F$F.7B3A2BABA16B.F.7B4A2BABA15B.F.6BABAB7A14B.F.6B2A3B5A15B.F.7B
3ABA4BA14B.F$F.8B3A2BAB3A13B.F.7BA2B2A2BAB2A13B.F.6BABAB4ABA15B.F.5BA
4B3ABABA14B.F.6BA3B3A2BA15B.F$F.12BABABA14B.F.7BA3B3ABA15B.F.6BABA5BA
16B.F.6BA4B2ABA16B.F.5BA4B3A2BA15B.F$F.6B2ABA2BA3BA14B.F.5B3A3BAB3A
15B.F.5BA9BA15B.F.4B2A3BAB4A16B.F.4B2A4B4ABA15B.F$F.5B2A3B4ABABA13B.F
.5BA2BAB3A18B.F.4BABABAB4A17B.F.4B2A4B5A16B.F.4B2A4B4A17B.F$F.7BA2B4A
17B.F.5BA3B6ABA14B.F.4BA5B4A17B.F.3BA5B5A17B.F.2B3ABA3B4A17B.F$F.4BA
5B6A15B.F.3BA5B7A15B.F.2B3AB2A2B5ABA14B.F.2B2AB3AB6A16B.F.2BABA2BA2B
6A15B.F$F.3BA2B3AB6A15B.F.2B7AB5A16B.F.2B5AB8A15B.F.3B4A3B6A15B.F.2B
6A2B5A16B.F$F.2BA3B3AB5ABA14B.F.3B5A2B5ABA14B.F.3B7AB6A14B.F.4B6AB5A
15B.F.3B6AB7A14B.F$F.3B5A2B7A14B.F.2B2AB5AB6A14B.F.2BA2B5AB6A14B.F.5B
6AB4A15B.F.3B8AB3A16B.F$F.4B7AB4A15B.F.4B6A2B4A15B.F.3B8AB4A15B.F.2B
2AB5ABAB2ABA14B.F.3B2AB5A2BABA15B.F$F.3B8AB5A14B.F.3BAB6A2B2ABA14B.F.
5B6ABA18B.F.4BAB5ABABA16B.F.4B6ABA2BA16B.F$F.5BAB4ABA18B.F.6B4A21B.F.
5BAB2A6BA15B.F.5B2ABABA20B.F.4B2A5BA19B.F$F.6BAB2A2B3ABA14B.F.11BA2BA
16B.F.7BA3B2A2BA15B.F.7B2ABA2B2A16B.F.7B2A2BA2BA16B.F$F.5BABA3BABA17B
.F.8BAB3A2BA15B.F.10B4A17B.F.10B5A16B.F.9BA3BA17B.F$F.9B3AB2A16B.F.9B
A4BA16B.F.8BA2BAB4A14B.F.10B2ABAB2A14B.F.10BA2BAB2A14B.F$F.10B2AB4A
14B.F.14BAB2A13B.F.14B3A14B.F.15B2A14B.F.12BA2B2A14B.F$F.10BA3BAB2A
13B.F.10BA4BA15B.F.14BA16B.F.13BA17B.F.12BA18B.F$F.12B2A2B2A13B.F.11B
2A18B.F.12BAB3A14B.F.12BA18B.F.12BABA16B.F$F.12BABABA14B.F.11BAB2AB2A
13B.F.10BAB2A17B.F.12B2ABA15B.F.12B2A17B.F$F.12BABA16B.F.11BA19B.F.
10BA20B.F.9BA21B.F.12B2A17B.F$F.12BA18B.F.11BABA17B.F.10BABABA16B.F.
9BABA2B2A15B.F.9B2A3B2A15B.F$F.12B3A16B.F.11B2ABA16B.F.10B2A2B2A15B.F
.10BA3B2A15B.F.12BAB2A15B.F$F.12BAB3A14B.F.11BA3BABA13B.F.11BA19B.F.
10B2ABA4BA12B.F.10B2ABA3B2A12B.F$F.12BAB4A13B.F.12BAB3A14B.F.12BABA2B
3A11B.F.12BA4B4A10B.F.11BABA2B2A2BA10B.F$F.11BA4BAB2A11B.F.11B2ABABAB
3A10B.F.11BABAB2ABABA10B.F.11BAB2AB2AB2A10B.F.12B3AB2A2BA10B.F$F.11B
3A6BA10B.F.11BAB2A4B2A10B.F.11B2A2BA2BABA10B.F.13B2A16B.F.10BAB3A3BA
12B.F$F.12BABA2B2ABA10B.F.12B2ABA15B.F.10B2A2B3A14B.F.9B2A2B2AB2A13B.
F.9B2A5B2A13B.F$F.10B2AB3A15B.F.9B2AB2AB2A14B.F.9BA2B2A2BA14B.F.9BA2B
2A2BA14B.F.8BAB3A4BA13B.F$F.9BA2BABA2BA13B.F.9B3A2BABABA12B.F.9BA2B2A
3B2A12B.F.9BABA2BAB3A12B.F.8BA3B4A2B2A11B.F$F.9BABABAB2ABA12B.F.12BAB
5ABA10B.F.10BABA2BA2BA2BA9B.F.9BA2BA2BABABA11B.F.13BA5B2A10B.F$F.13BA
4B4A9B.F.12BAB2A2BA2BA9B.F.14B3AB3A10B.F.11BA2BABA2B2A10B.F.10B2A5B4A
10B.F$F.12BABA4B2A10B.F.11B5A3BA11B.F.12BABABAB3A10B.F.11BA7BA11B.F.
11BABABA2BAB2A9B.F$F.11B2A2BA2BABA10B.F.11B2ABA2B2AB2A9B.F.11BA2B5AB
2A9B.F.12BABA4BAB2A8B.F.11BA3BA2BABA2BA7B.F$F.17BA4BA8B.F.17BA3BA9B.F
.16BA2BA2BA8B.F.15BABAB5A7B.F.15BAB2A3B2A7B.F$F.15BABA3BA2BA6B.F.17BA
2B4A7B.F.16BA3BA2BA7B.F.15BAB3A2BA8B.F.17BABA2BAB2A5B.F$F.18BABAB2A7B
.F.17B2A3BA2BA5B.F.16B4A11B.F.14B2A8B3A4B.F.13B2ABA6B2A2BA3B.F$F.15B
4A4B2ABA4B.F.14B2A3B4A3B2A3B.F.13B5ABA3B5A3B.F.13BA2B4A2B2AB3A3B.F.
13BAB2A2BAB2AB3A4B.F$F.14B2ABABABAB2AB2A3B.F.13B2ABA5B3AB2A3B.F.13BAB
2ABA3BAB4A3B.F.13B2A4BABABAB3A3B.F.13B5ABABABAB3A3B.F$F.13BA2BA5BA8B.
F.14B2AB7ABA5B.F.14BA6B3A7B.F.15BA5BA2BA6B.F.15BA4BAB2A2BA4B.F$F.14BA
BABABA2BA2B3A2B.F.13B3ABA2B3A2B2ABA2B.F.13BABAB3ABA2BABA4B.F.14B2ABA
3B4A6B.F.13B2A2BA3BA2BA6B.F$F.15BABAB4A2BAB2A2B.F.18BA4B2ABABA2B.F.
14BAB2A4BABABABA2B.F.13BA2B2A4B2A3BA3B.F.16B2A5BAB2A4B.F$F.15B2ABA2BA
B4A4B.F.15BA5BABA3BA3B.F.22B3AB2A3B.F.22BABABA4B.F.22BA3B2A3B.F$F.17B
2A4B2AB3A2B.F.17B2A3BA5BA2B.F.27B2A2B.F.23BA2B3A2B.F.21B4ABA4B.F$F.
22BABABABA2B.F.21BABA2BABA2B.F.21B2A8B.F.20B3A8B.F.20BA3BAB2A3B.F$F.
21B3ABA5B.F.21BA9B.F.20BABABA2BA3B.F.20B2ABABA5B.F.18BABA4B2A4B.F$F.
21BABAB2ABA2B.F.21B3AB2A4B.F.20B2ABABA5B.F.17B3A5B2A4B.F.16B2A2BA4B2A
4B.F$F.22BA8B.F.17B2A2BAB2A6B.F.16B6ABABA5B.F.16BA3BA5BA4B.F.15B2A8B
2A4B.F$F.16B4A5B4A2B.F.16BAB2A5BA2BA2B.F.16B2AB2A4BA5B.F.15BAB3A11B.F
.16BABA12B.F$F.16BABA7B2A3B.F.16B2ABA5BA2BA2B.F.16BABABA10B.F.16BABAB
A10B.F.15B3ABA11B.F$F.18BABA10B.F.17BABA11B.F.17BA13B.F.17B2A12B.F.
18BA12B.F$F.16B2ABA11B.F.16BA14B.F.16BA14B.F.17BA13B.F.17BAB2A10B.F$F
.17B2ABA10B.F.16B2AB2A10B.F.19B2A10B.F.15B2A2B3A9B.F.14B2A2BA2BA9B.F$
F.19BAB2A8B.F.15B2AB2A2BA8B.F.14B2ABABABA9B.F.14BA2BA3BA9B.F.13B2A2B
2ABA10B.F$F.14B4A2B2A9B.F.14BA2B2A2BA9B.F.14B4AB3A9B.F.13BA3BA2BABA8B
.F.14BABAB2A11B.F$F.14BAB2A2B3A8B.F.14B5ABABA8B.F.14BA4B3A9B.F.14B2A
3B3A9B.F.13B4A3BA10B.F$F.16B2ABA11B.F.15BA2B2ABA9B.F.16B2A13B.F.15B3A
B3A9B.F.14B2ABAB3A9B.F$F.14B3ABA3BA8B.F.14BA2BAB2ABA8B.F.15BAB2A3BA8B
.F.16BA14B.F.15BABA13B.F$F.14B2AB2AB3A8B.F.16B2AB2ABA8B.F.16B2AB2ABA
8B.F.14BABAB3A2BA7B.F.13BABAB2ABA10B.F$F.15BA3BA11B.F.14BABA4BA9B.F.
13BABABA2BABA8B.F.13BABABAB2A10B.F.12B4A4BA10B.F$F.13B3A2B2A11B.F.13B
AB5A11B.F.13B2A16B.F.12BABA16B.F.12B2A2BABA12B.F$F.14BA2BA13B.F.13BA
2BA14B.F.13B3AB2A12B.F.12B3A2BA13B.F.11BABA17B.F$F.15BA15B.F.14B3A14B
.F.13B2ABA14B.F.12B4A15B.F.12B2ABA15B.F$F.13BABA15B.F.12BAB2A15B.F.
13B2ABA14B.F.31B.F.13BA17B.F$F.12BABA16B.F.13BA17B.F.14BA16B.F.14BA
16B.F.12BA18B.F$F.14BA16B.F.13BABA15B.F.12BA18B.F.11B3A17B.F.11BAB2A
16B.F$F.12B3A16B.F.11BA19B.F.11B2A18B.F.11BA4BA14B.F.10BABA2BA15B.F$F
.11B3AB2A14B.F.11B3AB2A14B.F.11BABAB3A13B.F.11BA3BA15B.F.12BA2BA15B.F
$F.12BA3BA14B.F.13B3ABA13B.F.12BA2BA15B.F.13B2ABA14B.F.12B3A16B.F$F.
12BABABA14B.F.12B2A17B.F.12B3ABA14B.F.12BA18B.F.13BABA15B.F$F.13BA17B
.F.15BA15B.F.14B2A15B.F.14BA16B.F.31B.F$F.13B2A16B.F.13B3A15B.F.15B2A
14B.F.16B2A13B.F.15B3A13B.F$F.15BABA13B.F.15BA2BA12B.F.15B3A13B.F.16B
2A13B.F.16B2A13B.F$F.16BABA12B.F.17BA13B.F.16BA14B.F.14B2A15B.F.13BAB
2A14B.F$F.15BABA13B.F.14B5A12B.F.13B2AB2A13B.F.13B3AB2A12B.F.13B2A2B
2A12B.F$F.14BABA14B.F.13BAB4A12B.F.13BAB4A12B.F.13BABAB2A12B.F.13BABA
B2A12B.F$F.13B7A11B.F.13BA2BA14B.F.17BA13B.F.16BA14B.F.14BA2BA13B.F$F
.14BA16B.F.15BA2BA12B.F.16B3A12B.F.15B2ABA12B.F.17BA13B.F$F.14BAB2A
13B.F.16B3A12B.F.15B2A14B.F.15B3A13B.F.15BA2BA12B.F$F.17B2A12B.F.19BA
11B.F.18B2A11B.F.17B3A11B.F.17BAB2A10B.F$F.17BABA11B.F.17BABA11B.F.
18BA12B.F.20BA10B.F.19BA11B.F$F.19BABA9B.F.18BAB2A9B.F.17B3ABA9B.F.
17B2A12B.F.17B2A12B.F$F.19B3A9B.F.19BABA9B.F.18B2ABA9B.F.17B2AB2A9B.F
.19B2A10B.F$F.20BA10B.F.20BA10B.F.19B2A10B.F.18B2A11B.F.17B3A11B.F$F.
19BABA9B.F.21BA9B.F.21BA9B.F.31B.F.31B.F$F.20B2A9B.F.21BA9B.F.31B.F.
31B.F.31B.F$F.19BA11B.F.31B.F.31B.F.31B.F.31B.F$F.31B.F.31B.F.31B.F.
31B.F.31B.F$F.31B.F.31B.F.31B.F33.F33.F!

I used mgp-tool ingest-1gp in a gross way to construct that although I'm not sure it's particularly relevant. I fed that through to-uwi and then through "pd-fold p5 5" to coalesce all 5 blocks. Then replacing all the exclamation points with asterisks, I get that the tile envelope of the goal looks like this:

Code: Select all

| ............................... |
| ............................... |
| ..............*................ |
| ............*****.............. |
| ........*...*****.............. |
| ......*****.******............. |
| ......************............. |
| ......************............. |
| .....****.*******.............. |
| .....***.********.............. |
| ....***.********.*............. | \
| ....**.*.******.*.............. |  - search 1: 16
| ..***.**.********.............. | /
| ..**************............... |
| ..***************.............. |
| ..***************.............. |
| ...********.****............... |
| ..***************.............. |
| ....*********.**............... |
| ....*************.............. |
| .....*.**.******............... |
| ........*********.............. |
| ..........**.*****............. | \_ choke 1': 8
| ..........*.*.****............. | /
| ...........*******............. |
| ..........*****.**............. |
| ..........******............... | \_ choke 1: 7
| .........******................ | /
| .........*******............... |
| ..........***.****............. |
| ..........**********........... |
| ...........**********.......... |
| ...........**********.......... |
| ..........*********.*.......... |
| .........*********............. |
| ........*******.***............ |
| ........**************......... |
| .........*..**********......... |
| ..........***********.......... |
| ...........***********......... |
| ...........**.**********....... |
| ...............**********...... |
| ...............******.****..... |
| .............***************... |
| .............*******.*******... | \
| .............***********.***... |  - search 2: 16
| .............****************.. | /
| .............****************.. |
| .............*.****..*******... |
| .................**...***.***.. |
| .....................****.***.. |
| ....................********... |
| ..................*.****.**.*.. |
| ................***********.... |
| ...............******....****.. | \_ choke 2: 6 (actually a split, other width 4)
| ...............******....****.. | /
| ...............******.......... |
| ................****........... |
| ................*****.......... |
| ..............*********........ |
| .............*********......... |
| .............**********........ |
| .............*********......... |
| ..............*********........ | \
| ..............*********........ |  - search 3: 11
| .............***********....... | /
| ............*********.......... |
| ............*******............ |
| ...........*******............. |
| ............*****.............. |
| ............***................ | \_ choke 3: 4
| ............****............... | /               \
| ...........****................ |                  - search 4: 8
| ..........****.***............. |                 /
| ...........*******............. |
| ............***.*.............. |
| ............****............... |
| .............****.............. |
| ...............****............ |
| ................***............ |
| .............******............ |
| .............******............ |
| .............*******........... |
| ..............*****............ |
| ..............*****............ |
| ...............*****........... |
| .................****.......... |
| .................*****......... |
| .................*****......... |
| .................*****......... |
| .................***.*......... |
| ....................**......... |
| ...................*........... |
| ............................... |
| ............................... |

I've marked the 3-row windows that I think are widest in their respective searches as well as the 2-row windows that are where the splits would probably be found (thinnest, earliest, although choke 1' is enough earlier than choke 1 that it might matter. Now, for the searches...

First search apparent width 16 requires mid_steps=17 to guarantee cover (how exactly mid_steps and apparent width relate is probably too complex to really explain here but it's more or less off by one in typical setups). It's particularly wide at the front and thinner at the back, so it's possible an aggressive --pre-reify-autochoke could speed this up without losing the part we want (possibly even with a larger mid_steps, if, say, you didn't somehow magically know that 17), but I ran the full version like so:

Code: Select all

$ rlife llsss-recentering-wao --rule 'B2e3-ejnr4ejkn5ajkn6-i/S2-ci3-kry4qw5acei6-i78' c5k-1 '@bg' --wao-tile-error-mask MAX --partials srv2 17

This is also the sort of search I would start with if I were doing this problem from scratch. Rather I would do a line of searches, increasing mid_steps one at a time, until one filled memory and died and then I would read the logs of the last two (one complete and one crashed) for interesting chokes.

mid_steps=17 completed through w_pos 25[4] in ~33 minutes and VmPeak 41.45 GB on my modestly-busy laptop and given the rate of growth of memory I'm not optimistic about making it through w_pos 29[4] to have a shot at finding choke 1 above. It's possible more computer or careful/lucky --pre-reify-autochoke could do it, but I killed it and will settle for what I have here. At 25[4] it didn't even find choke 1', finding instead this somewhat thinner, but mostly matching choke:

Code: Select all

LlsssMonitorSeamRipperV2(2, 4) (choke width 6):
|                      |                      |                      | LLLLLLLLL      RRRRR | LLLLLLLLL      RRRRR |
| LLLLLLLLL      RRRRR | LLLLLLLLL      RRRRR | LLLLLLLLL      RRRRR | ZZZZZZZZZZZZZZZZZZZZ | ZZZZZZZZZZZZZZZZZZZZ |
| ZZZZZZZZZZZZZZZZZZZZ | ZZZZZZZZZZZZZZZZZZZZ | ZZZZZZZZZZZZZZZZZZZZ | .................... | .................... |
| .................... | .................... | .................... | .................... | .................... |
| .................... | .................... | .................... | .................... | .................... |
| .................... | .................... | ..............*..... | .............**..... | ............***..... |
| ..............*..... | .............***.... | .............**.*... | ............*.*..... | ............***..... |
| .............***.... | .............****... | ........*...*.*.*... | .......**...**...*.. | ......***....**..... |
| ........*.....***... | .......***...*..*... | .......**.*.*.***... | ......*.*.**...*.*.. | ......***.*.*.**.... |
| .......***..*.*..... | .......****..*.*.... | ......*.*.*******... | ......**...*****.... | .......***.*....*... |
| ........***..*.***.. | .......*..**..*.**.. | ......*.*.****.*.... | .....*....***.*.*... | ......*...***..*.... |
| ............*.*.*... | .......*...***.*.... | ......*.*.....*..... | ......*....**.*..... | .....*....***..*.... |
| ......**.*..*...*... | .....***...*.***.... | .....*.........*.... | ....**...*.****..... | ....**....****.*.... |
| .....**...****.*.*.. | .....*..*.***....... | ....*.*.*.****...... | ....**....*****..... | ....**....****...... |
| .......*..****...... | .....*...******.*... | ....*.....****...... | ...*.....*****...... | ..***.*...****...... |
| ....*.....******.... | ...*.....*******.... | ..***.**..*****.*... | ..**.***.******..... | ..*.*..*..******.... |
| ...*..***.******.... | ..*******.*****..... | ..*****.********.... | ...****...******.... | ..******..*****..... |
| ..*...***.*****.*... | ...*****..*****.*... | ...*******.******... | ....******.*****.... | ...******.*******... |
| ...*****..*******... | ..**.*****.******... | ..*..*****.******... | .....******.****.... | ...********.***..... |
| ....*******.****.... | ....******..****.... | ...********.****.... | ..**.*****.*.**.*... | ...**.*****..*.*.... |
| ...********.*****... | ...*.******..**.*... | .....******.*....... | ....*.*****.*.*..... | ....******.*..*..... |
| .....*.****.*....... | ......****.......... | .....*.**......*.... | .....**.*.*......... | ....**.....*........ |
| ......*.**..***.*... | ...........*..*..... | .......*...**..*.... | .......**.*..**..... | .......**..*.**..... |
| .....*.*...*.*...... | ........*.***..*.... | ..........****...... | ..........*..**..... | .........*.**....... |
| .........***.**..... | .........*....*..... | ........*.*..***.... | ..........****...... | .........*...**..... |
| ..........*.*....... | ...........*.*...... | ...........*........ | ..........**........ | ..........*.*....... |
| ..........**.*...... | ..........*****..... | .........***.**..... | .........*...**..... | .........*..*.*.*... |
| .............**.*... | .........*.......*.. | ......**.*..**..*... | .......**.**...***.. | ......***....*.**... |
| ........*.**.**..*.. | .....****.**....*... | ........*.*..*..**.. |                      |                      |

This reading logs and looking for good chokes to extend is definitely a thing I would try if taking on the problem from scratch. Here I'm going to focus on trying to find your exact chokes instead.

There are many fiddly ways to extend from a choke, but the simplest to set up is just chop the bottom off and fix the roots. How much bottom to chop is of course more art than science in real cases (here we chop exactly what we must to still find the goal, namely two W rows above the choke) and chopping above the choke can be expensive (requires refinding those wide rows). There are much fancier ways, using fuzzy edges, to allow changing some cells near the choke, but above it, without paying the width expense for the entirety of those rows, but we should see if we can get away without it first and I'm not sure it will even help since it's gonna be mid_steps=17 again anyway. With s2a.in:

Code: Select all

|                        |                        |                        | LLLuuuuuuuuuuuuuuuuRRR | LLLuuuuuuuuuuuuuuuuRRR |
| LLLuuuuuuuuuuuuuuuuRRR | LLLuuuuuuuuuuuuuuuuRRR | LLLuuuuuuuuuuuuuuuuRRR | ...................... | ...................... |
| ...................... | ...................... | ...................... | ...................... | ...................... |
| ...................... | ...................... | ...................... | ...................... | ...................... |
| ...................... | ...................... | ...............*...... | ..............**...... | .............***...... |
| ...............*...... | ..............***..... | ..............**.*.... | .............*.*...... | .............***...... |
| ..............***..... | ..............****.... | .........*...*.*.*.... | ........**...**...*... | .......***....**...... |
| .........*.....***.... | ........***...*..*.... | ........**.*.*.***.... | .......*.*.**...*.*... | .......***.*.*.**..... |
| ........***..*.*...... | ........****..*.*..... | .......*.*.*******.... | .......**...*****..... | ........***.*....*.... |
| .........***..*.***... | ........*..**..*.**... | .......*.*.****.*..... | ......*....***.*.*.... | .......*...***..*..... |
| .............*.*.*.... | ........*...***.*..... | .......*.*.....*...... | .......*....**.*...... | ......*....***..*..... |
| .......**.*..*...*.... | ......***...*.***..... | ......*.........*..... | .....**...*.****...... | .....**....****.*..... |
| ......**...****.*.*... | ......*..*.***........ | .....*.*.*.****....... | .....**....*****...... | .....**....****....... |
| ........*..****....... | ......*...******.*.... | .....*.....****....... | ....*.....*****....... | ...***.*...****....... |
| .....*.....******..... | ....*.....*******..... | ...***.**..*****.*.... | ...**.***.******...... | ...*.*..*..******..... |
| ....*..***.******..... | ...*******.*****...... | ...*****.********..... | ....****...******..... | ...******..*****...... |
| ...*...***.*****.*.... | ....*****..*****.*.... | ....*******.******.... | .....******.*****..... | ....******.*******.... |
| ....*****..*******.... | ...**.*****.******.... | ...*..*****.******.... | ......******.****..... | ....********.***...... |
| .....*******.****..... | .....******..****..... | ....********.****..... | ...**.*****.*.**.*.... | ....**.*****..*.*..... |
| ....********.*****.... | ....*.******..**.*.... | ......******.*........ | .....*.*****.*.*...... | .....******.*..*...... |
| ......*.****.*........ | .......****........... | ......*.**......*..... | ......**.*.*.......... | .....**.....*......... |
| .......*.**..***.*.... | ............*..*...... | ........*...**..*..... |                        |                        |

Code: Select all

$ rlife llsss-recentering --rule 'B2e3-ejnr4ejkn5ajkn6-i/S2-ci3-kry4qw5acei6-i78' c5k-1 s2a.in --partials srv2 17

At w_pos 29[4] it did not even find choke 1. I assume choke 1 is in there, but it is beaten by this thinner choke:

Code: Select all

LlsssMonitorSeamRipperV2(2, 4) (choke width 5):
|                      |                      |                      | LLLLLLLLLLL     RRRR | LLLLLLLLLLL     RRRR |
| LLLLLLLLLLL     RRRR | LLLLLLLLLLL     RRRR | LLLLLLLLLLL     RRRR | LLuuuuuuuuuuuuuuuuRR | LLuuuuuuuuuuuuuuuuRR |
| LLuuuuuuuuuuuuuuuuRR | LLuuuuuuuuuuuuuuuuRR | LLuuuuuuuuuuuuuuuuRR | .................... | .................... |
| .................... | .................... | .................... | .................... | .................... |
| .................... | .................... | .................... | .................... | .................... |
| .................... | .................... | ..............*..... | .............**..... | ............***..... |
| ..............*..... | .............***.... | .............**.*... | ............*.*..... | ............***..... |
| .............***.... | .............****... | ........*...*.*.*... | .......**...**...*.. | ......***....**..... |
| ........*.....***... | .......***...*..*... | .......**.*.*.***... | ......*.*.**...*.*.. | ......***.*.*.**.... |
| .......***..*.*..... | .......****..*.*.... | ......*.*.*******... | ......**...*****.... | .......***.*....*... |
| ........***..*.***.. | .......*..**..*.**.. | ......*.*.****.*.... | .....*....***.*.*... | ......*...***..*.... |
| ............*.*.*... | .......*...***.*.... | ......*.*.....*..... | ......*....**.*..... | .....*....***..*.... |
| ......**.*..*...*... | .....***...*.***.... | .....*.........*.... | ....**...*.****..... | ....**....****.*.... |
| .....**...****.*.*.. | .....*..*.***....... | ....*.*.*.****...... | ....**....*****..... | ....**....****...... |
| .......*..****...... | .....*...******.*... | ....*.....****...... | ...*.....*****...... | ..***.*...****...... |
| ....*.....******.... | ...*.....*******.... | ..***.**..*****.*... | ..**.***.******..... | ..*.*..*..******.... |
| ...*..***.******.... | ..*******.*****..... | ..*****.********.... | ...****...******.... | ..******..*****..... |
| ..*...***.*****.*... | ...*****..*****.*... | ...*******.******... | ....******.*****.... | ...******.*******... |
| ...*****..*******... | ..**.*****.******... | ..*..*****.******... | .....******.****.... | ...********.***..... |
| ....*******.****.... | ....******..****.... | ...********.****.... | ..**.*****.*.**.*... | ...**.*****..*.*.... |
| ...********.*****... | ...*.******..**.*... | .....******.*....... | ....*.*****.*.*..... | ....******.*..*..... |
| .....*.****.*....... | ......****.......... | .....*.**......*.... | .....**.*.*......... | ....**.....*........ |
| ......*.**..***.*... | ...........*..*..... | .......*...**..*.... | .......**.*..**..... | .......**..*..*..... |
| .....*.*...*.*...... | ........*.***..*.... | ..........****...... | ..........*****..... | .........*...*...... |
| .........***.**..... | .........*....*..... | ........*..*.****... | ..........**.*.**... | ..........*..*.**... |
| ..........**.****... | ..............*.**.. | ..............***... | ...............**... | ............*..**... |
| ..........*...*.**.. | ..........*....*.... | ..............*..... | .............*...... | ............*....... |
| ............**..**.. | ...........**....... | ............*.***... | ............*....... | ............*.*..... |
| ............*.*.*... | ...........*.**.**.. | ..........*.**...... | ............**.*.... | ............**...... |
| ............*.*..... | ...........*........ | .................... | .............*...... | ............**...... |
| ............*....... | .................... | ..............*..... | .................... | .............**..... |
| .................... | .............***.... | ............**...... | ............*.**.... | ...............*.... |
| .............****... | ............*....... | .............*.**... |                      |                      |

It did not make it to finding choke 2 before hitting the 60G limit I gave it (last completed w_pos 40[1] while choke 2 would be found at 59[4]). Above this width 5 choke matches choke 1 (and the goal) exactly so I guess I will resume from there, adding roots to make s2b.in:

Code: Select all

|                        |                        |                        | LLLuuuuuuuuuuuuuuuuRRR | LLLuuuuuuuuuuuuuuuuRRR |
| LLLuuuuuuuuuuuuuuuuRRR | LLLuuuuuuuuuuuuuuuuRRR | LLLuuuuuuuuuuuuuuuuRRR | ...................... | ...................... |
| ...................... | ...................... | ...................... | ...................... | ...................... |
| ...................... | ...................... | ...................... | ...................... | ...................... |
| ...................... | ...................... | ...............*...... | ..............**...... | .............***...... |
| ...............*...... | ..............***..... | ..............**.*.... | .............*.*...... | .............***...... |
| ..............***..... | ..............****.... | .........*...*.*.*.... | ........**...**...*... | .......***....**...... |
| .........*.....***.... | ........***...*..*.... | ........**.*.*.***.... | .......*.*.**...*.*... | .......***.*.*.**..... |
| ........***..*.*...... | ........****..*.*..... | .......*.*.*******.... | .......**...*****..... | ........***.*....*.... |
| .........***..*.***... | ........*..**..*.**... | .......*.*.****.*..... | ......*....***.*.*.... | .......*...***..*..... |
| .............*.*.*.... | ........*...***.*..... | .......*.*.....*...... | .......*....**.*...... | ......*....***..*..... |
| .......**.*..*...*.... | ......***...*.***..... | ......*.........*..... | .....**...*.****...... | .....**....****.*..... |
| ......**...****.*.*... | ......*..*.***........ | .....*.*.*.****....... | .....**....*****...... | .....**....****....... |
| ........*..****....... | ......*...******.*.... | .....*.....****....... | ....*.....*****....... | ...***.*...****....... |
| .....*.....******..... | ....*.....*******..... | ...***.**..*****.*.... | ...**.***.******...... | ...*.*..*..******..... |
| ....*..***.******..... | ...*******.*****...... | ...*****.********..... | ....****...******..... | ...******..*****...... |
| ...*...***.*****.*.... | ....*****..*****.*.... | ....*******.******.... | .....******.*****..... | ....******.*******.... |
| ....*****..*******.... | ...**.*****.******.... | ...*..*****.******.... | ......******.****..... | ....********.***...... |
| .....*******.****..... | .....******..****..... | ....********.****..... | ...**.*****.*.**.*.... | ....**.*****..*.*..... |
| ....********.*****.... | ....*.******..**.*.... | ......******.*........ | .....*.*****.*.*...... | .....******.*..*...... |
| ......*.****.*........ | .......****........... | ......*.**......*..... | ......**.*.*.......... | .....**.....*......... |
| .......*.**..***.*.... | ............*..*...... | ........*...**..*..... | ........**.*..**...... | ........**..*..*...... |
| ......*.*...*.*....... | .........*.***..*..... | ...........****....... | ...........*****...... | ..........*...*....... |
| ..........***.**...... | ..........*....*...... | .........*..*.****.... | ...........**.*.**.... | ...........*..*.**.... |
| ...........**.****.... | ...............*.**... | ...............***.... | ................**.... | .............*..**.... |
| ...........*...*.**... | ...........*....*..... | ...............*...... | ..............*....... | .............*........ |
| .............**..**... | ............**........ | .............*.***.... | .............*........ | .............*.*...... |
| .............*.*.*.... | ............*.**.**... | ...........*.**....... |                        |                        |

Code: Select all

$ rlife llsss-recentering --rule 'B2e3-ejnr4ejkn5ajkn6-i/S2-ci3-kry4qw5acei6-i78' c5k-1 s2b.in --partials srv2 17

Even with 60G that did not make it to the marked 16 width bulge, much less to choke 2 behind it. At this point I think I'm lost on tracing your exact steps.

As for your commentary on how you found it it sounds mostly like "repeat extending partial until victory" which is sensible even I can't seem to quickly cough up these exact chokes in my own searches. I assume these were spotted either in "Thinnest partial" outputs or in "Random[ish] partial" outputs? I have found quite a few good partials from thinnest/random myself, but I might also recommend SRV2. It is pretty slow (adds a great deal of time to searches), but it is pretty decent at spotting thin backs that are not necessarily thin the way "Thinnest partial" judges. The only spicy bit to me is:

I did a mid-steps 18 search (earlier mid-steps got nowhere), ...

I find this especially surprising, considering I believe mid_steps=17 should be guaranteed to find the entire ship, if completed (taking who knows how much memory, of course).

On a lark I started the s2b.in search with a mere 100mb --pre-reify-autochoke, hoping to get lucky and slink my way into choke 2. Instead it found this complete ship after which I gave up and killed it (all SRV2 outputs after that will be zero slices forever):

Code: Select all

x = 146, y = 65, rule = B2e3-ejnr4ejkn5ajkn6-i/S2-ci3-kry4qw5acei6-i78History
F28.F28.F28.F.26B.F.26B.F$F.26B.F.26B.F.26B.F.26B.F.26B.F$F.26B.F.26B
.F.26B.F.26B.F.26B.F$F.26B.F.26B.F.14BA11B.F.13B2A11B.F.12B3A11B.F$F.
14BA11B.F.13B3A10B.F.13B2ABA9B.F.12BABA11B.F.12B3A11B.F$F.13B3A10B.F.
13B4A9B.F.8BA3BABABA9B.F.7B2A3B2A3BA8B.F.6B3A4B2A11B.F$F.8BA5B3A9B.F.
7B3A3BA2BA9B.F.7B2ABABAB3A9B.F.6BABAB2A3BABA8B.F.6B3ABABAB2A10B.F$F.
7B3A2BABA11B.F.7B4A2BABA10B.F.6BABAB7A9B.F.6B2A3B5A10B.F.7B3ABA4BA9B.
F$F.8B3A2BAB3A8B.F.7BA2B2A2BAB2A8B.F.6BABAB4ABA10B.F.5BA4B3ABABA9B.F.
6BA3B3A2BA10B.F$F.12BABABA9B.F.7BA3B3ABA10B.F.6BABA5BA11B.F.6BA4B2ABA
11B.F.5BA4B3A2BA10B.F$F.6B2ABA2BA3BA9B.F.5B3A3BAB3A10B.F.5BA9BA10B.F.
4B2A3BAB4A11B.F.4B2A4B4ABA10B.F$F.5B2A3B4ABABA8B.F.5BA2BAB3A13B.F.4BA
BABAB4A12B.F.4B2A4B5A11B.F.4B2A4B4A12B.F$F.7BA2B4A12B.F.5BA3B6ABA9B.F
.4BA5B4A12B.F.3BA5B5A12B.F.2B3ABA3B4A12B.F$F.4BA5B6A10B.F.3BA5B7A10B.
F.2B3AB2A2B5ABA9B.F.2B2AB3AB6A11B.F.2BABA2BA2B6A10B.F$F.3BA2B3AB6A10B
.F.2B7AB5A11B.F.2B5AB8A10B.F.3B4A3B6A10B.F.2B6A2B5A11B.F$F.2BA3B3AB5A
BA9B.F.3B5A2B5ABA9B.F.3B7AB6A9B.F.4B6AB5A10B.F.3B6AB7A9B.F$F.3B5A2B7A
9B.F.2B2AB5AB6A9B.F.2BA2B5AB6A9B.F.5B6AB4A10B.F.3B8AB3A11B.F$F.4B7AB
4A10B.F.4B6A2B4A10B.F.3B8AB4A10B.F.2B2AB5ABAB2ABA9B.F.3B2AB5A2BABA10B
.F$F.3B8AB5A9B.F.3BAB6A2B2ABA9B.F.5B6ABA13B.F.4BAB5ABABA11B.F.4B6ABA
2BA11B.F$F.5BAB4ABA13B.F.6B4A16B.F.5BAB2A6BA10B.F.5B2ABABA15B.F.4B2A
5BA14B.F$F.6BAB2A2B3ABA9B.F.11BA2BA11B.F.7BA3B2A2BA10B.F.7B2ABA2B2A
11B.F.7B2A2BA2BA11B.F$F.5BABA3BABA12B.F.8BAB3A2BA10B.F.10B4A12B.F.10B
5A11B.F.9BA3BA12B.F$F.9B3AB2A11B.F.9BA4BA11B.F.8BA2BAB4A9B.F.10B2ABAB
2A9B.F.10BA2BAB2A9B.F$F.10B2AB4A9B.F.14BAB2A8B.F.14B3A9B.F.15B2A9B.F.
12BA2B2A9B.F$F.10BA3BAB2A8B.F.10BA4BA10B.F.14BA11B.F.13BA12B.F.12BA
13B.F$F.12B2A2B2A8B.F.11B2A13B.F.12BAB3A9B.F.12BA13B.F.12BABA11B.F$F.
12BABABA9B.F.11BAB2AB2A8B.F.10BAB2A12B.F.12B2ABA10B.F.12B2A12B.F$F.
12BABA11B.F.11BA14B.F.10BA15B.F.9BA16B.F.12B2A12B.F$F.12BA13B.F.11BAB
A12B.F.10BABA13B.F.9BABA2B2A10B.F.8BABA5BA9B.F$F.12B3A11B.F.11B2AB2A
10B.F.10B2AB4A9B.F.9B2AB5A9B.F.8B2A2BAB2ABA8B.F$F.9BA2BA2BA2BA7B.F.9B
A2BA2B2A9B.F.10BA2B4A9B.F.9BA4B2ABA8B.F.13BA12B.F$F.9B3A3B2A9B.F.11B
2A3BA9B.F.8B4A2BABA9B.F.7B2AB3A3BA9B.F.6BABA3BA13B.F$F.8BA5BA11B.F.7B
2ABA2B2A11B.F.7B2A4B3A10B.F.6B3ABAB2AB2A9B.F.6B2A2B2A3B2A9B.F$F.7BA5B
2A11B.F.7B2A6BA10B.F.6BA6BA12B.F.7BA4BABA11B.F.12B3A11B.F$F.7B3A3B2AB
A9B.F.7BA4BA13B.F.7BA5B2A11B.F.7BA5B3A10B.F.15BA10B.F$F.13BA2BA9B.F.
8BA4BABA10B.F.7BA7BA10B.F.12B2ABA10B.F.11B3AB2A9B.F$F.15B3A8B.F.12B4A
BA8B.F.11B2A3B2A8B.F.11B4A2B2A7B.F.10B2AB2A2B2A7B.F$F.11B2ABA2BA8B.F.
11B2A2B3A8B.F.11BABABAB2A7B.F.10BA2BABAB2A7B.F.10B3A4B2A7B.F$F.12BA2B
A2B2A6B.F.12BA3BA2BA6B.F.11B3ABA10B.F.10BABA13B.F.10BA2BABA10B.F$F.
10BA3BA2B3A6B.F.14BAB2ABA6B.F.11B3ABAB3A6B.F.11B4AB2A8B.F.10BA3BAB3A
7B.F$F.10BABABA2BA8B.F.10B2ABABA2BA7B.F.14B4A8B.F.12BAB2A2BA7B.F.11B
3ABABA8B.F$F.11BAB2ABAB2A6B.F.14BA2BABA6B.F.13B3A2B3A5B.F.14B3A3BA5B.
F.13B2AB2ABABA4B.F$F.11B2A4BABA6B.F.11B3A4BABA5B.F.13B2A2B3A6B.F.13BA
4B2ABA4B.F.14BA3BAB3A3B.F$F.14BAB2ABA2B2A2B.F.16BA2BA2B2A2B.F.12BA2BA
B2AB3A3B.F.15B2ABABABA3B.F.14B3ABAB3A3B.F$F.16BABA3BA3B.F.15BABAB3A4B
.F.15B3A3B2A3B.F.15BA3BA2BA3B.F.17B3A6B.F$F.15BAB2AB4A2B.F.15B3AB2A2B
A2B.F.17BA2BA5B.F.14BABA3BA5B.F.13BA2BAB2A6B.F$F.15B5A2BA3B.F.14B2A4B
2ABA2B.F.13B3AB2AB2A4B.F.13B3AB2A7B.F.12BA4BABA6B.F$F.13BA5BABA4B.F.
13B2A3BA2BA4B.F.13B3ABA2B2A4B.F.12BABA5B2A4B.F.12BAB2A3BA6B.F$F.13B5A
BABA4B.F.13BA3BA8B.F.13BABAB2A7B.F.12BA5BA7B.F.11BAB2A11B.F$F.15B2A9B
.F.14B3A9B.F.13B2ABA9B.F.12B2ABA10B.F.13BA12B.F$F.13BAB2A9B.F.15B2A9B
.F.13BA2BA9B.F.11BA14B.F.10B2AB2A11B.F$F.26B.F.11B2ABA11B.F.10B3ABA
11B.F.10BA3BA11B.F.9B2AB2ABA10B.F$F.10B4A2BA9B.F.10BA2BAB2A9B.F.10B2A
B2ABA9B.F.9BABABABA10B.F.10B2ABABA10B.F$F.10BAB2AB2A9B.F.10B3A2BA10B.
F.10BA4BA10B.F.10BAB2AB3A8B.F.9B3ABABABA8B.F$F.11BABA3BA8B.F.13BA3BA
8B.F.12BA3B3A7B.F.11BA4BAB2A6B.F.15B2A2BA6B.F$F.10BABA4BA8B.F.11BA5B
2A7B.F.10BA5B2ABA6B.F.11BA6BA7B.F.11BA5BA8B.F$F.11BABA2BA2BA6B.F.10BA
6BABA6B.F.11BA5BA8B.F.10BA7BA7B.F.11BA6B2A6B.F$F.18B2A6B.F.18BA7B.F.
17B3A6B.F.17BA2BA5B.F.17B3A6B.F$F.20BA5B.F.19B2A5B.F.18B3A5B.F.17B3A
6B.F.17BA8B.F$F.18BABA5B.F.17BAB2A5B.F.19B2A5B.F.18BABA5B.F.17B2A7B.F
$F.17BABA6B.F.26B.F.26B.F.26B.F.26B.F$F.18B2A6B.F.17B3A6B.F.26B.F.26B
.F.26B.F$F.26B.F.26B.F.18BA7B.F.26B.F.26B.F$F.26B.F.26B.F.26B.F.26B.F
.26B.F$F.26B.F.26B.F.26B.F28.F28.F!

[LuveelVoom]

Even with 60G that did not make it to the marked 16 width bulge, much less to choke 2 behind it. At this point I think I'm lost on tracing your exact steps.

As for your commentary on how you found it it sounds mostly like "repeat extending partial until victory" which is sensible even I can't seem to quickly cough up these exact chokes in my own searches. I assume these were spotted either in "Thinnest partial" outputs or in "Random[ish] partial" outputs? I have found quite a few good partials from thinnest/random myself, but I might also recommend SRV2. It is pretty slow (adds a great deal of time to searches), but it is pretty decent at spotting thin backs that are not necessarily thin the way "Thinnest partial" judges.

Yes, I searched through them by eye. Randomish happened to have the best outputs in this case.

I did a mid-steps 18 search (earlier mid-steps got nowhere), ...

I find this especially surprising, considering I believe mid_steps=17 should be guaranteed to find the entire ship, if completed (taking who knows how much memory, of course).

Unfortunately, I appear to have lost the search parameters, but seeing the direction of your search I think it's probably more likely I did a mid-steps 17 search and misremembered it as mid-steps 18.

On a lark I started the s2b.in search with a mere 100mb --pre-reify-autochoke, hoping to get lucky and slink my way into choke 2. Instead it found this complete ship after which I gave up and killed it (all SRV2 outputs after that will be zero slices forever):

Lucky!!

How long did this search take overall?

[LaundryPizza03]

Is there a way to get a search like this to not get stuck on various repeating components that significantly slow down things and make it difficult to tell if it has other paths besides them? It's probably not just them causing the eventual slowdown, but I imagine it contributes. I assume wcaf doesn't work here to do so because of the geometry in some way.

Code: Select all

./rlife llsss-recentering-wao --rule B2-k3knq4aeirwy5-kq6cek78/S1c2cen3enr4-ijqtw5ejny6-i78 --filters wcaf --wao-left-edge-errors --left-edge bg raw:1:0:0:-1:-7:8:0:1:0 '@bg' 25

Ah, here is the other boot drop on what I was answering just above. Mostly probably see that post, although some of the questions I had are now answered. I still don't have a good subjective feeling of the rule / search space and without one it's gonna be hard to give much more specific advice about the options. I guess add to the questions: how do you feel about the c/2d back edges and large all-on sections? Some variants of forbidden transitions or forbid_block would be reasonably effective at avoiding them if you don't mind losing (all partials with) them.

WCAF specifically only works if the cycle repeats along a multiple of the W vector. I think the above linked one might be a multiple of -X+Y so if you point W that way you could maaaaybe do it. It also requires starting from the cycle and is a pain to use. Add to it how long this cycle is and the implication above that there are "various" cycles and I don't think it's probably the right pick.

I am tickled enough by the problem ("find any (7, 1)c/8" and perhaps "in this rule") that I might be interested in taking a look myself. If you are okay with that (and the risk of getting partly scooped), please let me know, unambiguously, and I shall try to restrain myself otherwise.

EDIT: I might add about that command: --filters wcaf is doing nothing as WAO does a better job of keeping stuff out. --left-edge bg is more or less the default and is doing nothing. --wao-left-edge-errors is only making more confusing WAO indices that will all die on the first row when the all-background edge refuses to expand the edge into them. --wao-tile-error-mask MAX is applicable here and if added I would expect to reduce memory for otherwise-comparable searches.

The initial answer didn't really explain why it isn't always possible to detect repeating components with the LSSS-type search method. In particular, checking if the latest row in a branch matches a previous one in the same partial, which is roughly what gfind and qfind do. Although, your advice on wcaf and changing the search orientation sounds useful.

[amling]

I have been standardizing all the terminology in the partial cutter.

Lol. If you read the 24 pages of thread so far (not recommended, but maybe ask your LLM for giggles?) you would discover how very much consistent and sensible names are not a virtue of mine. We should definitely do what we can while we are thinking about it. Some of these bullet points seem more like LLSSS word salad to me, looking like they belong on this thread, but not meaning anything to me. Some seem like they're weird concerns of the your partial cutter alone and are sort of distant from me. I'll try to go through the ones that make more sense to me...

Code: Select all

Mode names: "Recentering: extend and let it widen", "Fixed board: extend at a fixed width", "Split into branches, axis constraint", "Split into branches, empty columns at the axis", "Solve a branch beside its sibling (fuzzy left edge)", "Back only (narrow question marks)", "Cut along a drawn line". They use sourced words, but the modes have no LLSSS names.
Both halves versus the branch alone: his plan A and plan B are close, but his plan B for recentering drops the question marks, so I don't reuse the names.

LLSSS setup is just so configurable that I haven't named every possible way you could hang boundary conditions together to try to extend something someone has called a partial. When I get around to it, my plan is to call the mgp-tool to-fixed-input (and @yolo_1gp for fixed board) cases e.g. "odd" and "odd/split" but even that's like a pretty local concern (an aspect of mgp-tool not of the greater LLSSS ecosystem).

Code: Select all

Tool names: "partial builder", "Stitcher" (the thread says "stitching", but has no tool by that name) and "grid workbench". ||| Luveel note: the partial stitcher is a really terrible tool that the AI has repeatedly said it will fix but which it has consistently failed to do, just ignore that for now. It is intended to combine a found continuation to the initial frontend into a full ship by linking them together, which is irritating to do manually.

It's possible it's wondering about:

If I'm gonna invent horrible tools for branching, turning, and stitching searches, I might as well use them:

This post is quoted by a post in the, uh, "amling thread database", but I guess I can't rightly claim to have invent a stitching tool per se, just to be a moderately accomplished user of vim's block mode. The rest of this bullet point seems like word salad to me.

Code: Select all

The start file format: amling says it has no name ("we should really name this format").

It's likely I was saying that about the general case of multiple generations separated by pipes and less about starting grids. I do agree we should name that. I think Sokwe's golly lua dumper calls them "LLSSS phase charts" and I think "chart" isn't used yet in LLSSS terminology so I guess let's start calling them that. An "XYT chart" is made of multiple generations separated by pipes. Each generation has its own distinct, ascending T value. The lines of the file have distinct, ascending Y values. In each generation, the columns have distinct, ascending X values. A "UWI chart" is made of multiple sections separated by pipes. Each section is ... we didn't talk about UWI view yet, did we? Well, "UWI charts" also exist and look similar but the coordinates mean something else. Inputs to searches, called "start files" in many places, are XYT charts, but have a bunch of other rules about shapes and how they're interpreted.

Code: Select all

The layout checks my validator ports from rlife (previously "shape rules").

I assume this is talking about generally demanding that XYT charts be complete UVW prisms. So far, historically, this has meant "ask amling to make your grids", "don't use grids, use magic grid generations like @bg", or "read example grids for your geometry and ape them as best you can". I have probably said "make UVW prisms" two dozen times on this thread at this point and that is really the central, more-or-less-named concept that I think is relevant here. I recognize that UVW coordinates aren't really approachable and most people are going to learn the, uh, shape rules that "UVW prisms" translate to in various geometries, but I'm not quite sold on inventing a name for that.

Code: Select all

The bracketed percentages on Completed lines.

Those are a sort of estimate of how much better/worse the number that precedes them is compared to the previous analogous number. Note analogous for the "Completed" lines is the same number from the last "Completed" line with the same subtile position. E.g. if the lines are "Completed w_pos 7[0]", "7[1]", "8[0]", "8[1]" then the numbers from the third are comparing themselves to numbers from the first and the fourth is comparing itself to the second. The estimate ranges from -100% when the second number is zero up to, asymptotically, +100% as the second number gets arbitrarily large. Close to +0% they are close to accurate percentage changes. The formula is:

Code: Select all

200.0 * (next - prev) / (prev + next)

I recognize this was a weird choice, but I sort of like the boundedness of the value (-100 to 100). I don't think this needs a name as as far as I'm aware no one has ever talked about it before this moment.

EDIT: Oops, I just realized this is bounded by -200 and 200, not by -100 and 100. This was what I had to accept to make the numbers accurate percentages near zero.

Code: Select all

"Blows up" for a search that doubles each row: amling uses it once, for output size.

I might use that phrase a lot for things getting bigger quickly. I don't think there's a particularly coherent and relevant concept here to be given a glossary name though. Also note that searches can get much worse than doubling each row. With AF2=3 a jcol can expand by a factor of up to 2^3 = 8 each bit and a full W rows can contain many bits.

All of the following are somewhere between word salad and some sort of partial cutter-specific concern and so I don't really think there is much for me to make of them myself:

Code: Select all

Cells a constraint file sets to the partial's values in cut-line mode (previously "pinned").
The part of the partial above the drawn line (previously "known side").
Lines to keep: an option name. "Line" itself is sourced.
Backtrack: LuveelVoom uses it in this sense in the thread; amling doesn't. ||| Luveel note: the LLM has my personal name as the account name so it doesn't know who LuveelVoom is
Padding left/right in Back-only mode: written into the file rather than passed as --left-pad or --right-pad.

These just seem like pure word salad:

Code: Select all

The branch further from the axis in the fuzzy-left-edge mode. The other branch is the sibling branch, which is sourced.
Extra columns: the wiki uses this for width beyond the ship, a slightly different sense.
The Stitcher's merge terms: "rewritten by the search", and cells that agree or differ.

[amling]

On a lark I started the s2b.in search with a mere 100mb --pre-reify-autochoke, hoping to get lucky and slink my way into choke 2. Instead it found this complete ship after which I gave up and killed it (all SRV2 outputs after that will be zero slices forever):

Lucky!!

How long did this search take overall?

15 minutes from start to first hit on my modestly-busy laptop. This does not count the 1MB and 10MB searches I let run for a bit first though. You say lucky, but I think using PRAC to finish searches that have gotten to a distinct narrowing is a move that gets lucky a lot.

[LuveelVoom]

I have been standardizing all the terminology in the partial cutter.

Lol. If you read the 24 pages of thread so far (not recommended, but maybe ask your LLM for giggles?) you would discover how very much consistent and sensible names are not a virtue of mine. We should definitely do what we can while we are thinking about it. Some of these bullet points seem more like LLSSS word salad to me, looking like they belong on this thread, but not meaning anything to me. Some seem like they're weird concerns of the your partial cutter alone and are sort of distant from me. I'll try to go through the ones that make more sense to me...

I do agree that a few of these are nonsensical; however, most of the ones you described as word salad are (as you guessed) very specific things it decided to include in descriptions in the partial cutter.

The stitcher is going to be discontinued and I am going to try and get it to stop working on it. It's really just a minor inconvenience to manually connect partials. (Also, many of the word salad things are related to it... I think it's getting confabulated there)

As you mentioned earlier, since LLSSS has evolved a lot over the 24 pages, the earlier pages contain a lot of stuff that can get it mixed up with the later pages. I'm going to keep working on getting the terminology, at least the key components, to correspond to those LLSSS uses.

[amling]

(about repeating components)

The initial answer didn't really explain why it isn't always possible to detect repeating components with the LSSS-type search method. In particular, checking if the latest row in a branch matches a previous one in the same partial, which is roughly what gfind and qfind do. Although, your advice on wcaf and changing the search orientation sounds useful.

The short answer is it really doesn't work that way. Nearly no one understands how LLSSS works, which is fine, but it means you really can't be trying to dictate algorithm implementations.

In the initial answer I had written:

This is sort of a problem with (my understanding of) LSSS descendants, as opposed to (my understanding of) gfind descendants, where pruning some part of the search you don't like is an effective notion.

It's a long sentence, but one of the things it is trying to say, although perhaps somewhat backwardly, is "pruning some part of the search you don't like is [not] an effective notion [for my understanding of LSSS descendants]".

There was a similar exchange about a similar sort of feature that is easy in (my understanding of) gfind descendants, buried on some other thread, ending with my writing:

Due to the way LLSSS stores partials (as collection(s) of possible vertical strips) there is no real global state and very much no collection of fully-realized partial results. Any partials output along the way are an illusion, constructed by complicated code which picks some path through the mess. Given this (weird storage of state) I just don't see any way to swing anything that could be described as "object separation and branch disqualification".

This is equally applicable here, just replacing "object separation and branch disqualification" with "repeat detection".

[LuveelVoom]

I attempted to do the opposite of what I did to find the knightship: start with a small pattern and widen, using the new partials to reduce the search space by predetermining the frontend, allowing for larger mid-steps as one descends.

Now, this did appear to work! However, I chose an extremely bad partial to deepen on, as the specific branch of the search that seemed promising turned out to be merely a facade for a well of failure.

Code: Select all

x = 21, y = 49, rule = LifeHistory
10.A$9.A.A2$8.2A.2A$7.3A.3A$7.A5.A$7.A5.A3$4.3A7.3A$4.A.2A5.2A.A$5.A4.
A4.A$9.3A2$9.3A$10.A$9.3A$8.A3.A$7.A.A.A.A$7.A5.A3$8.2A.2A$8.A.A.A$8.
A.A.A$10.A$9.A.A$8.2A.2A$7.A2.A2.A$7.2A3.2A$6.2A.3A.2A$3.A3.2A.A.2A3.
A$3.A13.A$2.A5.A3.A5.A$4.2A2.2A.2A2.2A$4.2A2.2A.2A2.2A$7.2A3.2A$4.A2.
A5.A2.A$3.A3.2A3.2A3.A$.2A2.3A.3A.3A2.2A$.A.2A.2A5.2A.2A.A$A.A3.A3.A3.
A3.A.A$.A2.A.A.5A.A.A2.A$7.2A.A.2A$6.A.2A.2A.A$.2A.4A2.A2.4A.2A$4.2A.
7A.2A$7.A5.A$5A3.A3.A3.5A!

I have chosen a different split near the top and am hopeful that it might be completable. Will update this post as things develop. Anyway, this partial cutting strategy seems promising, especially with the above knightship. LLM-generated thingamajig-partial-maker-accessibility aside, do you think this strategy could be useful in the future?

(The specific split I'm working on):

Code: Select all

x = 19, y = 37, rule = B3/S23
9bo$8bobo2$7b2ob2o$6b3ob3o$6bo5bo$6bo5bo$b3o11b3o$3bo11bo$3bob3o3b3ob
o$5b3o3b3o2$4bo9bo$2b4o7b4o$b2o3bo5bo3b2o$bo2b2o7b2o2bo$2o15b2o$2o15b
2o$3bo11bo$o17bo$o17bo$bobo11bobo$3b2o9b2o$3b2o9b2o2$b2obo9bob2o$2b3o
9b3o$2b2ob2o5b2ob2o$5b2o5b2o$3bo11bo$5bo7bo$2b2obobo3bobob2o$2b3o9b3o
$3bo2bo5bo2bo$b3o2bo5bo2b3o$b2o4bo3bo4b2o$2bo2bob2ob2obo2bo!

Edit: Sadly, this search is a failure. The search cannot stop blowing up just below partial joints.

(I'm also rethinking my plan of creating accessibility programs for complex features; the LLM is starting to get stuck in bogs. It's probably not viable (using AI, anyway), at least not for the next 6 months or so. Hopefully the world doesn't end by then... I'll attempt a little more development on this, and start cross-checking the explanations with my (now somewhat expanded) knowledge of LLSSS's workings; once it gets to a state that's not spewing misinformation the community can look at it in more detail. (you can veto this if you think it will be a problem))

And, of course, any published object will come with big bold bright red letters every other sentence telling the user that they should not take any errors or questions (about the partial cutter) to amling (unless, of course, the error occurs on files that don't come from the partial cutter too) !!!

edit: I should probably OCR those notes now...

[amling]

...start with a small pattern and widen, using the new partials to reduce the search space by predetermining the frontend, allowing for larger mid-steps as one descends.

... The search cannot stop blowing up just below partial joints.

This is also mostly my experience trying to widen searches as you go down. It's true that fixing the top allows wide(r) mid_steps and the whole idea is appealing because it lets you get longer partials, but it just never seems to translate into eventually thinning. This is how a lot of unlimited mid_steps PRAC searches seem to end, in these long, wide pyramids that were clearly just getting worse and worse most of the way.