Here’s a challenge for anyone who wants to work their way into building self-constructing circuitry, in small easy steps. This came up recently over in the ConwayLife Lounge.(invite link)

Imagine a pattern along the lines of the most recent spiral-growth pattern -- except that instead of building a simple Snark at each corner, it builds a glider splitter. One branch turns 90 degrees as before, but the other branch just continues straight, with a small lateral offset. An elbow is placed on both output lanes so that the construction can be repeated on both branches.*

… I post things like this every now and then, and usually nobody takes me up on the challenge, so then I have to do it myself.

Someone should please explain why this is. I’m intending this challenge in particular to be what Bill Gosper calls an “insurmountable opportunity”, seeing as it’s a good first step on the way to a completed honest-to-Golly quadratic-growth replicator.

* The elbow on the straight-ahead branch could possibly be set up to do a mirror-image construction. If both branches have the same chirality, you end up with a branching pattern that looks kind of like Langton's Loops replication. I haven't looked much at what would happen with other branching options, like two different chiralities, a T-shaped glider splitter, etc.

A simple loop with a couple of Snarks and two of the same G-to-2Gs would work fine.

Why not three Snarks and one G-to-2g? Is it because of colour changes? Is a G-to-2G-with-eater the smallest colour changing reflector?

dvgrn wrote:

You’ll eventually want to scatter some eaters and things all around the Recipe Storage Unit.

That way the quadratically-growing streams of gliders won’t bend around and blow everything up.

Won't we also need to protect the circuitry itself? Some of it is bound to crash, because otherwise we would have each splitter producing two new splitters, which would be an impossible exponential growth pattern.

Also, I think the thing we will have to protect against is a construction elbow being pushed towards the pattern we want to protect. So I suspect what we want is an eater and then in front of it a still life that annihilates the construction elbow and itself when the elbow gets pushed into it.

dvgrn wrote:The elbow on the straight-ahead branch could possibly be set up to do a mirror-image construction. If both branches have the same chirality, you end up with a branching pattern that looks kind of like Langton's Loops replication. I haven't looked much at what would happen with other branching options, like two different chiralities, a T-shaped glider splitter, etc.

I think the version with no reflection would make it easiest to predict where the crashes will occur.

EDIT: If you want this to be a "learning moment" I can probably work out the answers to these questions myself. I'm just thinking out loud.

A simple loop with a couple of Snarks and two of the same G-to-2Gs would work fine.

Why not three Snarks and one G-to-2g? Is it because of colour changes? Is a G-to-2G-with-eater the smallest colour changing reflector?

Pretty close. Yes, you could use three Snarks and a color-preserving splitter instead. Just figured it was easier to use what was already lying around.

Macbi wrote:

dvgrn wrote:

You’ll eventually want to scatter some eaters and things all around the Recipe Storage Unit.

That way the quadratically-growing streams of gliders won’t bend around and blow everything up.

Won't we also need to protect the circuitry itself? Some of it is bound to crash, because otherwise we would have each splitter producing two new splitters, which would be an impossible exponential growth pattern.

True enough. And the locations of those eaters (and sacrificial stoppers) will have to be determined, and then compiled into the construction recipe. Will there be two of them, or three of them, or four of them? It could get a little bit tricky there.

Macbi wrote:Also, I think the thing we will have to protect against is a construction elbow being pushed towards the pattern we want to protect. So I suspect what we want is an eater and then in front of it a still life that annihilates the construction elbow and itself when the elbow gets pushed into it.

Exactly right again. Probably a single sacrificial block will do, with an eater behind it. This can be found pretty easily with the Seeds of Destruction Game, or even by hand, once we know what push reaction will be being used at that point.

A simple loop with a couple of Snarks and two of the same G-to-2Gs would work fine.

Why not three Snarks and one G-to-2g? Is it because of colour changes? Is a G-to-2G-with-eater the smallest colour changing reflector?

Pretty close. Yes, you could use three Snarks and a color-preserving splitter instead. Just figured it was easier to use what was already lying around.

