dvgrn wrote:The horrible slowness of these boustrophedonic designs is almost all due to the unmanageably large number of hashtiles resulting from nearby glider streams traveling in opposite directions.

A better solution to that problem might be to allow a Hashlife-type algorithm to make diagonal rectangular hashtiles so that each glider stream can be run independently.

A for awesome wrote:A better solution to that problem might be to allow a Hashlife-type algorithm to make diagonal rectangular hashtiles so that each glider stream can be run independently.

In a sense that's what I was suggesting with the Hyperspace HashLife option -- each diagonal rectangle would be embedded in an otherwise empty square hashtile, is all.

A lot of the power of HashLife comes not from the complexity or subtlety of the algorithm, but from its ridiculous simplicity. That simplicity is very heavily contingent on square orthogonal 2^N tiles. Maybe there's a way to generalize the method to be able to handle arbitrary-length diagonal rectangles, without higher-order rectangles getting too wide and picking up neighboring opposing glider streams... but I think it would take a lot of pattern-specific special-case coding.

Once we're doing special-case coding, it suddenly becomes fairly easy to write an algorithm that can produce any future generation of a Demonoid pattern, on demand, in a fraction of a second. The algorithm could be told in what order the still lifes are constructed, and what the position and order and time of transition is for the 4818 elbow patterns. The signal gliders are always the same, except for a few that are temporarily in Herschel form, going through the circuitry, so it's easy to drop those into place.

So we'd end up with an algorithm that's billions of times faster than HashLife, because it can instantly tell you for example that the Demonoid will be at (-130N,-130N) in 1636712N ticks -- whereas HashLife has to work really hard to figure that out every time around.

But that's on the other side of a subtle line between simulating a pattern's evolution, and predicting it. If there's a subtle bug in some future Demonoid, where two components interact where they're not supposed to interact, then this kind of predictive algorithm might not even notice the problem!

Theoretically it's possible to write a generalized algorithm that can analyze signal circuitry, prove theorems about specific patterns using that circuitry, and use those theorems to achieve huge simulation speedups. Compared to something like that, HashLife would look like plain mindless brute force. Which is pretty much what it is, really -- brute force that uses memory more than CPU cycles.

On the other hand, actually writing and debugging that hypothetical new algorithm is not a task that many programmers or mathematicians would want to face...!

Maybe there's a way to generalize the method to be able to handle arbitrary-length diagonal rectangles, without higher-order rectangles getting too wide and picking up neighboring opposing glider streams...

Not too sure. For a cell 'c' to advance in N gens one would have to get the information of all the cells inside the 2N+1 by 2N+1 square, with 'c' in the center. Unless you know that the patterns are mostly gliders and don't affect each other... Or maybe that's what you mean by this?

but I think it would take a lot of pattern-specific special-case coding.

Congratulations!I'm going to make it a point to retrace the collaboration on this one.SO much going on. Not only the slow salvo constructions, but also the duplex 10h elbow manipulation. Superb!

Two questions (m... maybe three):1st (and it took two viewings to 825,500 generations): Is it a single construction tape in a double serpentine?2nd: after the replicating reflectors there are two guns, a singleton and a doubleton. Was the doubleton usage for convenience in achieving the 10h shift? That would make the second output superfluous. Thus:3rd: Its eater placed for easy deletion w/ SoD?

Again, NICE.triller

The most exciting phrase to hear in science, the one that heralds newdiscoveries, is not "Eureka!" (I found it!) but "That's funny ..."-- Isaac Asimov

triller wrote:Two questions (m... maybe three):1st (and it took two viewings to 825,500 generations): Is it a single construction tape in a double serpentine?

Yes, that's certainly what it looks like to me. One glider loop is copied for insertion into the NW31 gun, and the other for use in the NW41 gun. Both loops are synchronized with each other, and work in tandem to move the elbow block and create hand gliders for construction.

triller wrote:2nd: after the replicating reflectors there are two guns, a singleton and a doubleton. Was the doubleton usage for convenience in achieving the 10h shift? That would make the second output superfluous. Thus:3rd: Its eater placed for easy deletion w/ SoD?

The first part of the conduits are identical, until the NW31 and NW41 H-->Gs. NW31 conduits are commonplace--it's one of the natural outputs of a bare Herschel. However, there's only one small NW41 that we know of:

