dvgrn wrote:For now I'll call these hypothetical OTTs "BT-Spartan" (Better Than Spartan). The name probably won't stick, but you never know until you try...!

Pseudo-Spartan, perhaps?

Well, but "pseudo-" is already kind of overloaded in Life terminology, with at least three unrelated uses (guns, still-lifes and barber-poles).

I've already used "Spartan++" for regular Spartan objects plus dead spark coils and tubs-with-tails. BT-Spartan potentially adds dozens of objects and closely-spaced constellations that would be really painful to construct separately, or in any other orientation -- there just happens to be a shortcut for one particular slow-salvo direction.

Speaking of slow salvos, here's the lookup table I'm currently using for deciding which eater recipe to build next:

Every recipe starts with a construction-arm "hand" block (shown in red in the pattern above) and produces an eater -- usually on one edge or another of its construction envelope, so it can be placed close to already-constructed still lifes -- and also a new target hand block, shown in green.

There always has to be a target to work with, or construction can't continue... at least, not without breaking down some perfectly good constructed object and then rebuilding it. That ended up happening with blocks a couple of times in the SE Replicator recipe, which is one of the reasons I'm sure that there's a sub-300-glider recipe out there.

Some future round of slow-salvo compiler optimization should probably take advantage of the fact that there are thousands more variants of these recipes out there, which build the same eaters but put the output hand blocks in slightly different locations, which may turn out to be exactly where they're needed to start the next construction.

Really there's no reason -- besides "Keep It Simple, Stupid"! -- to insist that the target "hand" go back to a block stage between recipes. Here again, there are a few places in the SE Replicator recipe where I cheated and used a honeyfarm, saving a step (since the huge majority of block-move recipes immediately turn the target block into a honeyfarm, anyway).

Allowing other hand objects could increase the total number of object recipes by several orders of magnitude, potentially allowing for much more efficient constructions -- maybe 30-50% fewer gliders. But it would also increase the compiler's workload in the same proportion... so for now I'm leaving that optimizing project as an exercise for the reader!

Is there a non-KISS reason to limit yourself to having only 1 live "hand" object at a time?

Suppose you've found a recipe that builds an object of interest and leaves two spare blocks. Construction could continue using one of these blocks as the "hand", and then return later to continue with the other.

Of course this makes the optimisation / ordering process even trickier. For one thing you have to leave a path open for the construction salvos to reach the second "hand". For another thing, the search space now has branches in it, making it much larger and harder to examine.

This is all off the top of my head - I haven't looked much at the intricacies of construction.

MikeP wrote:Suppose you've found a recipe that builds an object of interest and leaves two spare blocks. Construction could continue using one of these blocks as the "hand", and then return later to continue with the other.

Yes, that works just fine! This is actually another shortcut that I took a couple of times in the hand-built SE Replicator construction. Multiple hands came in really handy at least once -- I would have had to move the current hand block a long way to get to the next construction site, but I was able to modify a previous cleanup to leave some junk behind in the right place.

Then toward the end of the recipe, I left an extra beehive lying around for a long time, thinking it would be useful... but it wasn't, so it just got shot down the next time I was in the area -- no harm done.

This suggests that the compiler should know about two different kinds of object constructions -- clean recipes, for when a hand object won't be needed any more, and object+hand recipes where the construction is planned to continue somewhere in the near vicinity.

MikeP wrote:Of course this makes the optimisation / ordering process even trickier. For one thing you have to leave a path open for the construction salvos to reach the second "hand". For another thing, the search space now has branches in it, making it much larger and harder to examine.

All very true. In semi-manual constructions, the part about leaving a path open isn't too difficult in practice. Basically you only want to drop extra hands right near where a future object construction is going to happen. If the extra hand is going to get in the way, you could move it off to the side... but if it's getting in the way, that's probably a sign that you don't need it in the first place -- you can split an extra hand off of whatever reaction it's getting in the way of, instead!

At least 40 of the 300+ gliders in the current recipe are straight annihilation reactions, so most of those objects could have been used as extra hands if they'd been needed.

