For a macro-spaceship that is its own glider synthesis I'd like to know what initial collision between two 90-degree gliders can most quickly be converted into a clean elbow block (or SPEBOE, I suppose -- Standard Pi-Explodable Block or Equivalent, for anyone who's getting a little rusty on that questionable bit of terminology).

It looks like all the available 90-degree collisions aren't quite lucky enough to make an elbow object in the right place directly. Did I miss a good one somewhere?

I eventually found a traffic-light-making collision that allows a crystal to form --

chris_c wrote:There was a solution lurking in the second code-box of this post:...The second glider comes 90 ticks after the first. Is that acceptable or does the first glider need to be a singleton?

As far as I can see there's no reason to require a singleton. The all-gliders recipe will consist of two diploid chromosomes -- two exact copies of two slightly different recipes. Any stream of gliders that can be duplicated by a memory loop is fair game. Thanks!

When we get to the all-gliders stage, the first copy of the recipe will already be partly used up: the first N gliders in the recipe hit a receding Cordership. Their job is to clean up all the debris and produce that Acceptable Glider, by building a 180-degree one-time turner off to the side if necessary. (Or straight back along the channel -- see below.)

I think it should be fairly easy to extract an elbow block from a crashed Cordership, using the same single-channel lane for every glider. Then we can pull that elbow back and use 0-degree gliders from there to do the cleanup and eventually build the Acceptable Glider.

OptionsI guess it would work to have either a 180-degree one-time turner triggered by a 90-degree glider that uses up a standard elbow, or a 90-degree one-time turner triggered by a 0-degree glider that uses up the 0-degree elbow. Just have to make sure the next three single-channel gliders can get there in time to meet the Acceptable Glider.

Of course that part is all a very arbitrary song-and-dance to make it so there are nothing but gliders in the spaceship at some point. Otherwise it would be much simpler to just make the Cordership debris into an elbow, and restart the construction cycle from there.

-- Come to think of it, a recipe that converts an elbow into a clean 180-degree one-time turner would also work, if the turner sends back a glider on the lane shown here. That seems likely to be the cheapest option -- no need to build anything complicated off to the side.

I can easily compile a working Cordership-to-180-degree-turner conversion recipe manually, using 0-degree gliders. But a direct conversion is bound to be cheaper. Might something like that be within reach of a one-off search with an existing search script?

However, there's another use case where you don't really want the elbow duplicated, you just want it moved quickly. For that I'd need a destructive recipe for a return glider on a lane 3hd from the single-channel lane.

Is there any chance of a destructive 3hd return glider recipe showing up magically when I wish for it, or is it time for me to go see if I can get some search code working again? At this point I only have embarrassingly vague memories of what's available in this department. I can fake a solution by appending a 0-degree recipe on a near-zero lane, but that seems unnecessarily expensive.

(Really the 3hd offset isn't a requirement. It could be any offset that can be cheaply hit with another single-channel glider and cheaply converted back into a clean elbow. Most likely 46 gliders is painfully suboptimal already.)

dvgrn wrote:...However, there's another use case where you don't really want the elbow duplicated, you just want it moved quickly. For that I'd need a destructive recipe for a return glider on a lane 3hd from the single-channel lane....(Really the 3hd offset isn't a requirement. It could be any offset that can be cheaply hit with another single-channel glider and cheaply converted back into a clean elbow. Most likely 46 gliders is painfully suboptimal already.)

Looks good! Thank you for granting another wish. Is there some kind of quota, or do I just have to make the wishes sound interesting enough?

The code for optimizing these recipes seems to have succumbed to bit-rot to some extent -- I can no longer quite locate a working script where I can feed in the form of single-channel recipe that you quoted, and get an optimized recipe out. Luckily it seems I have enough half-working scripts lying around to get a result fairly quickly.

So now we have a decent way to move elbow blocks back toward the single-channel source, much more quickly and with fewer gliders than would be possible with regular incremental block-pull elbow ops.

