Amling, do you think this is enough warnings? (This version isn't going to be released yet, by the way; the guide tab is riddled with errors and the partial builder has tons of bugs and contains no info on what modes are useful. I'm going to rewrite the text by hand.)
Screenshot 2026-10-01 at 6.29.17 PM.png (227.97 KiB) Viewed 554 times
Edit: While I was paying attention to something else, Claude decided to COMPILE THE ENTIRETY OF LLSSS ON A MACHINE WITH ONE CORE AND 3GB OF RAM FOR ONE BUGFIX.
There's a very unhappy CPU somewhere deep in a datacenter.
Needless to say, it did not go well. I went ahead and ran some tests and gave it the files to look at instead.
Update: At the moment, I am having it rewrite the tools which can be done with your new commands to utilize your new commands instead of the weird input file workarounds. We will see if this works out, I hope it does.
Update 2: LLSSS is having fun with a mid-steps 10 recentering search right now, taking up 70 gigs (nope, 80 (now 85)! Why doesn't phpbb have strikethroughs????????) of ram on my 48 gig computer by compressing 25 gigs of it, which I'm sure is very efficient
Update 3: And here is the result, partial cut indicated (this could probably have been found normally, but oh well)
LuveelVoom wrote: October 1st, 2026, 9:31 pm
Amling, do you think this is enough warnings?
(screenshot)
I am grateful for your understanding and attention about trying not to make a mess for me, so please understand that I really do appreciate all the concern, but I think that screenshot is probably a bit overkill.
There are a lot of ways the existence of a piece of software can change the world around it and specifically a lot of ways the partial cutter and your efforts on it could, even just from the strict selfish perspective of my own personal wishes, make things better or worse and I think the contents of that screenshot are a little overfocused on just a part of that.
I think making clear that it's a distinct tool from LLSSS, by a distinct author is the most valuable. I think making clear that it's possibly a little buggy and somewhat on the vibe-coded side is also quite useful. Both of these (distinct program and LLM/buggy nature) are simple facts that I think sensible users will be able to translate into their implications for expectations about the software and its support. There is always going to be a tail of insensible users and worrying about what they will do is hopeless.
As for the focus on this thread and/or my metaphorical desk, I think trying to figure out what your intended support path is, in a positive sense, is probably a better use of energy. You could ask users to DM you, although it's unfortunate for such to private. You could make a separate thread, but I assume this thread and that thread are going to end up linking each other all the time which makes it a bit silly. It's true that users posting on this thread is in a sense a support burden for me, but I think a lot of it is ameliorated by: (a) their understanding/expectations about it being a separate program, (b) their bug report quality, especially do they make clear they've used the partial cutter and do they post its inputs and outputs, and (c) your (hopefully) pitching in triaging and resolving them, especially when/if it seems like LLSSS is doing the right thing for its own inputs. I know this is a little hypocritical given my previous attempts to flee the blast radius, but I guess maybe I'm coming to think telling users to post here is reasonable and instead it's better to focus on influencing them to provide clearly all the details when they do.
LuveelVoom wrote: October 1st, 2026, 9:31 pm
LLSSS is having fun with a mid-steps 10 recentering search right now, taking up 70 gigs (nope, 80 (now 85)! Why doesn't phpbb have strikethroughs????????) of ram on my 48 gig computer by compressing 25 gigs of it, which I'm sure is very efficient
Uh, I assume that's tongue in cheek and it is not efficient? Do you know what the mechanism of compression is? There was a question earlier about how zram/zswap do earlier and if you have any data about it, I think the thread is interested.
amling wrote: October 2nd, 2026, 12:16 pm As for the focus on this thread and/or my metaphorical desk, I think trying to figure out what your intended support path is, in a positive sense, is probably a better use of energy. You could ask users to DM you, although it's unfortunate for such to private. You could make a separate thread, but I assume this thread and that thread are going to end up linking each other all the time which makes it a bit silly. It's true that users posting on this thread is in a sense a support burden for me, but I think a lot of it is ameliorated by: (a) their understanding/expectations about it being a separate program, (b) their bug report quality, especially do they make clear they've used the partial cutter and do they post its inputs and outputs, and (c) your (hopefully) pitching in triaging and resolving them, especially when it seems like LLSSS is doing the right thing for its own inputs. I know this is a little hypocritical given my previous attempts to flee the blast radius, but I guess maybe I'm coming to think telling users to post here is reasonable and instead focus on influencing them to provide clearly all the details when they do.
This makes sense. The reason I included so many warnings was because of unreasonable users who might ignore their judgement on AI-generated software, run up against a wall due to buggy LLM code, and come over here. On second thought, I think there probably aren't that many users in this community who would both be unreasonable and be able to compile LLSSS (there are plenty of unreasonable users, but the tool requires LLSSS to actually do anything, and I don't think any of those unreasonable users actually have tried to use LLSSS.)
I think the best strategy is:
-Including a warning, but not as absurd as the warnings above (just one box at the top, plus another for the guide until it is updated)
-Having a thread for "my" scripts, and a support link to that thread clearly marked inside the program,
-If someone comes over to my thread with a simple question, I can solve it and add it to a list of QAs inside the program
-If someone comes over to my thread with a complex issue, I can ask them to create a detailed report and bring it to you.
Having this thread will be useful when I create more "wrapper" scripts for various CA programs. As I have stated before, my goal with these sorts of programs is to make CA search programs more accessible. It is foolhardy to embark on writing a search program with AI (certain people in the discord have made attempts, which have all ended badly), but AI can manage a GUI which outputs files or sends shell commands or whatever to run a program, and that makes it far easier to debug and fix, while still massively helping users navigate programs. (I hope you are not upset that I chose LLSSS as the first program to try this strategy on... maybe APGsearch would have been a better pick, I just happened to want to build partial files for a different reason when I came up with this idea.)
Update: Here is a more reasonable warning:
Screenshot 2026-10-02 at 9.41.32 AM.png (132.99 KiB) Viewed 486 times
At some point I am going to write down my current idea of when the partial cutter is most useful (ooo, that gives me another idea: a thread for "tips and tricks when using search programs" (in the format of MDIOCA), where people share techniques for best using various search programs).
amling wrote: October 2nd, 2026, 12:16 pm Uh, I assume that's tongue in cheek and it is not efficient? Do you know what the mechanism of compression is? There was a question earlier about how zram/zswap do earlier and if you have any data about it, I think the thread is interested.
It's certainly not efficient (although there's not anything you can do that would help that (other than lowering the memory usage of LLSSS), since it's a component of my system), LLSSS massively slowed down as soon as it started cutting into compressed memory. I will look into how it compresses it and update this post. (M4 Macbook Pro, if that helps, running Sequoia 15.1).
LuveelVoom wrote: October 2nd, 2026, 12:34 pm
Having a thread for "my" scripts, and a support link to that thread clearly marked inside the program,
If you want to go with the separate thread, that seems reasonable enough. Please consider me very much available for and committed to answering what LLSSS does with a grid and why. While I may have mixed feelings about the partial cutter itself, I have no mixed feelings about attempting to grow and refine your human understanding and hopefully that will trickle down to the partial cutter.
amling wrote: October 2nd, 2026, 12:57 pm
If you want to go with the separate thread, that seems reasonable enough. Please consider me very much available for and committed to answering what LLSSS does with a grid and why. While I may have mixed feelings about the partial cutter itself, I have no mixed feelings about attempting to grow and refine your human understanding and hopefully that will trickle down to the partial cutter.
Alright, I hope you're prepared for about 20 questions when I get around to completely rewriting the guide... they're going to a human's brain, if that helps
Anyway, this program isn't going to be released for a while (probably around a week?) while I work on refining it (including that guide rewrite as mentioned above). Next up on the cutting block is getting diagonal cutting to work. Do you happen to have even-symmetric, odd-symmetric, and asymmetric diagonal partials anywhere on hand? (Anyone reading this thread, if you have these, DM them to me)
LuveelVoom wrote: October 2nd, 2026, 12:58 pm
Do you happen to have even-symmetric, odd-symmetric, and asymmetric diagonal partials anywhere on hand? (Anyone reading this thread, if you have these, DM them to me)
I assume that "even" should be "gse". When I need examples usually I take existing ships that fulfill the symmetry and chop their backs off. Here are (a) a very asymmetric c/5d ship, (b) an odd symmetry c/5d ship, and (c) a gse c/6d ship, all grabbed semi-randomly from jslife-moving:
NNlk05 wrote: October 2nd, 2026, 9:23 pm
So far, I haven't seen ./rlife llsss-recentering used. What is the use case, and how does it differ from llsss-recentering-wao?
It makes more sense to ask/answer in reverse, i.e. "how is recentering WAO different from recentering?", which you more or less already asked here.
In my response then I quoted the tutorial that what WAO does is:
amling wrote: September 17th, 2026, 12:41 am
"force (a) live cell(s) in the first row"
So non-WAO recentering differs from WAO recentering by ... not doing that. About recentering in the first place, the tutorial says:
llsss-recentering is a variant of LLSSS that allows the center of the search to drift to the left or right analogously to floating rows in ikpx.
Can you please read the tutorial before asking any more questions?
I had an idea for avoiding repeating components. Couldn't you store W-rows of the spaceship in lookup tables, detect when they match earlier rows with no differences (other than perhaps temporal displacement) and no causal interaction with different rows, and discard those solutions in favor of different solutions? If that takes too much memory, perhaps a bloom filter could be used?
Additionally:
LuveelVoom wrote: October 2nd, 2026, 12:58 pm
Alright, I hope you're prepared for about 20 questions when I get around to completely rewriting the guide... they're going to a human's brain, if that helps
My executive function is not helping me out with the 10 page guide Claude claims is absolutely vital 1000% for using the program. I skimmed it and it is not absolutely 1000% vital. Three-quarters of it is explaining exactly how each in-file works in excruciating detail. I do want to include some useful info on LLSSS in there, though, so I may take your State of the Union post and create a little collapsible box with it and put it in the guide (plus diagrams!)
I had, but there's really not much for me to say. I retain my commitment to my value that others may do whatever they wish with their own time and sanity, but I would be lying if I said I was not rattled by nearly every facet of how this person has chosen to spend theirs. It seems especially distasteful and confusing to rip off the binary name, subcommand name, and half the user interface structure from LLSSS for what seems like it should be a distinct search program with its own distinct identity. That I must endure this is no doubt my karmic balance for naming LLSSS after LSSS come due and I hope somewhere out there Andrew J. Wade (LSSS's author) is getting a chuckle out of this.
I do wonder how it is so much faster, although there are many possible explanations so it's less a mystery that it is and more a mystery of which of the reasons matter and in what proportion. Nonetheless, I will probably not be digging into it. LLSSS has never been and probably never will be the fastest search program for any measure and my plate/roadmap is pretty full anyway.
amling wrote: October 5th, 2026, 2:47 pm
I had, but there's really not much for me to say. I retain my commitment to my value that others may do whatever they wish with their own time and sanity, but I would be lying if I said I was not rattled by nearly every facet of how this person has chosen to spend theirs. It seems especially distasteful and confusing to rip off the binary name, subcommand name, and half the user interface structure from LLSSS for what seems like it should be a distinct search program with its own distinct identity. That I must endure this is no doubt my karmic balance for naming LLSSS after LSSS come due and I hope somewhere out there Andrew J. Wade (LSSS's author) is getting a chuckle out of this.
I suppose I can reach out to gchromodynamics and ask if he could change the command names. It would be a bit of a hassle, but if it's important it should probably be done as soon as possible so the names don't propagate further.
amling wrote: October 5th, 2026, 2:47 pm
I do wonder how it is so much faster, although there are many possible explanations so it's less a mystery that it is and more a mystery of which of the reasons matter and in what proportion. Nonetheless, I will probably not be digging into it. LLSSS has never been and probably never will be the fastest search program for any measure and my plate/roadmap is pretty full anyway.
I believe most of the speed increase comes from it being written in C. The memory reductions might be useful, I will ask him how they work and get back to you if the major ones are related to LLSSS's functionality in some way (as opposed to being totally different).
Last edited by LuveelVoom on October 5th, 2026, 3:06 pm, edited 1 time in total.
LuveelVoom wrote: October 5th, 2026, 2:20 pm
I had an idea for avoiding repeating components. Couldn't you store W-rows of the spaceship in lookup tables...
I feel like I need to write a persistent page I can just link to, "it looks like you're trying to dictate LLSSS implementation details without understand the data model". As I just tried to explain to someone else, there are no reified partials. Implicit in that, there are no W rows. There are strips of columns, and that's it. For typical fixed board searches at meaningful sizes, the number of distinct recombinations of these strips into reified partials (and relatedly number of distinct W rows or W-overlap-sized-blocks-of-W-rows or whatever other aspect you want to try) is absolutely astronomical. For recentering it is possible to have cycles (and even non-background-agar cycles) and thus represent infinitely many (distinct) reified partials.
LuveelVoom wrote: October 5th, 2026, 2:20 pm
I had an idea for avoiding repeating components. Couldn't you store W-rows of the spaceship in lookup tables...
I feel like I need to write a persistent page I can just link to, "it looks like you're trying to dictate LLSSS implementation details without understand the data model". As I just tried to explain to someone else, there are no reified partials. Implicit in that, there are no W rows. There are strips of columns, and that's it. For typical fixed board searches at meaningful sizes, the number of distinct recombinations of these strips into reified partials (and relatedly number of distinct W rows or W-overlap-sized-blocks-of-W-rows or whatever other aspect you want to try) is absolutely astronomical. For recentering it is possible to have cycles (and even non-background-agar cycles) and thus represent infinitely many (distinct) reified partials.
Hmm hmm hmm I appear to already have lost most of my knowledge on the inner workings of LLSSS . I will have to go back to my notes and see if there is some sort of viable way to do this or if all hope for a clean solution is lost (which given how many times people have asked you this is very possible). (W-rows wasn't the right terminology here and I knew that, I had forgotten the proper term)
Sorry for wasting some of your time the past week or so...
LuveelVoom wrote: October 5th, 2026, 2:55 pm
I suppose I can reach out to gchromodynamics and ask if he could change the command names. It would be a bit of a hassle, but if it's important it should probably be done as soon as possible so the names don't propagate further.
I feel like much of that ship has sailed. At least we got a semblance of distinct identity / repo name ("LLSSS-ng").
LuveelVoom wrote: October 5th, 2026, 2:55 pm
I believe most of the speed increase comes from it being written in C.
It is a distinct possibility, but LLVM is an unstoppable killing machine and rust's design is very picky about ownership, allowing it to pass to LLVM a great deal of information that analogous C cannot, likely setting it up for success. The last time I was looking at disassembly under `perf` output I was absolutely lost in the SIMD maze of assembly it had made of the code. While this perhaps says more about me (many years out of practice reading assembly) it is at least a little evidence that LLVM (via rust) is as good as I hope/think it is.
LuveelVoom wrote: October 5th, 2026, 2:55 pm
The memory reductions might be useful, I will ask him how they work and get back to you if they're related to LLSSS's functionality in some way (as opposed to being totally different).
I sort of think I already know the answer about what LLSSS-ng does: The documentation says to me the memory format is succinct bit trees for bcols (and I think no jcols). MDSE V2 (BitTree) is LLSSS's own succinct tree implementation (I have described it elsewhere when I wrote it, but I did not know its name) and the currently-still-hypothetical MDSE V3 is my plan to try removing jcols and doing the CA checks they enforce on the fly. The question I am less sure of is: does it matter for perf? MDSE V2 (succinct trees) is materially slower than MDSE V1 (original/default index-based format) and I assume MDSE V3 will be even slower than MDSE V2. Maybe the (hopefully vast) reduction in memory bandwidth use will somehow win out?
amling wrote: October 5th, 2026, 3:12 pm
I feel like much of that ship has sailed. At least we got a semblance of distinct identity / repo name ("LLSSS-ng").
I have been calling it L2S3ng, initially out of convenience but recently to quickly distinguish it from LLSSS. Perhaps that is a viable name, and the very beginning of the command prompt (./rlife llsss) can be changed to reflect that.
amling wrote: October 5th, 2026, 3:12 pm
I sort of think I already know the answer about what LLSSS-ng does: The documentation says to me the memory format is succinct bit trees for bcols (and I think no jcols). MDSE V2 (BitTree) is LLSSS's own succinct tree implementation (I have described it elsewhere when I wrote it, but I did not know its name) and the currently-still-hypothetical MDSE V3 is my plan to try removing jcols and doing the CA checks they enforce on the fly. The question I am less sure of is: does it matter for perf? MDSE V2 (succinct trees) is materially slower than MDSE V1 (original/default index-based format) and I assume MDSE V3 will be even slower than MDSE V2. Maybe the (hopefully vast) reduction in memory bandwidth use will somehow win out?
Memory saving (and apparently vast memory saving!) at the cost of time sounds great to me
Probably shouldn't be filling this thread with low info messages, should I...
Anyway, partial cutter is basically complete in terms of functionality. Now I just have to make the guide... not suck. I'm kind of worried, since I already made a comprehension error just a few messages ago... (20 questions was a bit of hyperbole. The actual number will probably be 5-10.)
LuveelVoom wrote: October 5th, 2026, 3:23 pm
(about LLSSS-ng)
I have been calling it L2S3ng, initially out of convenience but recently to quickly distinguish it from LLSSS. Perhaps that is a viable name...
I definitely laughed when I read "L2S3" there. There was a brief moment in time near the beginning of LLSSS history where I considered replacing "LLSSS" with "L2S3" globally in its codebase. In the end I decided typing L2S3 was even worse than typing LLSSS and so I did not.
LuveelVoom wrote: October 5th, 2026, 2:20 pm
Couldn't you store W-rows of the spaceship in lookup tables...
...As I just tried to explain to someone else, there are no reified partials...
The list of people who have asked me more or less "can't you just do XXX with reified partials" is quite lengthy so I wouldn't sweat too hard being in their numbers. Perhaps more useful than me writing a negative "that's not how it works" page would be writing a positive "how it has to work" post for an existing algorithm, especially for one that has a simple naive "just do XXX with reified partials" equivalent in (my understanding of) gfind descendants. Maybe bg ends (I would simplify to zero agar)? It's simple and probably the most approachable, but maybe it's too simple. Maybe maxpop ends? It's an interesting condition to detect for sure. Maybe BCAF (again, simplify to zero agar)? It is also an interesting algorithm and the discussion might include an explanation of how it fails when independent good partials conspire to keep all bits of a bad partial in the memory, but that sort of feels like a rabbit hole. I will think on it...
Last edited by amling on October 5th, 2026, 7:23 pm, edited 1 time in total.
People often ask about LLSSS features with "can't you just do XXX with fully-reified partial boards?". The problem is that it doesn't work that way. LLSSS only has "vertical" (i.e. having fixed U value or extending parallel to the W axis, whichever way you want to think of it) strips of pattern in its state in memory and so these fully-reified partial boards simply do not exist. For meaningful fixed board searches their would-be number is astronomical and for recentering there are often infinitely many non-trivially-different boards due to "cycles" (horizontal repeats) possible in the strips. Whatever, I've written this paragraph several times in other posts, but I'll include it here as a reminder...
Instead, let's focus on how it has to work. The general case between fixed board and recentering is approximately that there is a graph of 2-wide strip vertices. Edges (in the graph sense) in this graph are CA-valid 3-wide strips. Some vertices (2-wide strips) are distinguished as "initial", i.e. contained in the left edge (edge as in CA board sense) and some are distinguished as "terminal", i.e. contained in the right edge (again, edge in the CA board sense). This graph fills memory (or it will by the end of any search project), so whatever you do, you can't use that much. Allocating memory proportional to the number of graph edges is mostly prohibitive, although occasionally algorithms suffer getting away with a small, fixed number of bits per graph edge. Allocating memory proportional to the number of graph vertices is probably acceptable, even probably allocating a few machine words per vertex to track some sort of state or weight. Allocating in virtually any other way is prohibitive. Don't even think about the space of all possible paths through the graph ("all fully-reified partial boards"). Probably don't think about doing any form of allocation that is dynamic per edge or dynamic per vertex, although "SSM filter ends" sort of gets away with it, at great performance cost, and most such ends use of this dynamic-ness is still very limited.
For fixed board you have the additional slight help that the vertices are sharded by U position, with all initial vertices in one (first) shard and all terminal vertices in another (last) shard. Fixed board ends take minor advantage of this for performance and minor advantage of this to represent in the logs the shape of necessarily-finite results. The only algorithm that I can think of that succeeds in taking real, qualitative advantage of this is fixed board autochoke.
I guess let's talk about zero ends first. It's sort of the simplest possible feature and yet it's going to be a bit complex to make it work. The human description, vastly oversimplified for zero background and ignoring the issue of only wanting "strict" ends that do not end in too many W rows of zeros, is that we want to find fully-reified partial boards whose entire last W overlap is all zeros. Rephrased in terms of the graph, this is all paths from initial vertices to terminal vertices, passing only through vertices whose 2-wide strips end in a W overlap of zeros. But how to do even this? I can't really motivate it any further, so let's just describe it:
(*) Construct a bit vector of a single bit for each vertex indicating if the vertex can be reached left-to-right (herein "l2r") from an initial vertex, passing only through vertices whose 2-wide strips end in a W overlap of zeros. We start by including all initial vertices that end in a W overlap of zeros and "closure l2r" where any time a reachable vertex has a right zero-ending vertex neighbor, we mark it in the bit vector (and possibly go on to check its right neighbors if this is an addition, etc.). This sort of closure operation is practically the only algorithmic building block available. You have some state per vertex (possibly as little as a bit or as much as a machine word), you have some notion of propagation across edges for it, and you do that, first seeding it somehow.
(*) Construct a bit vector of a single bit for each vertex indicating if the vertex can be reached right-to-left (herein "r2l") from a terminal vertex, passing only though vertices whose 2-wide strips end in a W overlap of zeros.
(*) Now if you intersect these two bit vectors you have the collection of 2-wide strips that are part of a result. If it's empty, you're done and there are no results. If it's non-empty, push on...
(*) At this point you have to figure out how you want to reconstitute the relevant 2-wide strips into actual results. In practice you're probably gonna assume the collection is small, fully reify the subgraph of these vertices, and revert to more normal graph algorithms to do whatever.
Contrast the giant mess of how this has to work with its simple implementation in (my understanding of) gfind descendants, namely "just look at the last W overlap of W rows and check if they're all zero".
For completeness, in reality I instead built "SSM filter ends" which handles a somewhat more general implementation for an ends that can be described via a "simple state machine", and agar ends (what zero/bg ends are backed by) operates by that.
As a second example, let's talk about the maxpop filter. Not interesting to us here is the mess of geometry that is trying to convert the collection of cells in a 1-wide strip into a count of how many are in the key generation. That part is "easy" and we'll take that as given (each 1-wide strip has a "weight"). Also take as given that there is some way to filter state, assuming you have a way to quickly adjudicate if a given vertex/edge should remain. Now again we find we have to perform a transformation from the naive "keep partials with bounded weight" to "keep edges/vertices that are part of a path of bounded weight" and figure out how to do that. Note that this isn't really equivalent, but it is a valid upper bound and gets rid of enough. It shakes out sort of similarly to zero ends:
(*) Find best-l2r-weight per vertex. This is the best (lowest) weight of any path, starting at an initial vertex, counted through the end of the vertex in question. For initial vertices this is initialized as the sum of the two weights of their two 1-wide strips and for other vertices it is initialized with a placeholder infinity value (2^64 - 1 or whatever). We closure across graph edges l2r by propagating infinity to itself and a non-infinite weight to itself plus the weight of the added 1-wide strip (i.e. the rightmost of the 3-wide strip). This closuring is a little more interesting, where when we update a vertex's value we take the minimum, and if the new value is lower than the old we need to continue on rightward of the vertex.
(*) Find best-r2l-weight per vertex. This is the best (lowest) weight of any path, starting at a terminal vertex, counted to the end of the vertex in question (notably not including either of the two 1-wide strips in the vertex!). For terminal vertices this is initialized as zero and for other vertices it is initialized with infinity. We closure across graph edges r2l by propagating infinity to itself and a non-infinite weight to itself plus the weight of the added 1-wide strip (i.e. the rightmost of the 3-wide strip, again).
(*) Now the best weight for any path for a vertex is easy: it's the sum of the best-l2r-weight and the best-r2l-weight. The best path weight for an edge is also pretty easy: it's the best-l2r-weight of the left vertex plus the best-r2l-weight of the right vertex plus the weight of the rightmost 1-wide strip (which was included in neither). As we can easily adjudicate best path weight for an edge/vertex, we can also easily adjudicate whether or not we should keep them which is what we need for filtering.
(*) Similar to ends, actual state filtering details are left to individual modes (fixed/recentering) and in fact a lot of how filters work altogether might be about to change, but I think this much of this version is still illustrative.
Finally, let's talk about WCAF/BCAF/ACAF. The very simplified version of this is keeping "only partials that do not start with too many zero W rows (herein 'interesting')". In order to define semantics for the graph state, we'll change it to: "keep edges/vertices that are included in some partial that contains an interesting vertex".
Note that this time it is deeply, deeply inequivalent! You could have "interesting" partials that do not themselves, individually, globally start with too many zero rows that force us to keep their strips, but then those strips can be recombined in a way to allow (to still exist) an "uninteresting" partial whose entirety does start with too many zero rows. In practice for fixed board this has been mostly livable where real searches usually eventually stop keeping too much crud, but from-zeros recentering searches run with BCAF unavoidably output an all-zeros "Thinnest" partial forever as the zero vertex and edge are always kept.
As for the algorithm, we will reword "is included in a partial that includes an interesting vertex" to the equivalent "has any path, in either direction, to an interesting vertex". Equivalence of the two is maybe not super obvious and relies on the search state's (CA-board-)edge-reachability invariant, where any vertex has a path left to an initial vertex and right to a terminal vertex and so any path to an interesting vertex can be extended on both sides to be part of some partial. This can be implemented as...
(*) Construct a bit vector of a single bit for each vertex, indicating if the vertex can reach, to the left, an interesting vertex. This is initialized with just the interesting vertices themselves and is closured l2r (i.e. if the left vertex of a graph edge can reach, to its left, an interesting vertex, so too can the right vertex of that graph edge).
(*) Construct a bit vector of a single bit for each vertex, indicating if the vertex can reach, to the right, an interesting vertex.
(*) Keep vertices iff they are in one (or both) of the two bit vectors. Keep edges iff the left vertex can reach an interesting vertex to its left or the right vertex can reach an interesting vertex to its right.
Again, this shakes out slightly differently in code where filters specify a notion of interesting-ness and then modes (fixed/recentering) have to implement filter-for-interesting-ness, although the recentering implementation of this is the one I just gave. Also, it's likely all about to change as I have some big ideas for reforming filters.
To summarize, and this is the entire point of this post: remember that any time you want to say "just do XXX with fully-reified partial boards", you have to translate it into some graph equivalent if you want it done in LLSSS.
LuveelVoom wrote: October 1st, 2026, 9:31 pm
Edit: While I was paying attention to something else, Claude decided to COMPILE THE ENTIRETY OF LLSSS ON A MACHINE WITH ONE CORE AND 3GB OF RAM FOR ONE BUGFIX.
There's a very unhappy CPU somewhere deep in a datacenter.
Needless to say, it did not go well.
Screenshot 2026-10-06 at 11.25.54 PM.png (39.54 KiB) Viewed 178 times
Um. What?
Development will be slowing down because I've used 90% of the week's token allocation and there's still 3 days left in the week. This is a family account so I probably shouldn't be wasting this much energy... I will be writing up the guide while I wait for the reset, though, so hopefully progress will pick up quickly after that.
LuveelVoom wrote: October 7th, 2026, 2:26 am
Um. What?
The context of the screenshot isn't clear to me. Can you please explain what's going on here in a bit more detail?
I've been in a long conversation with an AI model (claude, in this case) developing a webtool to make it easier to construct input files for LLSSS. At some point earlier, it made an attempt to compile LLSSS on its sandbox, a 1 core machine with 3 gigs of ram, which failed. Somewhere between then and now, it successfully compiled rlife (and with it LLSSS) on the sandbox.
Let me remind you that the tutorial recommends 16 gigabytes of ram for compiling rlife.
I've sketched a major overhaul of how filters work. For typical/simple uses it would be undetectable, but for finicky use of multiple filters or DL steps there may be changes coming. Lengthy details below...
For old, old, incredibly old reasons, filters were first written as "steps", i.e. entirely pluggable bits of code that run on the general form of the search state. "Expand" is a step that extends the search state one bit, "partials" are steps that don't change the state, but might print something, etc. It was simplest to code the original filters as their own distinct steps that ran after expand and reduced the state, after the fact. "Constraints" are part of the expansion step and prevent generation of certain cell possibilities during it. This is better because it avoids the expense of reifying that data, results in a smaller state going into pre-reify-autochoke, etc.
The sketch reworks filters to operate at pre-reify time instead. It does mean that during expansion the data is still generated in the pre-reify format (compared to constraints where it's eliminated even earlier), but then it gets pruned out before pre-reify-autochoke (pre-reify-autochoke is entered as the last pre-reify action).
This is theoretically capable of reducing memory usage right after reify, but did not change VmPeak in any of my benchmarking as the memory peaks were always elsewhere. In some testing, fixed board B2/S c4-f2b BCAF searches saw time improvements in the range of 20% which is a pretty big deal. I think a lot of this difference is being able to skip the entire expensive filter cols step, even if doing the ACAF computations on the pre-reify data is a little worse than the post-reify version. In other testing, rc WAO p3 statorless maxpop searches were maybe in the range of 3-5% slower, presumably due to similar issues making pre-reify computations more expensive but this time not saving as much on the other side filtering. I think it's all still worth doing.
This change gets rid of a lot of difficult and ugly code to filter/mutate state as now the only step that mutates the search state in any way is expansion and it does it in a very appendy sort of way. Extra not relevant to users perhaps, but it's a huge benefit for the codebase, especially in its reduction of the complexity of the MDSE abstraction.
Aside from the possible time savings for typical BCAF searches, the most likely user benefit for this is that it unlocks the possibility of "final partials". Previously I had dragged my feet on somehow avoiding the expense of default/random partials during the entire search as the existence of filter steps makes producing a last partial messier. The main problem was that searches could end either when expand emptied the state or when filters emptied the state and it wasn't clear what to do in the latter case. You probably want to see last partials from the state as it was before the expansion before the fatal filter, but that state is gone by the time we realize it. Now the only state-emptying end condition is expansion, and it's very easy for expansion to realize at the moment of reification that it's about to wipe the state and instead just halt the search. Then we can add a notion of final steps to run on halt. Arguably it could run any sort of step, but the most likely choice for such are like the current partials, but maybe defaulting to RLE (the same way the current last partial hacks do).
I think the main questions are likely...
(*) Do these final steps run on all halts or just some? Probably I will want to rethink the ontology of halt reasons, but mainly I wonder if we should run final steps or not for DL steps flagging halt and for --halts (which is right now just "w_pos"). I guess my assumption is that we should run them for anything that isn't more or less a crash and I think I can make the halt reason ontology make that clear.
(*) What exactly do we want available and what are the defaults? I would lean toward just reimplementing what we have right now, i.e. the default (and only choice for now) is "default" which gets you the same partial as "--pre-partials default", but in RLE and with a slightly different banner message. The difference being now you'll be able to add "--pre-partials none" and silence the per-round partials without losing the final partial that is currently hacked into them.
(*) What do we do if a final step flags a halt? We'd have two halt flags to combine. I think that (and the current sketch includes that) we could limit final steps to be unable to change state or flag halts and then we don't have to answer this. It might somewhat limit the future possibilities for weird final steps, but I can't think of any real applications.
As a final note, moving filters to pre-reify changes the way the DL integration has to work. In particular previously you could use "gate" (formerly "gate_step") on a filter since it was just another step, but now that's broken. In the longer term I have other plans for reworking the DL integration that will make fixing this easy (so you'll be able to gate pre-reify actions as well), but for now it's gonna be left broken. Probably more on this DL rework later.
I will think on it some more but my current inclination is to ship it as written and pick up the DL pieces later. Anyone needing to gate filters would be free to not pick up the changes and I am reasonably committed to recovering such later. I will almost certainly follow up with some --final-partials examples if/when I ship.
. I will have to go back to my notes and see if there is some sort of viable way to do this or if all hope for a clean solution is lost (which given how many times people have asked you this is very possible). (W-rows wasn't the right terminology here and I knew that, I had forgotten the proper term)