The most beautiful way to do it would be to have the recipe stored in a tightly packed loop of (snark + G-to-2g)s. Arranged so that the orignal memory loop would blend in seamlessly to the grid of replicators forming around it.

Macbi wrote:

dvgrn wrote:

You’ll eventually want to scatter some eaters and things all around the Recipe Storage Unit.

That way the quadratically-growing streams of gliders won’t bend around and blow everything up.

Won't we also need to protect the circuitry itself? Some of it is bound to crash, because otherwise we would have each splitter producing two new splitters, which would be an impossible exponential growth pattern.

True enough. And the locations of those eaters (and sacrificial stoppers) will have to be determined, and then compiled into the construction recipe. Will there be two of them, or three of them, or four of them? It could get a little bit tricky there.

I originally thought that the offset between the input lane and the 0 degree output lane was going to cause the grid to be very irregular and the copies to be crashing into each other in all sorts of different ways. But (based on a little doodle I just did) I think we get lucky and we actually only need one sacrificial stopper + eater per splitter.

to RLE? (Hmmm, do I have to use the "makerecipe" function from simeks-library-optimizer-binary.py given here?) Sorry for being needy but I find the forum very hard to search, and often the relevant information is hidden in a thread about something else.

Macbi wrote:I originally thought that the offset between the input lane and the 0 degree output lane was going to cause the grid to be very irregular and the copies to be crashing into each other in all sorts of different ways. But (based on a little doodle I just did) I think we get lucky and we actually only need one sacrificial stopper + eater per splitter.

I think you're right. All the attacking streams will come from the side that doesn't have an output stream.

Assuming the 90-degree turn copy is going clockwise, and the first splitter we build is northwest of the RSU (Recipe Storage Unit), then the protection on the RSU will prevent any streams from hitting the first splitter immediately. The second-order splitter on the straight NW branch will be protected for the same length of time (plus one more cycle). Let's give the second- and later-order splitters names, maybe strings of "S" for "straight" and "R" for "right", to say how to turn to get there from the RSU.

The R splitter will be hit by a grandchild stream from the S splitter: SRR will hit R. So we need a stopper and eater combination on that side.

I _think_ all the other attacking streams will be exact analogies of that one -- even the ones that show up after wrapping all the way around the outside of the RSU, however big that turns out to be.

Macbi wrote:The most beautiful way to do it would be to have the recipe stored in a tightly packed loop of (snark + G-to-2g)s. Arranged so that the orignal memory loop would blend in seamlessly to the grid of replicators forming around it.

Probably the whole thing will run a good bit faster if we just leave the RSU as a big open diamond, and line it with lots of stopper-and-eater combos, instead of packing it into a small tight back-and-forth loop. But if we're careful to make the loop length a power of two, like in the spiral-growth and triple-wickstretcher patterns, then it won't matter so much, at least in the long run.

Macbi wrote:Also, how do I compile recipes like [Snarkmaker] to RLE?

Yeah, that part isn't very well organized yet, because mostly nobody but me has run those scripts. The makerecipe function is more or less what you want, but there's a faster version now. You can use the same script for the output of slmake (but see below). I.e., slmake will not only tell you what the slow glider lanes are that build the splitter, but it will also compile that recipe into a single-channel recipe for you.

-- Actually, it's been a while since I last ran slmake, and now I don't remember if there's an extra optimization step in there somewhere. But more important, there's a newer secret intermediate build of slmake, "slsparse" ... that doesn't seem to be documented anywhere, but you probably ought to try using it instead of the May version.

As per the details below, it should give you a pattern file directly -- .mc rather than .rle, but same difference.

That means somebody definitely needs to update the slmake walkthrough to show how to use slsparse instead. That won't be me this week, unfortunately, but maybe next week sometime.

calcyman wrote:... it's now available from http://hatsya.co.uk/gol/slmake-2017-07-27.zip and the main source file is called 'slsparse.cpp'. As one can deduce from its name, it has been adapted to run efficiently on large patterns with many well-separated clusters; it should theoretically run in something very close to linear time (technically O(n^2) for boring reasons, but you'll need ridiculously large patterns before you start to feel the effect of the quadratic term).