Here's a mirror-image contribution: we can also move elbow blocks relatively quickly away from the single-channel source, quite a bit faster than incremental block pushes can do it. It only makes sense for very long distances. The recipe is 2745 gliders, a bit more expensive than the current 2423-glider Snarkmaker recipe. 2-engine Corderships are pretty cheap to make, as these things go.

The latest slsparse is clever enough to compile a slow-salvo recipe for a 2-engine Cordership seed, that fits nicely inside the current known range of 0-degree recipes:

Here's the infile.mc I ended up using to find the recipe. You can't actually trigger the seed with the limiting still lifes in place, but the Cordership can fly between those walls once it has been created.

Any still life with 32 bits or more is treated as an obstacle by slsparse. None of the slow salvo gliders or construction reactions can be allowed to damage the those walls. Luckily slsparse has a lot of recipes to choose from, so apparently it didn't have any problem finding a solution with those constraints.

slsparse also already knows about using multiple elbows -- i.e., duplicating an elbow, using the closer one for a while, then destroying it and going back to the more distant elbow. And it can do long-distance hand pushes by building and shooting down a Cordership... a 3-engine Cordership. But up to know it hasn't been taught the same trick for pushing along the construction arm. Things might get a bit more efficient with these new recipes available.

simeks wrote:No problem! I don't mind running a search like that every now and then. As long as it doesn't mean too much modification to existing software...

If after this long of a gap you can still get your existing software to work correctly, you're doing better than I am. I'd probably best stop posting all my miscellaneous self-construction utility scripts here and there on forum threads, and start getting them properly checked in to GitHub somewhere instead.

Anyway, I'm glad you said that, because I do have one other wish-list item open at the moment... it would be nice to have a slow-salvo recipe for the other parity of HWSS.

I went ahead and made one by brute force, but it's 182 gliders where the known HWSS parity is only 35 gliders. So the toolkit is complete now, but it seems just a little bit unbalanced:

EDIT: Also, quick question: the current 0-degree toolkit is complete up to +/-59, I think, but there are strange and magical things that can be accomplished with a width around +/-80 or maybe +/-90, maybe even if the wider range toolkit isn't complete. How close to the edge of searchability are those wider 0-degree recipes?

EDIT: Also, quick question: the current 0-degree toolkit is complete up to +/-59, I think, but there are strange and magical things that can be accomplished with a width around +/-80 or maybe +/-90, maybe even if the wider range toolkit isn't complete. How close to the edge of searchability are those wider 0-degree recipes?

The way I remember it was getting really difficult right around +/-60 lanes, but I'll take a look to make sure!

Wonderful -- thank you! Both parities are now cheaper than the old 35-glider recipe -- 30 and 29 gliders for the first two I tried, but I'd better double-check the recipes and make sure I haven't missed cheaper ones:

I'll run the optimizer script on these at some point, and try to get all the known recipes into some kind of single-channel builder script.

... Now I'm hoping someone will be unable to resist writing a *WSS slow salvo search program, since otherwise I'll have to do it myself eventually. Having six different projectiles to aim at the target at each stage should make for a search tree with an impressive branching factor.

I've probably mentioned before that one possible candidate for a new smallest self-constructing spaceship would be a version of Scorbie's Demonoid that does both construction and destruction via *WSS collisions -- no need for a temporary elbow Snark. There are also a lot of other interesting cases where it would be handy to be able to use an orthogonal upper construction arm instead of a diagonal one.

dvgrn wrote:EDIT: Also, quick question: the current 0-degree toolkit is complete up to +/-59, I think, but there are strange and magical things that can be accomplished with a width around +/-80 or maybe +/-90, maybe even if the wider range toolkit isn't complete. How close to the edge of searchability are those wider 0-degree recipes?

The way I remember it was getting really difficult right around +/-60 lanes, but I'll take a look to make sure!

Appearently I didn't put much time into those searches... It seems possible to extend the toolkit well beyond +/- 80 lanes! I sampled some lanes (I need to search each wide 0-degree lane seperately with my existing code). 71, 75 and 79 lanes works just fine. I'll run searches from 61 lanes and upwards and post results for as wide as my current code can find them in reasonable time.