I'm thinking about continuing development on a semi-manual compiler, where the user always chooses the next object to construct, and then cycles through the various target objects that could be left over after the construction. Target objects would each have a destruction recipe associated with them, so they could easily be removed if they got in the way of a later recipe, or if they were going to stop being accessible because of getting "buried" by later constructions.

A completely automatic searcher/compiler is certainly still possible with all these refinements, but the heuristics would be very tricky. It probably makes more sense to stick with the simple one-handed model for a completely automatic search, which would concentrate instead on finding lucky matches between hundreds of thousands of object recipes with different input and output hands.

That's something that can very easily be done without too many difficult judgment calls. You just pick whichever object-recipe pairing is the cheapest in terms of glider pairs on the memory tape. Any individual search can easily be broken off if it's found something "good enough", and if going through all combinations would take too long. So you don't get the kind of combinatorial explosion that's likely to bog down a non-human-assisted compiler, where the algorithm gets lost for years looking at all possible twigs on an unproductive branch of the search tree.

It will be interesting to see which method will end up producing shorter recipes -- the simple automatic search or the human-inspired semi-manual one. Ultimately there may be a way to get the best of both worlds: set up short stretches of construction to do exhaustive searches on, maybe two to five objects in a row -- but leave to the user most of the key judgment calls about which hand objects to keep or shoot down, and what to construct next.

The main thing I'm keeping in mind is that it's going to be pretty much impossible to find the absolute best recipe for any given construction, at least above ten-object constellations or so. As Paul Chapman said once, just writing down an accurate description of all the parameters of the search space is an NP-complete problem...!

codeholic wrote:A loaf instead of a boat can also emit a glider in order to remove the blocker on the glider stream replication lane...

Nice! Only nine still lifes, then -- and it would be 8sL, except that I think all the single-still-life glider turners are color-changing, and this happens to need a color-preserving turn like the two-block OTT. [I just looked at boats, longboats and eaters -- am I forgetting something?] Could use a dirty turner, of course -- increasing the replicator's still-life count by one block isn't exactly the end of the world:

...Or I'm really tempted to use a toad, even though it isn't stable let alone Spartan -- it's certainly BT-Spartan, and there's no problem controlling the period so that it works for this purpose.

I'm working on cutting down the unnecessarily complicated one-time circuitry I used in the prototype replicator. Once that's done I can start on the construction recipe for the Output Copier (the Silver reflector to the northeast) and this Construction Stopper. At the moment it might look something like this:

Hmm, that 102sL count is a little annoying somehow. Are there not any two-still-life candidates for the final output-stopping eater seed? Even zero-clearance would be no problem there. I'm less likely to want to use P2 objects for this seed, though -- it would affect the allowable replicator periods, or at least tend to cause minor synchronization headaches.

I could probably manage without the two target hands in the NW corner -- the yellow blocks -- by splitting a hand off directly from the elbow when I need it. At the moment I only know a really expensive way to do that with 9hd glider pairs, but it's probably pretty easy. Anyone need an interesting little research project?

-- And I'm pretty sure I can set things up so that the universal constructor's period quadrupler starts in its zero-block state instead of a one-block state. So that should do the trick -- a Conway's Life replicator with under 100 still lifes! [Yes, there will be a few gliders, too...]

codeholic wrote:Well, I've found a 2sL seed for the stopper, but you probably will not like it...

Well, none of the problems you listed are show-stoppers by any means: ships are easy to construct, a boat-bit catcher is fine on the output lane especially because cycles are always in groups of four anyway... and there are plenty of OTTs that can turn a glider onto a lane 6hd away from an active lane.