As you can see, it produces an additional NW19 output, which we don't want. And hence the eater--placed, like you surmised, for easy construction and destruction.There's also a rather tricky eater weld here, which chris_c found a good construction recipe for, allowing this design.

That was a much more complicated blueprint than the design we ended up with! Even so, that was the model that got Paul Chapman interested in the project. He wrote the Seeds of Destruction Game to look for self-destruct circuitry for it.

The key improvement was to use the same reflectors to carry both recipes in series, saving a lot of reflectors and period doublers, and allowing recipes with singleton gliders to be encoded easily. You're stuck with pairs only if the rule is that "gliders on the tape are sent to alternate construction lanes" -- and then you usually also have the problem of building extra circuitry to delay one glider until its partner shows up... though that's less of a problem with the new faster syringe-based circuitry, come to think of it.

And now the 0hd Demonoid design cuts the number of still lifes to be constructed in half again. It will be interesting to see how much smaller a replicator unit can get. I'm still keeping my fingers crossed for a good Spartan G-to-H or G-to-2G.

Meanwhile I'm somewhat tempted by this design for a 0hd Demonoid, because it allows the signal repeat time to be reduced to 90 ticks:

On the other hand, that would require rebuilding all of the self-destruct circuitry, and then coming up with all new slow-salvo recipes for the whole combined mess... so maybe I'll let someone else have a turn building that one.

triller wrote:2nd: after the replicating reflectors there are two guns, a singleton and a doubleton. Was the doubleton usage for convenience in achieving the 10h shift? That would make the second output superfluous. Thus:3rd: Its eater placed for easy deletion w/ SoD?

Right again. The space of possible optimizations for this design is just ridiculously huge. What generally happens is that each little subproblem gets solved exactly once. After a solution is shown to work, it gets built into the assumptions of the next stage, and then it becomes really hard to change it.

In this case, that eater could be placed anywhere in a long line out from the NW41 conduit, and more empty space around it was better because it was one of a few necessary objects in the "danger zone" very close to the construction lanes. I noticed that there was one location and orientation for that eater, that allowed a block destruction in the already-existing self-destruct circuitry to clean it up for free. Try removing the copy of that eater at T=1428 in the NE wing of the c/12700 Demonoid, and you'll see that the block still gets cleaned up in the same way.

"For free" is really hard to resist, even when it makes the circuitry look a little funny -- especially when it means being able to re-use exactly the same self-destruct recipe for Circuit A and Circuit B. So that arbitrary solution very quickly got baked into the design, and we never thought about it again.

There's one other place in this design (usually there are more) where the eater placement is arbitrary, and maybe an inspired adjustment could allow for a cheaper construction or destruction. It's a little hard to imagine an automated compiler algorithm that can intelligently take into account all the possible placement variants, but I do hope someone tackles that problem someday.

Okay, here's a reworked "TileA" recipe for use in a 0hd Demonoid. Really it's closer to a subset of TileD, since A was the one with the NW41 attached to it. But it will be just as confusing to rename it to Partial TileD at this point, so let's just call it TileA Version 8:

This is definitely a suboptimal duct-tape-and-baling-wire patch added to the original recipe. If I were starting from scratch I'd take out the longboat+boat combination in the west corner. It would be better to figure out some other way to shoot down the connected eater, that doesn't require an extra block to absorb the output glider. In the original Demonoid, that glider very neatly takes out the leftover NW41 still life, but now suddenly it's not needed.

So I'd be vaguely embarrassed by this design, except that it was so easy to finish it. For some reason I'm not even slighly tempted to start over and try to produce a slow salvo that's five percent more elegant. It would be great practice for any other aspiring self-constructing circuitry engineers out there, though...!

Yes, sorry! I've been working on the 0hd stuff in bits and pieces but I've been too lazy to write about it.

First of all I've made a 0hd recipe for the near construction lane stuff. I used a slightly different method to suppress the unwanted glider: dropping a block directly from the construction lane just behind the eater. The recipe was constructed with copy/paste and so we will eventually need a script to turn this back into machine readable form:

And I've also worked on the 0hd recipes. With 4+1 recipes and blocks as elbows it was coming out at around 6.5gp per glider. Last night I computed the 4+1 recipes with blocks and beehives as elbows. Out of the four beehive/glider interactions that destroy the beehive, only one of them is slow enough to be hit by a following glider on the same lane. That means that (up to reflection) there are four block elbows A, ..., D and ten hive elbows E, ..., N. All the code is up on github. The actual recipes are attached here:

I just ran the gp-compiler on the above slow salvo recipe and it came out at roughly 5.3 gp/glider. The trouble is that there is a collision somewhere at the "blocks and boats" stage of the recipe. This is actually more fortunate than anything I saw with only blocks: previously I always had collisions at the other end of the recipe too. Here is the code that produces the sample recipe:

But maybe it is worth computing the elbow recipes at some higher depth? I'm not sure I have the willpower personally. For anyone wishing to compile the recipe on their own machine note that the values on this line are designed so that the above slow salvo recipe starts with an elbow block that is in the correct place for the block that is left by the eater + blocks recipe in the first code block (unless I made a mistake of course).

If anyone can get a working recipe that has no collisions, the next step will be to add an elbow move that shifts from the final elbow of the recipe to the initial elbow for the eater + blocks recipe. That can be done with another script that I made. It's not very user friendly (standalone Python with the elbow move to be specified via command line argument) but it works.

EDIT: Oh, yeah. If anyone wants to diagnose the which operation is responsible for the collision in the above recipe, here is the list of elbow operations:

chris_c wrote:First of all I've made a 0hd recipe for the near construction lane stuff. I used a slightly different method to suppress the unwanted glider: dropping a block directly from the construction lane just behind the eater. The recipe was constructed with copy/paste and so we will eventually need a script to turn this back into machine readable form...That means we can use the slow salvo recipe exactly as it was in the 10hd case. It's 540 gliders...

That looks a little better than my solution. Okay, here's the back-translation:

[At some point I should really clean up that pattern-script code -- these copy-and-paste scripts include all kinds of outdated junk... On the other hand, maybe if I don't fiddle around with it too much, it will keep working.]

Just for the record, here's the code I wrote to do the back-translation:

chris_c wrote:EDIT: Oh, yeah. If anyone wants to diagnose the which operation is responsible for the collision in the above recipe, here is the list of elbow operations...

That's a lot of recipes. I wonder how much more efficient these 0hd constructions could get with even more elbow types. Honeyfarms seem like they'd be good candidates. Maybe even traffic lights and blinkers, if the parity issues don't end up being too much trouble.

The trouble is caused by one of the Cr K: o20 o56 operations. That recipe gets used quite a bit, so I'll try to replace it only when it causes a problem. Further bulletins as events warrant --

This is the first UC example with non spartan circuitry, and although some doubts it looks like eater2 is now solid part of the self constructing circuitry together with other less common SLs.

Thanks! It's nice to get another working example, anyway. There are quite a few more efficiency improvements possible here, but I think these tools are good enough to build -- for example -- the slightly more complicated switching circuitry needed for a quadratic-growth replicator.

The eater2 and other non-Spartan still lifes were pretty expensive compared to all the Spartan objects, but since they enabled a factor of three improvement in the signal compression they were clearly worth the investment -- assuming we were optimizing period or bounding box. If population or Golly execution speed (or design-plus-construction time!) were the only things that mattered, a pure Spartan version would probably still be competitive.

Maybe the next item on the agenda should be a slow-salvo compiler script that knows a lot of recipes for small objects. Adding compiler support for non-Spartan objects like the hive-with-tail or eater2 is just a matter of adding more recipes to the compiler's library. If some particular orientation isn't known, or if the reaction envelope of the recipe doesn't match the constraints of the pattern being compiled, then that recipe won't be used.

I'll be interested to see how this current 10hd Demonoid design measures up against a 0hd version. And against a p120 or p240 "carrier signal" model -- that idea really does seem like it has a lot of potential. The startup problem seems fairly trivial: the first glider on the non-carrier lane would knock out an eater, using an additional still life if necessary. Shutdown is trickier but can be done fairly easily -- an eater seed could be triggered to catch any unwanted gliders, but with the right timing of the self-destruct circuit all the gliders will get used.

In particular, the new trigger method for the self-destruct sequence -- a completely independent glider following the main recipe on a different lane -- means that the timing of the destruction can be trivially adjusted to hit exactly the right phase of the right cycle of the p120 gun.

dvgrn wrote:Honeyfarms seem like they'd be good candidates. Maybe even traffic lights and blinkers, if the parity issues don't end up being too much trouble.

I have added honey farms as targets and updated the 0hd recipe book. It adds approximately 1,500 recipes, taking the total to over 3,500. I haven't run the gp-compiler with the new recipes except with lookahead depth = 1 to test that things are working correctly.

Accepting P2 targets is something that should definitely give more of an improvement. I have thought about it quite a lot but I'm quite daunted by the details. It wouldn't be much trouble to compute recipes to move P2 objects up and down the construction lane but the annoying thing is that the period of the output gliders are fixed unless you happen to find a P1 intermediate target on the way. Sorting this out seems like more mess than I would like to deal with.

dvgrn wrote:The trouble is caused by one of the Cr K: o20 o56 operations. That recipe gets used quite a bit, so I'll try to replace it only when it causes a problem.

Well, good luck. This is another problem I have though about quite a lot... and still haven't thought of a satisfactory solution that is easy to code.

chris_c wrote:I have added honey farms as targets and updated the 0hd recipe book. It adds approximately 1,500 recipes, taking the total to over 3,500.

Thanks for doing this! I haven't been as lucky this time around as I was in recompiling the original Demonoid recipe, where removing a particularly sparky recipe and recompiling at a different depth happened to solve the only construction conflict, fairly quickly.

This time around I've taken out several recipes, one at a time, but so far another problem recipe has always been chosen to replace the old one. I've been playing around with other possible ways to dodge the problem, but haven't had a lot of time to spend on it this week.

I'll try compiling with the honeyfarm recipes and see if it happens to get past the boats-and-blocks construction. It's much easier to make small changes to the compiler and re-run it a few times with my fingers crossed, than to go in and rebuild pieces of the gp-recipe by hand...!

EDIT: No luck with recipes-including-honeyfarm-elbows at depth 8 -- there are still conflicts in two places, one requiring the elbow to be one step farther away (toward the beginning) and one needing two diagonal steps more clearance (in the usual blocks-and-boats section at the end). But the efficiency ratio has continued to improve:

@depth8: 2678gp / 540g = 4.959259@depth12: 2668gp / 540g = 4.940741

chris_c wrote:Accepting P2 targets is something that should definitely give more of an improvement. I have thought about it quite a lot but I'm quite daunted by the details. It wouldn't be much trouble to compute recipes to move P2 objects up and down the construction lane but the annoying thing is that the period of the output gliders are fixed unless you happen to find a P1 intermediate target on the way.

One possible approach might be to register the two phases of blinkers, toads, beacons and so on as completely separate objects. The search algorithm would have to give up on the idea that it's always possible to exchange "e" and "o" in a glider recipe to get the opposite phase of output glider. For stable targets you could always do that, but maybe the two versions of the recipe could be listed separately in the library instead of being generated on the fly.

For p2 elbow targets, that symmetry wouldn't be available, but presumably there would still be a variety of glider outputs on a variety of different lanes. If one of those happens to line up with the next lane needed in the slow salvo recipe, then you're ahead of the game.

The odds of success might be cut in half, more or less, compared to starting from stable elbow targets, but blinkers in particular are common enough that they'll probably still increase the overall efficiency.

Also, there are a couple of details we've never tried to address in our slow-salvo encoding format. For a fair percentage of gliders, the output phase doesn't actually matter. The glider hits a stable object, and the result is a stable object. A p2 elbow would work fine for that case.

Maybe at the same time it would be worth addressing the fact that gliders that do cleanup, like deleting a block, have many available lanes as well as available phases. A recipe format that listed all the permissible lane and parity options for each glider would allow a compiler to find a significantly more efficient solution.

Maybe it's best not to go farther than that. But it's also true that slow-salvo gliders can very often be sent in many different orders to produce the same result, and that some orders can presumably be built more efficiently than others. That's a little harder to come up with a readable format for, or even to find all the possible options. It would be a nice problem for Someone to tackle Sometime, as the saying goes.

chris_c wrote:This is another problem I have though about quite a lot... and still haven't thought of a satisfactory solution that is easy to code.

One rather brute-force-ish solution might be to actually test each newly assigned gp-recipe in the context of the construction it's supposed to be doing. If the same pattern results when the hand block is in its correct starting position, as when it's moved some distance diagonally farther from the construction lanes, then there's no interference and the new assignment can be accepted.

When a difference is found, the coding definitely gets more annoying. At that point it would probably be worth doing a similar compatibility test on all the branches that can be followed from the current elbow -- i.e., all gp-recipes with that elbow as a starting point. Then only gp-recipes that don't interfere with the construction would be used in that step of the search.

Basically that would amount to compiling a custom library for any step of the search where a conflict is seen. The search would work at very close to its current speed as long as no conflict shows up.

-- Any pointers as to whether and how the current search code might be modified to use a different library whenever some conditions are met? E.g., number of glider pairs is between N1 and N2 (I'll go find the specific numbers later)?

dvgrn wrote:EDIT: No luck with recipes-including-honeyfarm-elbows at depth 8 -- there are still conflicts in two places, one requiring the elbow to be one step farther away (toward the beginning) and one needing two diagonal steps more clearance (in the usual blocks-and-boats section at the end). But the efficiency ratio has continued to improve:

@depth8: 2678gp / 540g = 4.959259@depth12: 2668gp / 540g = 4.940741

Finally got a depth3 search to complete without conflicts, using a dodgy hacked version of the search script. @chris_c, thanks for contributing the necessary changes, unless you consider them too embarrassing to publish, in which case I did them all myself.

I'll probably keep wrestling with this problem until I've gotten the cost back down under 5gp/g. Might take another week or so. A depth-6 search already has a fairly nice ratio -- 2706gp / 540g = 5.011111 -- but it breaks in several places in the boats-and-blocks construction. Will probably recompile at something like depth 15, and then just patch in the depth-3 solution for the blocks-and-boats part at the end, unless a lucky nonconflicting recipe shows up at a greater depth.

-- Of course the only problem is that it takes too long to figure out which specific recipes to forbid, when compiling the full recipe at greater depths. It's fairly easy to compile, test, and recompile just blocks-and-boats at a greater depth, starting from a known elbow that's part of an efficient high-depth recipe -- then patch the two partial recipes together. Maybe I'll do something along those lines.

Here's the version of the dodgy hacked search script that successfully found the depth-3 solution. It expects the input recipe to be either in the clipboard or in a file called recipe.txt (but you can type in another filename).

# Uncommment to use only central blocks as elbow# if tokens[i+2].count("A") != 2:# continue

cost = s.count("e") + s.count("o")

for c in "RL": if side is None or side == c: recipes[elbow_in].append((elbow_out, move, lane, cost)) recipe_strings[(elbow_in, elbow_out, move, lane)] = recipe_string if description_string in dodgy_bits: for lane_num in dodgy_bits[description_string]: lanes[lane_num][1].append((elbow_out, move, lane, cost))

def is_recipe(s): if ":" in s: parts=s.rstrip().split(":") if len(parts)>2: return False s=parts[1] ###### Other malformatted data is still possible, but if there aren't any nonconforming ###### characters on the clipboard, the odds are quite good that it's really a recipe return all(c in "0123456789- EO" for c in s)

rfile=g.getstring("Enter name of glider-pair recipe library to use\n(same directory as script):",RECIPE_FILE)

dvgrn wrote:-- Of course the only problem is that it takes too long to figure out which specific recipes to forbid, when compiling the full recipe at greater depths. It's fairly easy to compile, test, and recompile just blocks-and-boats at a greater depth, starting from a known elbow that's part of an efficient high-depth recipe -- then patch the two partial recipes together. Maybe I'll do something along those lines.

Yes, I've been having a go at this problem and that is the approach that I took. I ended up with a fully integrated 2744gp solution. The searches were based on lookahead depth 8 and I ended up setting checkpoints after 470 gliders and 530 gliders to speed things up. This ended up being my list of "dodgy_bits". Also there is a slight change in the code to prevent certain elbow moves in the run up to a specific glider. The dodgy branch certainly justifies the name but once you get the hang of it it's not too horrendous to use.

By chopping off some glider pairs from the front and putting them back at the end I managed to make the initial elbow a fairly accessible beehive. This could be useful if we want to make a gun. Here is the recipe embedded into a 0hd-recipe building script:

chris_c wrote:I ended up with a fully integrated 2744gp solution...Are you happy to call it quits here and build the gun/spaceship?

Sure, anything under 2750 gliders is fine with me. (And if the number had been a little higher, I would have picked a slightly higher threshold.)

A depth-10 search with this library gives 2671 gliders, and a depth-12 search gives 2668g, so clearly your recipe is within a hundred gliders of the best we can do. I'm going to leave my laptop running on a depth-20 search over the weekend, since I'm traveling out of state anyway -- just to see what the limit is.

I probably won't have time until next week to work on a gun, but it should be pretty easy to adapt the current pattern script to work with the gun script pattern that I posted a while back. This design really doesn't have the headaches that the previous one did. If I get a moment tonight, I'll run the optimizer on this new recipe and see how tightly the glider pairs can be packed.

I made a 0hd-Demonoid gun of period 660 * 4 * 3^6 that shoots 0hd-Demonoids of period 660 * 3^6 (approx 480,000). It is based on two loop guns that feed the recipe into a fixed copy of the Demonoid and six fixed period guns that rebuild the elbow and hand and insert the destruction glider when necessary.

Also here is an optimised 0hd-Demonoid of period 438,852. I think the only way to make it smaller is by optimising the recipe or advancing certain glider pairs by one tick when the pattern is P2 but the effect of that glider pair is only P1 in nature.

chris_c wrote:I made a 0hd-Demonoid gun of period 660 * 4 * 3^6 that shoots 0hd-Demonoids of period 660 * 3^6 (approx 480,000)... Also here is an optimised 0hd-Demonoid of period 438,852.

Awesome! You're continuing your tradition from the centipede, Parallel HBK and HBK gun, of finding ways to patch together previous pieces to make something many times smaller than the previous model... It took longer than usual this time, though -- this is pretty tricky stuff. I don't think I'll be leaving my dark corner again for a while, myself.

Seems as if this 0hd model is just about as small and simple as it can get. I'll be really interested to see if one of simsim314's carrier-signal designs can significantly improve on the size or the period. I'd guess that the next big improvement in efficiency might come from a return to a two-arm constructor, like the original Gemini but with glider-pair recipes running the arms.

-- Anyway, so is this in fact the first new family of spaceships where a gun was built before the actual spaceship? Or did you do some spaceship tests before the gun was complete?

Over the weekend while I was traveling, my laptop finished a depth-20 search and came up with recipe that uses 2662 gliders, but hits a conflict in the boats+blocks construction as before. Very likely a slightly smaller Demonoid could be made by patching the end of the current 0hd recipe together with the beginning of this one:

dvgrn wrote:Awesome! You're continuing your tradition of finding ways to patch together previous pieces to make something many times smaller than the previous model.

Thanks! But none of this would have happened if you hadn't spent all that time working out the construction and destruction recipes. I think this area should be tackled before anyone tries something like this again. Also kudos to your idea of using 0hd construction arms which simplified the design a lot and ended up making a spaceship of nearly four times smaller period.

dvgrn wrote:-- Anyway, so is this in fact the first new family of spaceships where a gun was built before the actual spaceship? Or did you do some spaceship tests before the gun was complete?

Yes, I resisted the temptation to do any standalone flight-testing. The first spaceship was constructed by the gun.

dvgrn wrote:Over the weekend while I was traveling, my laptop finished a depth-20 search and came up with recipe that uses 2662 gliders, but hits a conflict in the boats+blocks construction as before. Very likely a slightly smaller Demonoid could be made by patching the end of the current 0hd recipe together with the beginning of this one.

I patched in the old recipe somewhere near the start of the blocks and boats stage. It saves 15 gliders compared to the old recipe. The annoying thing is that there is a conflict with a boat from the previous stage at around generation 489,000 when you run the script below. Fixing this should yield a design that is roughly 2,400 ticks faster if anyone has the motivation to do so.

This construction method seems reasonably appropriate, constructing the Demonoid with more or less the same methods that it will use to construct its next descendant. This particular timing was really lucky -- the two glider streams at the bottom pass right through each other with no conflicts. Other periods would have caused a lot more trouble, maybe needing a temporary reflector or some such horrible thing.

Probably the job could be done in something under 11,000 gliders, by constructing the two initial reflector/edge shooters using a conventional construction with gliders from all four directions, instead of two slow salvos. E.g., compile with Calcyman's Gemini-recipe compiler script, suitably amended to include recipes for a few more still life types.

What's the minimum again, exactly?I suppose that technically the construction can be done in something under ten thousand gliders, by constructing a sliding-block decoder and programming it appropriately. I wouldn't want to actually figure out the required seed constellation that would produce a Demonoid, but it could clearly be done. In fact it wouldn't be all that hard to write a script to automatically compile a stable seed for any unidirectional glider stream.

It would be great to be able to say, "No glider-constructible object needs more than N gliders to construct", and actually have a specific maximum value for N. A glider synthesis for any working sliding-block decoder, plus a small construction-arm circuit to connect it to, is all that's needed to find an upper bound for N. The decoder might need a little more optimization before anyone tries to synthesize it, though...!

Boustrophedonic Is Bad, Unreflected Is UnbeatableNotice how quickly Golly can handle the slow-salvo constructions, early on in the above Demonoid recipe. The next trick is going to be to set up some kind of Geminoid self-replicator that never folds any streams of gliders back on themselves. That really seems like the only thing that's holding Golly back.

A diamond-shaped design should be pretty good, but is there something better? I get vague pictures of long streams of gliders zipping around in a mostly empty grid with small reflectors scattered here and there, and occasionally maybe two streams run themselves through signal splitters and work together to build something else at the edge of the construction area.

Mad Metacell MusingsIt might be interesting to revisit Calcyman's old idea of a self-constructing metacell, with all this new technology in mind. The key idea is that the OFF meta-state would be simply empty space, and the ON meta-state would be a replicator, which contributes a copy of itself to any neighbor location that needs to turn ON in the next meta-tick.

We can build things with 0hd glider streams now, or with *WSS streams interacting with glider streams, or by sending out a loafer or Cordership and following it with a faster ship, or with "armless" designs that can produce output gliders across a really wide area. Do any of these mechanisms make a self-constructing metacell vaguely feasible?

It could be a metacell that could be programmed to emulate different rules, or it could be limited to one specific rule -- as long as it was a good enough rule! For example, a self-constructing B3/S23 metacell could be set up for quadratic growth simply by building a meta-spacefiller... and every known spaceship would become the beginning of an infinite series of new spaceships with progressively slower meta-velocities.

We can use a data tape made of loafers... Then the glider elbow can build a 2c/5 or c/3 ship which will pass the loafer stream. For a long time after this would just be waiting for it to get fairly far. Then the glider elbow can start firing slow LWSS salvos , which will convert the slightly slower ship sent earlier into a target and start building the next unit. Or we could use the bait ship as part of a super efficient but very long INC operation in some way so that elbow and bait are set up at the proper distances very far away, then use glider salvos.

By the time the next unit is built, the loafers have only just caught up.

It would definitely be much more complex in terms of circuitry, but maybe it could allow for a U.C. based ship where HashLife doesn't get bogged down by all the nearby streams moving relative to one another...

On the other hand, the data tape is still necessarily eventually moving in the same direction as the construction tape, so it might be a bit tricky to make it pay off...

It's a nice article but your name is conspicuously absent from the list of "discoverers". I definitely consider both ships to be a joint endeavour even though I did work pretty hard on the 0hd-Demonoid last weekend just so I could get it out of the way and think about something else! If someone with good wiki-editing skills can update the article to better reflect Dave's contribution it would be appreciated.

chris_c wrote:It's a nice article but your name is conspicuously absent from the list of "discoverers". I definitely consider both ships to be a joint endeavour even though I did work pretty hard on the 0hd-Demonoid last weekend just so I could get it out of the way and think about something else!

Well, it's easy enough to add a second discoverer. But I set it up that way on purpose, very similar to the ownership of the shield bug vs. the centipede, or the half-baked knightship vs. the Parallel HBK.

I did a little work on the 0hd Demonoid, but almost none of it was actually used in the final version. As far as I can see, I just contributed the initial 0hd idea, and I guess maybe the idea of adding honeyfarm elbows. Wild ideas don't require very much attribution, in my book -- the hard work was all in the script-writing and actually patching all the details together.

Now, the previous 10hd Demonoid was definitely a joint effort -- and it's listed as such in the first table in the Spaceships article on the LifeWiki. Yes, the 0hd Demonoid uses "my" TileA construction recipe, but that comes straight out of the 10hd Demonoid, so that's where that attribution belongs (in my opinion).

Not to worry, there's no shortage of links in the Demonoid article where my name shows up. I just added an "in collaboration with" phrase here and there, if that's any help.

If anyone wants to do some good Wiki-updating, I'd suggest that it would be much more appropriate to invest some time to fix the redlinks for "Chris Cain" and "Paul Chapman". Paul's contribution to the Demonoid was a really big one, just delayed by a couple of years. I'd have been sunk without the Seeds of Destruction Game, as patched up by Sphenocorona, to figure out a semi-decent solution for the TileA self-destruct circuitry. With the SODGame it was really fairly quick and easy.

Speaking of which, I should mention a recent email communication with Paul:

igblan wrote:I'm delighted that SOD played a part. And more even that it's been fixed and continues to live on with other folks' support. Pass on my thanks.