simeks wrote:Appearently I didn't put much time into those searches... It seems possible to extend the toolkit well beyond +/- 80 lanes! I sampled some lanes (I need to search each wide 0-degree lane seperately with my existing code). 71, 75 and 79 lanes works just fine.

Interesting!

In case it wasn't clear, the "strange and magical things" include a 0-degree Scorbie-Splitter-maker recipe -- another very useful thing to build directly on the construction lane.

Technically we can do this already, and in fact as of two days ago, slsparse can even build such things automatically. It would now compile an inline Scorbie Splitter by building two Snarkmakers in succession, building the splitter circuitry from a short distance to one side, and then sending two Snarkbreakers. Remove the elbow after that, and the splitter is ready to go.

Two temporary Snarks is pretty expensive, though. I think a 0-degree version of the Splittermaker will end up being quite a bit shorter.

dvgrn wrote:...EDIT:[/b] Also, quick question: the current 0-degree toolkit is complete up to +/-59, I think, but there are strange and magical things that can be accomplished with a width around +/-80 or maybe +/-90, maybe even if the wider range toolkit isn't complete. How close to the edge of searchability are those wider 0-degree recipes?

Lanes 95 to 99 and still no real limit in sight... How wide do we need to comfortably build the Scorbie-Splitter?

simeks wrote:Lanes 95 to 99 and still no real limit in sight... How wide do we need to comfortably build the Scorbie-Splitter?

Looks like your search code is finding natural versions of what I'd do if I had to build these zero-degree recipes manually: trigger an edge-shooting Herschel explosion in the right place, then shoot gliders sideways to clean up the extra debris far off to the side, then do a conventional search to reduce the remaining ash back to a Standard Pi-Explodable Block or Equivalent.

I asked for "a width around +/-80 or maybe +/-90", and one of slsparse's features is an way to specify narrow construction recipes. So +/-99 should be perfectly comfortable.

...I suppose if you can make it up to +/-120 or so, that might allow for a self-destruct-seeded Scorbie Splitter along the lines of the one in the loopship. But that will be a solution in search of a problem, at least for the moment.

What code are you running to do these searches again? Last time I asked, it turned out I wasn't ambitious enough to attempt to hack together a custom search for recipes like the Snarkmaker. Now we're getting more of these recipes, like the "Cordermaker" for a 2-engine Cordership directly on the construction-arm lane, to do efficient elbow pushes for very long distances.

The Snarkmaker and Cordermaker could both be reduced to about half their current weight in gliders, by starting each new search for the next 0-degree glider using the last glider-producing ash cloud as a target, rather than working all the way back to a SPEBOE every time.

It's kind of a scary thought that the same is true for regular 90-degree constructions. Pretty much all single-channel constructions to date use about twice as many gliders as they probably really need. Optimizing them would be a long search, different for each recipe, but each search would only have to be done once.

dvgrn wrote:Looks like your search code is finding natural versions of what I'd do if I had to build these zero-degree recipes manually: trigger an edge-shooting Herschel explosion in the right place, then shoot gliders sideways to clean up the extra debris far off to the side, then do a conventional search to reduce the remaining ash back to a Standard Pi-Explodable Block or Equivalent.

A bit simplified the search goes like this:- Say after having shot 20 gliders at the initial elbow, we have collected a pool of the most promising results from that.- Each pattern in the pool has settled to a stable P2 pattern, possibly with one escaping glider on the particular 0-degree lane we're currenctly looking for.- In the new 0-degree searches I use a pool size of 100000 patterns.- Then we try shooting a new salvo at the stable P2 pattern of either a single glider of one the two possible phases, or a pair of gliders. The first glider in a pair could also have either of two phases, and the second has a distance from the first of 90 to 173 ticks.- Each salvo that creates a new settled pattern is inserted into a new pool for patterns of either 21 or 22 gliders.- Next the pool of patterns from 21 gliders is considered. It will contains patterns from shooting one glider at a pattern from the 20 glider pool, or two gliders from the 19 glider pool.- The pool for patterns from 21 gliders will likely have about 10 times more patterns than the 20 glider pool.- Searching increasingly wide for each added salvo hasn't proved very useful in finding results in a reasonable time. It's much more efficient to limit the search width to a fixed number, and add more salvos instead.- So to keep the search width constant we pick the 100000 most promising results in the 21 glider pool, and throw away the rest.- To pick the most promising ones, we use a cost function. The cost is based mostly on the bounding box of the stable pattern.- Patterns that have already produced an escaping glider on the correct lane get a huge bonus in the cost function.- Once a few patterns have been found that produce the correct glider, patterns descending from those will quickly start to dominate the pools because of the cost function advantage given to them.- This divides the searches into two slightly overlapping phases. First find patterns that produce the correct output glider. Then reduce the residues back to an elbow again.