Basically, it takes the pattern and tries to find a convenient 'chunk' to bite out of the bottom-right of the pattern. It then runs the regular slmake algorithm on the chunk, making note of both the salvo and the block position, re-inserting the block back into the pattern and reiterating. The advantage is that the slmake algorithm needs only manipulate much smaller patterns, blissfully unaware that it's being orchestrated by a higher-level routine.

Also, the program is modified so that outfile.mc just contains a single-channel recipe aimed at a single block with the efficient simeksian elbow-to-hand splitting at the beginning.

Consequently, that xs24 with a block-shaped internal hole now specifies the *elbow* location, rather than the hand location.

I'm progressing well so far. I have the syntheses for the G-to-2G, Snark, and the push reaction all working well.

dvgrn wrote: But more important, there's a newer secret intermediate build of slmake, "slsparse" ... that doesn't seem to be documented anywhere, but you probably ought to try using it instead of the May version.

Is there an easy way to make slsparse output the glider spacings instead of the mc file? Or to convert the mc file back to glider spacings? (For now I'm going to try ye olde slmake.)

My problem at the moment is that out of the positions I've tried for the eater they are either too close to the elbow or too close to where the block is being pushed out. But I haven't been very systematic about trying all possibilities, so I'll come back when I'm more awake.

EDIT3: Okay, I've got it working now. The memory loop is going to be period 2^21. It's annoying because the recipe is only just too long for 2^20, but optimising it would be a lot of effort, I think, and 2^21 is fine, right?

Macbi wrote:EDIT3: Okay, I've got it working now. The memory loop is going to be period 2^21. It's annoying because the recipe is only just too long for 2^20, but optimising it would be a lot of effort, I think, and 2^21 is fine, right?

Yes, I think if I had to fit that recipe inside 2^20 I would do it by rebuilding the Snarkmaker recipe. If I'm understanding things right, the current recipe is about 80,000 ticks too big for 2^20, which is maybe a twelfth of the full recipe.

It looks like the Snarkmaker is about a quarter of the full recipe, and with a custom search program it may well be possible to reduce it by about a factor of two. If all these wild estimates are right, that should bring the whole recipe down to 2^20 with some room to spare.

An update just for the record, on a maybe somewhat faster running version of your pattern from the ConwayLife Lounge. I was able to run the modified pattern up to 40 million ticks or so over the course of three hours.

EDIT: Wow, my old laptop is slow. Tried it on another newer machine, and got to almost the same place in just five or ten minutes. Or maybe 40M is where any machine will bog down?

It's gained 30K from the T=0 version, so the (210,5) offset between splitters is creating a large number of new hashtiles. I don't think a whole lot can be done about that without replacing the splitter. Would probably need a significantly larger one to get both branches synchronized to a precise power of two.

EDIT: On second thought, I'm not even sure that even perfect 2^N alignment would give HashLife enough of a boost. It would certainly help to have the step size at 2^21, but there will still be lots and lots of hashtiles at the construction sites -- there won't be repeated hashtiles at the construction edge until the recipe has cycled through about 2^12 short segments.

... Well, that's only four thousand kinds of hashtiles, times four for the four directions that the construction edge can eventually be facing... I guess that's still a challenge that HashLife can probably handle, as long as every splitter-sized tile along the construction boundary is a duplicate of every other one.

I'm not quite clear on what weird things happen once the branching pattern starts wrapping around the spool, though. Anyone care to set up protection all the way around, and see what happens? Or just write a script to put splitters in the right places ahead of time -- that would be much faster, and pattern would end up exactly the same.

EDIT: Looks like corner protection can be done like this -- nice and simple:

I haven't confirmed yet that this allows a protected square to be completed, let's say with the recipe inside the square, spooled onto Macbi's original double spiral (see #cgol on Discord). But it seems as if that should be possible with little or no trouble.

I don't know how the Snarkmaker recipe was made, so I can't optimise that. But calcyman said that his new slsparse is a bit more efficient than before, so it might help if I recompile with that. Also, when I was trying to get the spacing to work out I moved the construction elbow 50 cells further away from the pattern, which also resulted in the eater being 50 cells (or something like that) further to the side. This probably added a fair amount to the recipe. So I could try displacements of fewer than 50 cells and see if I can find the smallest one that works.

Also, I totally am planning to build the defenses around the memory loop. I just haven't gotten around to it yet. Note that you don't actually have to run the pattern all the way around to find where the eaters have to go. You can just copy and paste a copy of the G-to-2G with its two children in the right place, and keep on doing this all the way around.

Macbi wrote:Note that you don't actually have to run the pattern all the way around to find where the eaters have to go. You can just copy and paste a copy of the G-to-2G with its two children in the right place, and keep on doing this all the way around.

Nice! Though that means that the smaller 2^20-sized recipe spool will be almost completely full of gliders, so there will only be a short gap between cycles and the splitter chains will pretty much be full of gliders all the time.

It occurred to me that it shouldn't be too terribly difficult to steal one of the blocked-off outputs, and run it through a separate delay loop off to the side somewhere and then back to the original output, with timing such that construction recipe #N exactly cancels out recipe #(N+1) as it's coming out of the Recipe Storage Unit. That way the splitter chains would keep filling with gliders, then going empty again, then refilling.

However, until the number of hashtiles can be reduced by finding a more HashLife-friendly splitter, it won't really be a lot of fun to watch the pattern run, I guess.

I am kind of tempted to write a script to do basically the copy-and-paste trick mentioned above. That's a fairly easy piece of scripting, and it will amount to an accurate simulation of the pattern without actually having to run it. In a sense it will be running the pattern orders of magnitude faster than even HashLife can.

). The pattern worked great until the replicator units had made their way all around the memory loop. Each replicator unit is built along with a defence eater+block that protects it from other replicators trying to build where it is. But once they had got all the way around the loop they crashed into each other in a new orientation that I hadn't allowed for (I have a copy saved of the pattern just before the explosion, but the file is too big: 1.1MB).