[The previous prototype had an OTT that did the opposite -- a beehive and block "robbed" a glider from a lane only 1hd from an already-used lane, and sent it off at 90 degrees. But in this direction, there wouldn't even be a problem with a complete overlap; a boat turner can manage that trick, for example, with 2hd extra clearance.]

Unfortunately adding a boat turner brings the total number of still lifes back up to 3 again -- so I have no incentive to change the current model...! Seems like the only hope of improvement is for the trigger glider to come in perpendicular to the lane to be blocked.

I can dig up a more efficient recipe when the compiler search is working properly. But there is a problem.

The Output Stopper eater has to be shot down with a glider from the NW, then reconstituted by a glider from the SE. An eater in this boat-bit-catching orientation can be shot down with no problem, with either color glider -- but one of those paths passes through the pre-constructed longboat+ship seed. The output glider from the current Construction Stopper is the wrong color (of course) to hit the accessible annihilation path behind the longboat.

The boat+ship and 2ship eater seeds aren't usable here -- the seeds need to be constructed already when the eater is destroyed, but they're both in the way of the annihilation glider from the NW.

So I guess I'll still stick with the boat+2block eater seed for now...!

The test pattern below runs pretty well up to a step size of about 2^22. After that, Golly has a tough time, at least on my laptop with 2GB of RAM. With this design, the memory loop period can't be a power of two -- it's 27,147,946 ticks in the test pattern, about the same as the full replicator will need -- so the number of hashtiles will tend to keep going up, at least until a large power-of-two number of reflectors has been built.

The construction recipe for the SE reflector is generated from T=0 to T=13430784 (or thereabouts). It doesn't actually start building the SE reflector until the last glider in the salvo has been created. The salvo finishes the construction at about the same time as the next salvo construction cycle starts.

So there's generally something interesting happening either at the NW end or the SE end of the memory loop, but never both at once. The loop could be trivially cut to half its current length, or could be reduced by 75% somewhat less trivially. I'm going to save those improvements until the full construction recipe for the replicator is completed.

This test pattern will stop working when the vertical line of SE reflectors meets the diagonal construction-arm lanes, but I'm not about to run Golly long enough to see that happen! If anyone wants to figure out exactly when the crash will occur, there's an easy shortcut.

There will be 80-odd still lifes in the replicator body, plus another dozen or more temporary still lifes used as one-time turners -- so about 100sL in all. That means the recipe in the test pattern is about a fifth of the way to a completed replicator. The Geminoid replicator project is finally starting to get somewhere!

As I hoped, the 4hd-clearance eater seed turns out to be far enough out of the way that it's easily constructible for use as a Construction Stopper -- even with a limited set of elbow ops (four cycles or less):

Now all that's left is the variant construction for a loaf and a toad, over on one side, for when the two glider outputs are needed.

Looks like I'll probably keep this solution to the Construction Stopper problem for the time being, unless something comes along that's obviously much more efficient. Just so I don't lose track of them, the glider-pair recipe looks like this --

The links above are to the scripts that can convert these respective recipes into RLE.

EDIT: It gets a bit expensive when two construction stoppers have to be built on opposite sides of the construction lanes. My standard gp-compiler doesn't work, because it doesn't know enough to worry about elbow-operation reactions hitting already-constructed objects. The last few dozen components had to be chosen and tested by hand. Nothing terribly difficult, but I really don't want to have to rebuild one of these...! Will have to think about how best to explain confined-space constructions to the compiler.

Here's a working model of a Construction Stopper seed recipe with 639 glider pairs. A more thorough search for elbow operations will probably reduce this cost by half, and very likely another 50% improvement is possible with more carefully designed slow salvos. I picked easy splitters, block moves, and object constructions with plenty of space around them -- but there are dozens of degrees of freedom in this recipe, and usually dozens of workable choices for each sub-recipe, so it's a sure thing that I didn't find the most efficient combination.

The following is a Golly metacell file showing the construction and triggering of the seed. This will the the very last recipe that runs through the construction arm. The output glider will shoot down the eater that blocks the secondary output from the universal constructor/replicator unit.

Hmm, a minor setback: I worked on the middle third of the replicator a little bit last night -- the "Output Copier" component that reflects a copy of the construction data onto the new memory loop, when the time is right. Unfortunately a still life that I'd been thinking was part of the Output Copier is actually part of the NW replicator unit.

The "Output Stopper" eater has to already exist when a new construction cycle starts -- its job is to block output gliders from the first cycle of the memory loop, and then get destroyed to allow the second-cycle gliders through. But out in the middle where I had put it, the eater gets in the way of the construction of the SE reflector. It will have to move down into the shadow of the NW RU, like so:

This doesn't seem to bring up any new problems, except that I'd already finished a recipe for the Output Copier, with (it turns out) half a dozen still lifes in the wrong locations -- and that the construction stopper seed recipe doesn't _quite_ fit with its new neighbors now, so that will have to be revised -- and that the still life count had to go up by one. An extra boat is needed because of the orientation of the new eater seed's trigger glider. Given the advantages of this design, I can live with that... but I'm open to suggestions for optimization as usual!

There's now a way to use either color of glider to shoot down the Output Stopper eater -- while I was rearranging things, I moved the hand block to a place where it could be useful.

Speaking about optimizations, I wonder, if one could build a stopper on construction lanes and send a glider in order to remove the output copier stopper, with glider pairs directly, without use of seeds.

Something like

Build a stopper on the first construction lane with some leftovers lying in front of it.

Use the leftovers to build a stopper on the second construction lane with yet some leftovers lying in front of it (could be the same recipe as the first one, but mirrored).

Use the leftovers to send a glider in order to remove the output copier stopper, and at the same time clearing the construction lanes from the leftovers and thus activating the stoppers on the construction lanes.

codeholic wrote:Speaking about optimizations, I wonder, if one could build a stopper on construction lanes and send a glider in order to remove the output copier stopper, with glider pairs directly, without use of seeds.

That sounds doable, sure. There are lots of ways of solving the suppression problem. The seed method seemed like it would definitely produce a solution, so I've settled on that for now -- but no doubt somewhere out there there's a much more efficient way to do the same thing.

I haven't seen a glider-pair recipe that produces an eater (or a boat-bit catcher) on one of the construction lanes. For your suggestion you'd need that *plus* junk in front of the eater that can be turned back into an elbow. That certainly isn't impossible -- the search space is huge. But it would take some retooling of DOpSearch code, or maybe a new search utility, to dig something like that up.

I'm also looking for elbow splitters and direct *WSS outputs, among other things, so it might be worth doing the coding to be able to find non-standard elbow ops. Another useful collection would be "dirty" elbow operations that throw junk far off to one side or the other. The junk could then be used as targets for slow-salvo construction, so pre-built hand blocks wouldn't be necessary. Or if there are enough junk-producing ops, maybe the junk could be arranged directly into an eater seed with no slow salvos needed.

Really the problem is that there are too many options! A replicator along these general lines could have been built any time since 1996, or certainly since 2003. It's taken a long time to organize a simple one-arm construction toolkit, mostly because using the toolkit means ignoring almost all of a much larger (and perfectly good) search space.

-- but it should be easy enough to build them in passing before the SE reflector construction. They're pretty well out of the way of all the later SE-traveling salvos, since most of them are backstopped by the NW replicator unit anyway. The next test pattern, with construction recipes for everything except the NW RU, will be coming along... sometime or other, when I can find another spare hour.

dvgrn wrote:An extra boat is needed because of the orientation of the new eater seed's trigger glider.

A barge and a block may be cheaper than two distant boats...

These look like they'll definitely come in handy, but I don't think they'll be cheaper than the boats. I can move the pair of boats right over next to the Output Copier circuitry, but still with plenty of space around them, and build them at the same time. So they'll be almost as cheap as single blocks.

I had a quick look at my not-yet-organized database of object constructions. There are several hundred direct constructions of barge+block, including dozens of near misses:

But Murphy's Law so far seems to be doing a good job at keeping really good lucky finds just out of reach. Sour grapes -- something like this would only have worked for two orientations of the barge+block constellation, anyway, and no doubt it would have turned out to be the wrong two...!

codeholic wrote:I warned you, that my gencols search had been still running...

Wow! 15hd clearance, and perfectly symmetrical, and no problem with the elbow staying beyond the eaters.

I suppose this counts as another minor setback, but in a good way: I hadn't gotten around yet to building the two extra hand blocks for my revised Construction Stopper design, so gencols has come through just in time. Thanks!

The glider-pair recipe is down to 253 base pairs, starting from three easy-to-construct still lifes. And I'm sure that's far from the minimum. I wasn't careful enough about picking the construction reactions, so some intermediate targets drifted to within 4hd clearance, meaning that less efficient low-clearance elbow operations had to be used for part of the construction.

The compiler doesn't yet know about the full range of possible elbow operations, anyway -- I've done some partial 5-cycle searches that should already at least double the options for glider outputs. There are certainly enormous numbers of 6- to 8-cycle elbow ops out there, too, if I can just manage to get a search to reach them without running out of memory...!

dvgrn wrote:Given the advantages of this design, I can live with that... but I'm open to suggestions for optimization as usual!

Speaking about optimizations again... I thought that Output Copier could actually play the role of SE Reflector, if one could modify it in the way, that it could receive input from two directions (is it possible?), and build a Replication Unit in place of SE Reflector. This design would make the replicator glide-symmetric. I'm not sure, if another recipe would be needed for building a grandchild (probably not), but as far as I understand the current replicator design, there is a place to encode this recipe in, since for now only every second glider is being expressed. This design could save a whole Silver reflector to be built and also it would make the replicator two times faster, because the RU wouldn't need to wait until the glider stream comes back from the reflector.

codeholic wrote:Speaking about optimizations again... I thought that Output Copier could actually play the role of SE Reflector, if one could modify it in the way, that it could receive input from two directions (is it possible?)

I have to read and think about this very carefully, because I've been going over Geminoid designs for a couple years now and tend to think that I've already thought of everything -- even though no doubt I haven't!

It's absolutely possible to make a Geminoid replicator unit that can receive input from two directions. The only problem is that the additional circuitry is pretty big. In the simplest form that I've been able to find, the extra circuit looks like... a Silver reflector. You can't even use something expensive like a Snark, because somewhere a glider path needs to be transparent to allow the two perpendicular data streams to merge.

There is one of Guam's tandem-glider components that's naturally transparent, so if you use tandem gliders instead of plain gliders in the memory loop, there's definitely potential to save Silver reflectors there -- and also tighten up the spacing between signals. However, what you gain in the Silver reflectors you lose in the Herschel splitters -- or so I've found so far, at least...

codeholic wrote:... and build a Replication Unit in place of SE Reflector. This design would make the replicator glide-symmetric. I'm not sure, if another recipe would be needed for building a grandchild (probably not),...

Right up until the most recent replicator design, most of the Geminoids I've worked on have either been glide-symmetric or have had two exact copies of the same replicator unit at the two ends. This followed right along with the the new ideas in the original Gemini spaceship.

That meant they either had to travel on an exact diagonal (the "Demonoid" design that has gotten the most attention, e.g., in Paul Chapman's Seeds of Destruction Game), or they were bigger because they needed two different circuits to accept signals from the NW and SE, or they needed merge circuits (see above), or they needed different recipes at the NW and SE ends (see below).

It's possible to design an oblique Geminoid that still re-uses the same recipe at both ends, even though the two construction arms have to bend in opposite directions -- but it takes extra circuitry to get the glider pairs to have the same timing at both ends. Even if you keep the glider pairs in two separate channels instead of encoding them, you tend to end up with differences in timing because each glider in the pair has to be routed to the opposite construction-arm lane in the SE from the one it goes to in the NW:

codeholic wrote:... but as far as I understand the current replicator design, there is a place to encode this recipe in, since for now only every second glider is being expressed.

You're absolutely right! There's a huge amount of potential for this encoding method to do very interesting things -- build two completely different-looking replicator units at the two ends of a Geminoid, and so on. Or something I'd really like to see is a diamond-shaped Geminoid, where the encoded gliders are in groups of eight, and each pair runs the replicator unit at a different corner of the diamond.

That might end up being the first Geminoid design that has few enough hashtiles that Golly could really "run away" with it. It might even be possible to make a 2D replicator out of a design like that, where the two loops slowly separate from each other, and the next replication cycle doesn't start until the two are safely distant from each other. That would nicely mimic DNA replication in bacteria, which have circular chromosomes.

However, the coding inefficiency of the current replicator design is only temporary. Once the entire recipe is done, I can fold it over on itself and get rid of the non-coding base pairs. Just have to make sure that there's an odd number of glider pairs in the loop, and that's easy to do by substituting in an N+1gp move recipe for an Ngp one somewhere, if necessary.

So I still have some hope of building a linear replicator that fits in a smaller bounding box than the original Gemini spaceship (as well as having a much much smaller population).