dvgrn wrote:I asked for "a width around +/-80 or maybe +/-90", and one of slsparse's features is an way to specify narrow construction recipes. So +/-99 should be perfectly comfortable.

The new search has results for all lanes from 48 to 108. I have posted the raw results here. I've also includes the new XWSS searches in a separate file.

dvgrn wrote:What code are you running to do these searches again?

Because you asked for it back then, I mailed the code to you on Sep 24, 2017. I have only made minor changes for the new searches. It uses my GoLGrid library, which is written in C in a way that allows gcc to compile the pattern evolve function into very fast 256 bit SIMD code.

Later patterns in the same file seemed to be doing something similar. I haven't yet tried interpreting your timing-number lists to see if they actually match the RLE, or if there's something going wrong in the translation there.

dvgrn wrote:...But when I checked 108b.txt, the glider showed up all right, but every RLE I tried gave a messy explosion instead of a cleanup....

Strange, seems to be some subtle bug, and not strange that it affects all solutions in the 108b.txt file, because all solutions are identical up until glider 34.Good news is, I checked the first solution of each of the other 80 files, and no similar problems in them. I found a few minor issues that are easy to deal with:

58b.txt: Add some delay after glider 1959b.txt: The file suffered a transfer error, and the first 4 kbytes of the file contains zero-bytes, but that part is before the first solution83b.txt: Add some delay after glider 7

I will try to figure out what went wrong with 108b.txt, even if we could probably do without that lane.

EDIT: Ok, could trace the bug to a rare situation where the second glider in the salvo is added to the evolving pattern too late, so that it should already have reacted with the pattern. It would be easy to work around this to get a valid lane 108 result.

EDIT 2: In the exploding pattern above, go to generation 5172, remove these three cells, and it "works":

simeks wrote:EDIT: Ok, could trace the bug to a rare situation where the second glider in the salvo is added to the evolving pattern too late, so that it should already have reacted with the pattern. It would be easy to work around this to get a valid lane 108 result.

Sounds good! I'm glad there weren't problems hiding in more places.

I just looked at the loopship design again with 0-degree construction in mind. It's pretty badly lopsided, extending to 150hd or so on the inside of the loop, thanks to some one-time turners and splitters that were added there.

I think it should be easy to redesign the one-time circuitry so everything fits somewhere inside 110hd, or 120hd anyway. So it's possible that the "compile with obstacles" feature in slsparse might give us a 0-degree recipe that doesn't need anything wider than lane 107 or 108.

Still, if you have some spare CPU cycles and the search is still giving results, it seems like this is a possible use case for continuing the search until it actually becomes difficult to find results. A 0-degree recipe for that part of the loopship would save two Snarkmakers, which is a pretty good chunk of the entire loopship recipe.

-- I guess if the widest 0-degree recipes are up around 75 gliders, that will counteract some of the Snarkmaker savings, but I think we'd still come out a good bit ahead.

dvgrn wrote:I asked for "a width around +/-80 or maybe +/-90", and one of slsparse's features is an way to specify narrow construction recipes. So +/-99 should be perfectly comfortable.

The new search has results for all lanes from 48 to 108. I have posted the raw results here.