So someone needs to replace the single defence eater+block that I used with a pair of eaters+blocks or some new pattern that can defend from both directions. But ideally you would want to do this while leaving the recipe still shorter than 2^20, and without moving the start and end position of the construction elbow relative to the replicator. Otherwise you will have to recalculate all the positions, which is very tedious and fiddly.

There's a limited amount of space too, because the defence eater+block can't be too close to the construction elbow, or to the path of the construction elbow of the next replicator to be constructed.

Macbi wrote:The pattern worked great until the replicator units had made their way all around the memory loop. Each replicator unit is built along with a defence eater+block that protects it from other replicators trying to build where it is. But once they had got all the way around the loop they crashed into each other in a new orientation that I hadn't allowed for (I have a copy saved of the pattern just before the explosion, but the file is too big: 1.1MB).

If you email it to me at b3s23life at gmail.com, I can probably post a file that size. Moderators are granted various unfair advantages.

Macbi wrote:So someone needs to replace the single defence eater+block that I used with a pair of eaters+blocks or some new pattern that can defend from both directions. But ideally you would want to do this while leaving the recipe still shorter than 2^20, and without moving the start and end position of the construction elbow relative to the replicator. Otherwise you will have to recalculate all the positions, which is very tedious and fiddly.

Can you maybe post a diagram showing where the new defense constellation could be placed relative to the existing one? Maybe just a piece chopped out of your pre-explosion pattern, with the added constellation marked in some way. EDIT: Right, you already did that. It will be easier to understand in the context of the full pattern, no doubt.

dvgrn wrote:If you email it to me at b3s23life at gmail.com, I can probably post a file that size. Moderators are granted various unfair advantages.

Done.

Can you maybe post a diagram showing where the new defense constellation could be placed relative to the existing one? Maybe just a piece chopped out of your pre-explosion pattern, with the added constellation marked in some way. EDIT: Right, you already did that. It will be easier to understand in the context of the full pattern, no doubt.

The pattern I posted showed their relative positions in the way they're supposed to be. Here's a cut-out of the "incorrect" arrangement, just before it explodes:

And as a picture -- this is run a little further, to re-fill the splitter tree.

QGC1 after 89.2 million ticks