Thank you! I've postprocessed those results with Dave's script and combined them with the earlier results to obtain pp0deg.txt. Now, slsparse is able to construct narrow metaclusters directly on the construction lane using those 0-degree construction recipes; this is somewhat more efficient than the fallback approach of using two Snarkmakers and Snarkbreakers.

What do you do with ill crystallographers? Take them to the mono-clinic!

It looks like the next easy construction might be a giraffeship, flamingoship, zebraship, or antelopeship. With the simplest design I can think of, the only new single-channel recipes that will be needed are specialty elbow moves -- the block ends up not in SPEBOE position but on a nearby lane, 1hd through 6hd away from a "correct" elbow location.

This is just so a construction arm's elbow can be moved at the last minute to a place where a reconstructed UC with an offset of (4,1) or (6,1) or (3,2) or (4,3) can pick it up and start constructing again.

What I should probably do is try to put together a simplified version of the schan program, where the input is a pattern plus a desired target, and the search stops as soon as it has found the target. That would allow for an alternate knightship/cameship/giraffeship/etc. design where it's necessary to move a Snark by a short offset, instead of just an elbow block.

I suspect that in a lot of cases, a single-channel salvo aimed at a Snark at a 1/2/3/4/5/6hd offset from the correct input channel will turn out to be able to clean it up into an elbow block, after which we can adjust the elbow location and send a fresh Snarkmaker.

In some cases the gliders will drill through too quickly or make an early output glider or something, so in those cases it would be necessary to add extra bait still lifes to stop that from happening, and build a new custom Snarkmaker that also constructs those bait still lifes.

-- Which sounds a bit painful, and that's exactly why I'm going with a design where only elbow blocks need to be moved...

dvgrn wrote:I suspect that in a lot of cases, a single-channel salvo aimed at a Snark at a 1/2/3/4/5/6hd offset from the correct input channel will turn out to be able to clean it up into an elbow block, after which we can adjust the elbow location and send a fresh Snarkmaker.

In some cases the gliders will drill through too quickly or make an early output glider or something, so in those cases it would be necessary to add extra bait still lifes to stop that from happening, and build a new custom Snarkmaker that also constructs those bait still lifes.

In the cases where the single channel gliders burn straight through the target I think that the cheapest way of enlarging the search space is to perturb the target with a 0-degree glider at the beginning. Hopefully this gives enough options so the search doesn't immediately reach a dead-end.

In the past I have done searches along these lines. See here for example. I can't remember how I did these searches though. Probably a hacked version of my old python elbow searching code.

chris_c wrote:In the cases where the single channel gliders burn straight through the target I think that the cheapest way of enlarging the search space is to perturb the target with a 0-degree glider at the beginning. Hopefully this gives enough options so the search doesn't immediately reach a dead-end.

That will maybe kind of work, but only if there's an elbow block available on the near side of the Snark.

In the case I'm looking at, it would be better to just finish using the Snark, leave it in position, and in the next cycle allow the 1hd (or whatever other offset) single-channel glider stream start hitting the Snark to convert it directly into a new offset Snark.

Don't Want A Snarkbreaker...The obvious alternative is a Snarkbreaker followed by the appropriate block moves, followed by an offset Snarkmaker. It's easy to compile a Snarkmaker at whatever offset to the current glider channel might be wanted. But when the Snark is a long way away from everything else, having to start out with a Snarkbreaker increases the length of the recipe significantly.

... But We Could Add An Offset ElbowAnother interesting option is a very easy addition to the Snarkmaker, using extra 0-degree gliders right at the end of the current Snarkmaker recipe. These would construct a new elbow at the appropriate offset from the current construction lane, out of the way of all the Cycle N single-channel gliders but ready to be used as soon as the offset Cycle N+1 gliders start showing up.

-- Or for small offsets like 1hd, 0-degree construct any constellation that will turn itself into an elbow when it's hit by a single glider coming in on the new construction lane, but again just out of the way of the current construction lane.

Clean Up With 0-Degree Gliders, Not SnarkbreakerThat's actually a fairly adequate workaround for the giraffeship/flamingoship problem, even without any Snark cleanup searches. As soon as a zero-degree elbow is available anywhere sourceward of the Snark, the Snark cleanup can be done with 0-degree gliders just as easily as the reconstruction (with a standard Snarkmaker).

So each recipe's first task will be to build the new Snark. The second task is to move the 0-degree elbow sideways to the next elbow position. After that all the single-channel gliders for the rest of the whatevership construction will follow, flying harmlessly past the future elbow location.

Déjà vuNo doubt we figured most or all of this out perfectly well when putting together the true (2,1) knightship blueprint, but that was a couple of years ago and I'm not so good at remembering all the details after that long. And now that Sir Robin has showed up, a knightship doesn't seem as interesting as the more exotic part of the hypothetical menagerie.

In the past I have done searches along these lines. See here for example. I can't remember how I did these searches though. Probably a hacked version of my old python elbow searching code.

If any such hacked version turns up, I'd be interested in taking a look at it to see if I can feed any of these problems into it. Mostly the interesting trick will be to feed in an arbitrary ash pattern, and find the shortest way to release a specific glider and then reduce the ash to an elbow block. Then you start a new custom search from the ash cloud at the point where that new glider was released -- and sooner or later you have a Snarkmaker, Cordermaker, or pretty much any existing self-construction recipe, at roughly half the current cost.

I should really buckle down and adapt simeks' fast 'schan' code for this kind of search, but that looks like it might involve thinking.

dvgrn wrote:That will maybe kind of work, but only if there's an elbow block available on the near side of the Snark.

I presume that you have some kind of UC that sends gliders to this Snark. Also I am assume that the UC is destroyed by some meteor shower of gliders and then rebuilt. You could send a single glider at the Snark between the destroy and the rebuild phase. This logic would apply to any number of chained Snarks.

dvgrn wrote:-- Or for small offsets like 1hd, 0-degree construct any constellation that will turn itself into an elbow when it's hit by a single glider coming in on the new construction lane, but again just out of the way of the current construction lane.

I already did this here but I am very hazy about how. Note that it is not a single glider that turns the junk back into an elbow, but three of them.

dvgrn wrote:If any such hacked version turns up, I'd be interested in taking a look at it to see if I can feed any of these problems into it. Mostly the interesting trick will be to feed in an arbitrary ash pattern, and find the shortest way to release a specific glider and then reduce the ash to an elbow block. Then you start a new custom search from the ash cloud at the point where that new glider was released -- and sooner or later you have a Snarkmaker, Cordermaker, or pretty much any existing self-construction recipe, at roughly half the current cost.

I should really buckle down and adapt simeks' fast 'schan' code for this kind of search, but that looks like it might involve thinking.

Unfortunately the exact version is not going to turn up because of a very silly computer mishap some time ago. But... I am slowly starting to remember how I did those searches. The main work was to use the elbow searching code from the GoL-search repository here but somehow integrate the ObjCellList_parse_rle function from the slightly newer GoLGrid repository here. Then you can define your own starting elbow here. That is a fairly decent hint but I'm afraid that thinking will still be required...

EDIT: Integrate is probably the wrong term... more like I moved elbow.c over to the newer repo and then tried to fix any compile errors.

dvgrn wrote:With the simplest design I can think of, the only new single-channel recipes that will be needed are specialty elbow moves -- the block ends up not in SPEBOE position but on a nearby lane, 1hd through 6hd away from a "correct" elbow location.

I just posted some recipes for converting a Pi elbow into a block in the wrong lane here

dvgrn wrote:With the simplest design I can think of, the only new single-channel recipes that will be needed are specialty elbow moves -- the block ends up not in SPEBOE position but on a nearby lane, 1hd through 6hd away from a "correct" elbow location.

I just posted some recipes for converting a Pi elbow into a block in the wrong lane here

Thanks! That's just about the last piece left to string together a giraffeship, except for the cleanup. I'm tempted to use a meteor shower of gliders, since they'll be slightly cheaper than GoL-destroy additions in this case (I think).

What search program did you use to produce this cleanup recipe for the Orthogonoid? It doesn't look like that code ever showed up anywhere like simeksgol. (?)