QGC1-after-wraparound.png (110.11 KiB) Viewed 15402 times

In a real run to 89 million, the tree structure would never be empty. So I'm not sure if the generation reported by the pattern is exactly accurate or not. (?)

Macbi wrote:So someone needs to replace the single defence eater+block that I used with a pair of eaters+blocks or some new pattern that can defend from both directions. But ideally you would want to do this while leaving the recipe still shorter than 2^20, and without moving the start and end position of the construction elbow relative to the replicator. Otherwise you will have to recalculate all the positions, which is very tedious and fiddly.

I'm not sure yet that we really need two-directional defense, except for a singular situation where the wraparound tree structure first makes contact with itself. After a successful first contact, doesn't the construction process for the splitter to the west successfully create the required guardian block+eater constellation, to prevent the collision you're looking at?

The only problem seems to be that for that one exceptional case, there isn't any splitter to the west of that location. So we can just put that block+eater constellation in there manually for that one case.

If it does turn out that we have to recompile anyway, it might make sense to try a different splitter, and make sure that the copies end up at a Hashlife-friendly offset from the original -- maybe (128,0) or (256,0). Is there a smaller (or cheaper to construct) G-to-2G than the one below, that has both output gliders on the same color as the input, and also recovers in 90 ticks or less?

It might be good to require that the two output gliders are the same phase as well as the same color. In QGC1, the 90-degree output is nine ticks slower than the 0-degree output. I think that could be changed by +/-4N by changing where the elbow blocks are constructed, but they're never going to line up exactly.

This doesn't matter all _that_ much to HashLife, since different orientations have to be handled separately anyway. After wraparound there are just fifteen rows of splitters that are 36 ticks slower than their counterparts just below -- the timing mismatch never gets any worse than that.

It would be nice to get the timing mismatch down to zero, so that every current construction path branch is exactly the same length as every other branch. But it may be hard to do this and put the splitters on a Hashlife-friendly grid, without doubling the size of the splitter again (e.g., adding a trombone-slide Snark loop for timing somewhere). Anyone see any nice options among the Spartan Herschel conduits and H-to-Gs?

dvgrn wrote:I'm not sure yet that we really need two-directional defense, except for a singular situation where the wraparound tree structure first makes contact with itself. After a successful first contact, doesn't the construction process for the splitter to the west successfully create the required guardian block+eater constellation, to prevent the collision you're looking at?

The only problem seems to be that for that one exceptional case, there isn't any splitter to the west of that location. So maybe we can just put that block+eater constellation in there manually for that one case...

I've checked this in about every possible way, except for actually running the starting pattern long enough to rebuild the splitter tree. The QGC1-possibly-patched.rle.gz attachment in the previous message should turn into the following after 90,196,400 ticks (if the generation count in the original QGC1 pattern was correct).

I took out the shotgun and ran the recipe to the point where the Snarkmaker recipe is just finishing up deleting the 0-degree elbow. If you run the pattern, you'll see the end of the construction recipe working its way through the tree. After the Snarkmaker is done, the newly constructed splitters get their first use, and what they do first is to push out both elbows to test for the presence of an eater+block constellation.

If no constellation is found, then after a short break (to reach 2^20) each branch gets going on building a new constellation to protect the new splitter, followed by the new splitter itself, followed by the Snarkmaker recipe again. To see all of that happening, you can paste QGC1-possibly-patched.rle.gz into the middle of this pattern. You'll just have to delete one block out of the very first Snark after pasting -- that's the original arm's elbow, no longer needed if the splitter tree is already built -- and also one eater that prevents the double-spiral Snark loop from refilling.

Theoretically, if there were enough space, the tree would have produced a 26-digit number of branches by now -- 2^89. (Yay, exponential growth!) But since we're stuck in a 2D plane, there are only about 275 active branches. All the rest were suppressed at some point or another by another branch that got to the same location first. (Yay, quadratic growth!)

EDIT: Here's a test pattern that gives some idea of how much work Golly has to do to maintain the double-spiral Snark loop. With a step size of say 2^12 or 2^15, it builds the first few splitters impressively faster. As expected, the construction gets past my experimentally placed block+eater constellation with no difficulty.

My system gets bogged down pretty badly by the time it gets around the first corner... your mileage may vary, but this shortcut (putting the recipes in a long straight line) doesn't work much past the second corner in any case. We really need a Hashlife with optional hyperspace bypasses, so the gun can be kept in a separate universe.

Anyway, it looks like QGC1-possibly-patched.rle.gz is a working quadratic-growth pattern -- a sparse oblique slow spacefiller with a speed of (185,20)c/1048576 instead of the usual c/2.

dvgrn wrote:The only problem seems to be that for that one exceptional case, there isn't any splitter to the west of that location. So maybe we can just put that block+eater constellation in there manually for that one case....... it looks like QGC1-possibly-patched.rle.gz is a working quadratic-growth pattern -- a sparse oblique slow spacefiller with a speed of (185,20)c/1048576 instead of the usual c/2.

Well, the patch works just as expected. Here's some confirmation from Tom Rokicki -- thanks, Tom!

If you really want to give your computer a workout, try deleting one cell from any glider in QGC1+90598400.mc.gz. Hashlife is already using a lot of resources even when everything is under control, but if you add some growing chaos to the mix, things get difficult very quickly --!

Congratulations to all involved for the construction of this interesting quadratic growth pattern. I tried running the QGC1-possibly-patched pattern myself but didn't have enough RAM available to get reasonable performance (that was only 3GB, so I'm not surprised it wasn't sufficient). Do you know how much RAM Tom allowed hashlife to use to simulate the pattern and how much is required to get the whole thing to run reasonably well once it has wrapped around and is steadily expanding?

wildmyron wrote:Do you know how much RAM Tom allowed hashlife to use to simulate the pattern and how much is required to get the whole thing to run reasonably well once it has wrapped around and is steadily expanding?

Ah, I should have mentioned that. I was able to get to 40 or 50 million ticks on a laptop with just a gigabyte or two allotted for Golly, just by being patient and using a relatively high step size -- 2^12 to 2^15, somewhere in there.

Apparently Tom ran a few million ticks on one of his monster boxes, and Golly used 35GB pretty quickly if it was available (but presumably not many of those hashtiles could get re-used, because things keep changing around the edges of the bigger hashtiles.)

The last report was from 98 million ticks: "It's using 220GB and it's still quite slow." So even quite unreasonable amounts of memory aren't going to let Golly run away with this one, it seems. It might be worth trying a splitter tree aligned to a 2^N grid, and see if that improves things at all:

Here's a version of the pattern as it would look after 99 cycles, 103809024 ticks, except there aren't any gliders in the splitter tree. If you run this to populate all the splitters, it should eventually return to exactly the same state as the actual QGC1 pattern. EDIT: Removed a blocking eater accidentally left in, SE of the shotgun.

It would be easy to simulate any later generation of the QGC1 pattern, by writing a script to add more rows of splitters along the four edges, adding 2^20 = 1048576 ticks to the generation count per row, and then running the pattern just far enough to populate all the splitters and reach the target generation.

dvgrn wrote:I'm not sure yet that we really need two-directional defense, except for a singular situation where the wraparound tree structure first makes contact with itself. After a successful first contact, doesn't the construction process for the splitter to the west successfully create the required guardian block+eater constellation, to prevent the collision you're looking at?

I can't believe I was only a block and an eater away from the solution!

Macbi wrote:I can't believe I was only a block and an eater away from the solution!

I'm betting you tried pretty much the same patch, but didn't get the offset quite right for whatever reason, or maybe also added another patch nearby in a place that needed to be left empty. Once you've tried something and it doesn't work, it's easy to stay confused for a very long time --!

There's a tricky moment in the construction when it looks like the elbow for the relevant branch of the splitter has been constructed, but it isn't quite in the right place yet -- it gets sneakily moved over a bit later. So if you try to put in the block-and-eater at the correct offset from the wrong block, Very Bad Things happen, and it kind of looks like there's an unfixable overlap problem.

New subtopic:

I was thinking that it seemed slightly weird that all paths are almost exactly the same length, with possible deltas of 0, 9, 18, 27, or 36 -- so pretty much the same exact thing is happening all around the edges of the pattern, all the time. So here's another experiment, where different paths are really significantly different lengths, so you can see different stages of the construction by inspecting different parts of the same pattern.

another way to get a self-constructing spacefiller started

QGC1b_small.png (60.28 KiB) Viewed 15156 times

There was some vague hope that isolating the gun in the center would reduce the number of hashtiles. Theoretically the tiles in the center are all exactly the same after 2^20 = ~1 million ticks, so Golly could re-use saved hashtiles and speed up the simulation after the first cycle. Unfortunately the number of unique hashtiles around the edges goes up really fast, counteracting any advantage in the center.

So I don't think anybody will be too impressed by the speed of this version, either. Here's the base pattern:

There are various things wrong with this, but it should help with visualization anyway. Here's a walkthrough of a replication cycle:

1) The story begins with a simple 2-engine Cordership puttering along through empty space (not shown).2) After a long, long time, a single-channel glider stream sneaks up from behind the Cordership and stops it, without allowing any gliders to be released.3) This glider stream is really two copies of the same stream, one following directly behind the other.4) First the single-channel stream builds two Cordership seeds and some supporting stuff (shown above) -- maybe using a 0-degree elbow, but maybe that won't be necessary.5) The two seeds are triggered simultaneously, more or less, and two new Corderships head off toward infinity at right angles -- one NW and one NE (shown above).6) Let's call the place where the Corderships start the "South Corner".7) The next part of the single-channel stream is the South Corner Splitter recipe. It builds some splitter circuitry at the South Corner. One output of the South Corner Splitter is pointed carefully at the NW Cordership. Initially it's blocked by an eater.9) The other output is the first part of a diamond-shaped memory loop. This part of the circuit may have to be a little oversized to get the timing exactly right, but let's worry about that later. For now, let's just say that this output lane is transparent, it also points NW, and it's on the single-channel stream's original lane.10) There's a big gap in the recipe at this point, several times as long as the recipe so far, while we wait for the Corderships to get far enough away to make a big enough memory loop.

11) The first glider after the gap is carefully timed to hit a one-time circuit that sends Following Gliders NE and NW to both Corderships (shown).12) These two Following Gliders do _not_ shoot down the Corderships. They just produce a little junk at the West Corner and the East Corner, plus two 90-degree output gliders (shown).14) Those output gliders collide at the north corner to make a block target (shown).15) The Corderships continue on their merry way, and we can forget about them until step 40.16) Immediately following the NW Following Glider (not shown) is a West Corner Snark recipe, converting the junk at the West Corner into a Snark.17) Immediately following the West Corner Snark Recipe is the North Corner Snark Recipe, which bounces off the West Corner Snark, and eventually -- you guessed it -- converts the block at the North Corner into a Snark.18) Immediately following the North Corner Snark Recipe is the East Corner Splitter Recipe, which passes through the West and North Corner Snarks, hits the East Corner junk, and builds a minimal-sized splitter.19) The East Corner Splitter has one output, blocked by an eater, pointing at the still-receding NE-ward Cordership.20) The East Corner Splitter's other output points back to the input of the South Corner Splitter.

Now we're starting to get somewhere! That was the last of the required construction, except for a small amount of one-time circuitry that will be described later.

A second copy of all those same gliders can follow along behind the first copy, and they'll automagically end up cycling round and round the diamond-shaped memory loop. Hopefully the loop a power-of-two period, thanks to some hypothetical careful design of the South Corner Splitter's input circuit.

I haven't told the story yet of how two copies of the recipe escape from the memory loop again, or what eventually happens to the two receding Corderships -- or what happens when this replicator's great-great-grandchildren show up in this vicinity several cycles later, and run into a scattering of old empty circuitry instead of empty space.

Luckily that part of the story can be handled with just a few dozen more small still lifes, so I'll save it for a follow-up post.

For now, I'd be very interested if someone can prove that the memory loop can't ever possibly be big enough to hold all those recipes, plus the required gap length.