Miscellaneous topics in Conway's Game of Life -- unfinished projects of all kinds and conditions

10 November 2018

New Tools for Self-Construction

Time for a new post on self-constructing circuitry! I've been updating the same old post since 2014, but I think there's now some news that warrants a new article.

Self-Construction Just Got A Lot Easier

For the last several years Adam P. Goucher has been incrementally working out the construction details for a "0E0P metacell". A metacell is a piece of Life circuitry that simulates the behavior of a single cell in Life, or in many cases some other CA rule, depending on how it's programmed.

"0E0P" is short for "[state] zero equals zero population", meaning that no support circuitry is needed: when one of these 0E0P metacells turns off, it self-destructs completely! This means that when the metacell needs to turn back on again, it must be re-constructed from the ground up by its neighbors.

One of the important effects of this design is that metacell patterns run at a sufficiently high step size, when viewed from very far away (e.g., at a size where an entire metacell takes up a single pixel in the display) will be indistinguishable from normal patterns that use the same rule -- except that the metacell patterns will run 2^36 times more slowly, of course.

Automatically Generated Construction Recipes

A key breakthrough enabling the construction of the 0E0P metacell was a publicly available search program written by Goucher, capable of finding a single-channel construction recipe for any constellation of still lifes -- provided the still lifes aren't too close together, and that recipes are known for each of them in isolation. This search program was originally called "slmake" but is now renamed to "slsparse" due to its ability to analyze a large constellation and automatically separate it into several well-separated sub-constellations, or "metaclusters" (when that's possible).

The first few self-constructing patterns -- Gemini, 10hd and 0hd Demonoids, linear propagator, and the first spiral-growth pattern -- all had slow-salvo recipes that were mostly compiled by hand. This was usually one of the most time-consuming parts of the construction process, and once a recipe was compiled it was often very difficult to make small adjustments to the design without recompiling everything from the ground up. Now that slsparse is available, it's much easier to produce new pattern variants and entirely new designs.

Here are three recently completed self-constructing spaceships that owe their existence to compilation with slsparse -- with images of each, since for a change they all look like something other than plain long straight lines from a distance.

Fast HashLife-friendly Orthogonoid

Older version with slow elbow push:

Lower-population version with Cordership elbow push:

The older Orthogonoid has a fairly continuous recipe, so it's a little easier to see what direction it's going. The newer recipe consists mostly of long gaps between gliders, waiting for Corderships to reach their target locations.
  • The blue arrow marks a slow salvo that has almost caught up with a three-engine Cordership, which it will convert into the main body of Orthogonoid circuitry.
  • The purple arrow marks a single-channel salvo just starting the long trip after a two-engine Cordership, which it will convert into an elbow block and then create the seed for a new three-engine Cordership heading at right angles to the first, to the northwest.
  • The green arrows show the direction the recipe travels.
  • The red arrows on the west side show the future path of an MWSS and glider that do the cleanup of previous circuitry that's no longer in use. The MWSS is constructed by the short segment of single-channel recipe that is just reaching the elbow ahead of the leftmost green arrow; it's a copy of a short final section of the last largest segment of the recipe.

Features of slsparse used to build the new Orthognoid include

  • automatic compilation of very widely separated metaclusters

    This allows the MWSS-to-glider circuit to be moved a long distance from the glider-to-MWSS circuit, which allows the structure of the spaceship to be much more visible from a distance -- and incidentally reduces the number of required hashtiles enough that Golly can now "run away" with the pattern.

  • automatically compiled elbow push and hand push, with different Corderships

    For historical reasons, slsparse currently uses 3-engine Corderships to move "hand" target blocks long distances at right angles to the construction lane. The more recently discovered two-engine Corderships are used to push elbow blocks long distances along the construction lane.

  • automatically compiled non-Spartan objects

    There's lots more available than the old standard Spartan still lifes -- even without counting the bespoke object collection, which allows for the construction of extra-difficult and extra-useful structures such as syringes and Snarks. For example, an aircraft carrier used to change a glider's color as part of the elbow Snark's self-destruct circuitry. This isn't strictly Spartan, but with slsparse the state of the art has moved well past that artificial limitation.

Hashlife-friendly Demonoid

(The image at right is not exactly to scale, but it's close enough that it should be recognizable.)

Features of slsparse that appear in the new Demonoid include

  • long-distance elbow pull

    A counterpart to the 2-engine Cordership push is a long-distance elbow pull recipe, also recently added to slsparse. A faraway elbow is converted to a return glider, which allows for much quicker movement toward the recipe source than would be possible with a long series of classical elbow-block PULL operations.

  • Snarkbreaker

    slsparse now knows a single-channel recipe that can add an additional lossless elbow to a construction arm -- a "Snarkmaker" -- and another recipe that can remove the added Snark when it is no longer needed ("Snarkbreaker"). This allows a single-channel arm to safely reach locations that are otherwise inaccessible, such as a construction area that overlaps the single-channel lane.

The above recipes were actually compiled by hand into the current HashLife-friendly Demonoid, because the relevant features hadn't been added to slsparse yet. The long-distance Cordership elbow push had also not been added yet, so the elbow movement was done inefficiently with a long series of PUSH operations, which accounts for a large fraction of the gliders needed in the recipe.

Challenge: Install the latest slsparse and use it to build a lower-population Demonoid than the current model, with wider separation (but still a power of two, to keep HashLife happy!) between the back-and-forth glider streams. Reasonably up-to-date installation and usage instructions can be found in this walkthrough on the LifeWiki.


In this Demonoid design, only the Snarkbreaker is needed, and at the moment slsparse doesn't know how to do a Snarkbreaker without a matching Snarkmaker preceding it (see below). So the Snarkbreaker was added into the Demonoid recipe by hand after the compilation was completed.

Another trick used in the Demonoid that slsparse doesn't know about yet is

  • destruction of old circuitry by *WSS produced directly from construction elbow

  • This destruction method is much more efficient than bending the construction arm around two 90-degree corners to reach the location of the old circuitry. At the moment slsparse is primarily concerned with construction and not destruction.


Features of slsparse used in building the loopship:

  • automatically compiled on-lane construction

    For the largest metacluster, slsparse automatically sends two Snarkmakers to move the construction arm sideways to a safe distance to complete the construction -- followed by two Snarkbreakers to return the arm to its original state.

A new feature of slsparse that could be used to build a somewhat smaller loopship:

  • automatically compiled 0-degree construction for sufficiently narrow on-lane constellations

    The largest metacluster is actually narrow enough that some reconfiguration of one-time turners could allow the entire constellation to be constructed directly by 0-degree gliders, with no Snarkmaker/Snarkbreaker combinations necessary.

Other mechanisms used in the loopship

  • destruction by GoL-destroy search result

    A separate search program called GoL-destroy written by Simon Ekström finds ways to interleave random still lifes into signal circuitry, out of the way of the actual signal paths, in such a way that the entire structure collapses cleanly down to zero population when it is hit by a single self-destruct signal. slsparse can compile these additional still lifes just as easily as the original circuitry.

  • one-time turners

    A few classical one-time converters -- glider to MWSS, MWSS to glider, and glider to 2 glider -- were also included in the design, just for variety, though they're probably slightly less efficient than the best solution that a GoL-destroy search could come up with.
The loopship's recipe gliders traverse parts of their path three times in a row, and some of those gliders (or rather a copy of them) travel the exact same path a fourth time, ahead of the full recipe. This happens along the zigzag central spine of the loopship.

A "working copy" of the recipe is split off from each loop to do the actual construction. The working copy first builds two Corderships and sends them off at 90 degrees to the left and right, to the next new loopship corners. After the necessary long pause, it follows those Cordership with cleanup salvos.

After that, the remainder of the working copy builds two temporary lossless elbows (Snarks) and constructs the biggest part of the loopship circuitry, which is a Scorbie Splitter combined with two Snark reflectors plus self-destruct circuitry. As the spaceship travels, a copy of this circuitry will appear at each 90-degree bend along the central spine.

An accurate diagram would show all these paths stacked exactly on top of each other, like the illustration at left.

However, it may be easier to visualize what's happening in the loopship, with a diagram has successive traverses offset slightly, as shown at right.

The above diagrams represent one full period of the loopship, made up of two mirror-image half periods. Adding another half period would look something like this:

The actual loopship has significantly different shapes at different times in its construction cycle. Here's a snapshot diagram where

  • the two Corderships (orange dots) are each in the process of being chased down by a salvo of zero-degree gliders. The southeast salvo will convert the Cordership's leftover debris into a Snark, and the northwest salvo will reduce that Cordership to a single block.

  • the remainder of the recipe traveling northeast will construct a new splitter-plus-Snarks constellation (a future blue dot halfway between the two Corderships).
  • a copy of the full recipe is heading southwest around the left-hand loop (green arrows).

  • a cleanup MWSS and glider (red dots) have almost reached the splitter-plus-Snark (blue dot) and Snark (purple dot) to the south, which are no longer in use.

The Switching System

There are a few details of the loopship's operation that aren't covered by the diagram. In particular, an extra signal makes its way around the loop twice, following a chain of one-time turners. This is what triggers the two self-destruct signals, and also turns off one of the branches of each Scorbie Splitter so that the full recipe doesn't get copied again, to attempt a second disastrous trip around the delay loop.

Final Challenges

The loopship is considerably bigger than it needs to be... and making it smaller requires only one minor adjustment to the recipe. It's quite possible to make this change without doing any recompiling with slsparse. Details of some open problems are posted on the loopship forum thread.

16 June 2018

Fixed Cost Glider Construction, Part II

Design Summary for Fixed-Cost Glider Construction

The previous post summarized the new 329-glider reverse caber tosser universal constructor design, but didn't go into detail about what exactly makes the design universal. Here are (most of) the fiddly details, some of which are already out of date now that a universal construction method has been found with as few as 35 gliders. See this conwaylife.com forum posting for a high-level walkthrough of how the 35-glider recipe might work.

The "reverse caber tosser" idea, with two gliders reflected back 180 degrees by a Cordership (or Corderpuffer, anyway) still remains intact -- and so does the three-glider PUSH/DFIRE salvo and the idea of using a block-laying switch engine as a source of elbow blocks. However, all of the PUSH/DFIRE salvos are now produced by glider-producing switch engines. These various switch engines are almost the only things that need to be constructed. In the 50-glider UC model, no stationary circuitry is needed at all. The 35-glider model needs a single block as a catalyst, to cleanly generate a return glider to retrieve the next bit from the approaching Corderpuffer.

The idea of a fixed-cost glider recipe for any possible glider-constructible object has gone through several iterations in the past few years. The first completed construction was a decoder that used a double sliding-block memory, and repeatedly divided the stored number by two or three, returning the remainder for each cycle. That information could then be used to run a construction arm. However, an explicit construction arm was never created for that design.

A newer "reverse caber tosser" design is an alternate storage mechanism for data feeding a universal constructor. The reverse caber tosser was designed by Adam P. Goucher, with Martin Grant finding the key glider-reflection reaction. A very large integer can be encoded in the position of a very faraway Cordership (instead of a block). If the distance to the Cordership is measured using circuitry designed to be as simple as possible, a complete decoder and universal constructor can be created by colliding exactly 329 gliders.

Normally a construction arm has at least four possible "elbow operations": PULL and PUSH to change the location of the elbow, and two different FIRE recipes to produce either of the two possible glider colors.

The first simplification for the reverse caber tosser is the use of only one color of output glider. This limits the output to monochromatic single-parity slow salvos (see below) but significantly simplifies the circuitry.

Usually FIRE operations also leave an elbow behind for the next elbow operation to make use of. The second simplification in the decoder design is to use up an elbow with every FIRE operation.

This makes construction recipes very much less efficient, because each new output glider needs a fresh elbow block to be pulled in from "elbow storage" (a line of blocks created by a block-laying switch engine) before the DFIRE (destructive fire) operation can be sent. As the number of output gliders increases, the pull distance increases proportionally, making the recipe progressively less efficient.

However, once again in this case, using up elbows makes the decoder mechanism significantly simpler, and that's the only kind of efficiency that matters from the point of view of reducing the total cost of the construction. The PULL and DFIRE combined salvo needs only three synchronized gliders. It appears that including an elbow-preserving FIRE option would require four gliders or more, with a correspondingly larger amount of circuitry that would then have to be constructed by the initial glider recipe.

Summary of required parts and mechanisms

  • The glider recipe builds the decoder/constructor plus a very faraway Cordership.
  • The recipe also builds a block-laying switch engine as a source of elbow blocks for the constructor arm.
  • Two gliders are sent toward the Cordership.
  • When they reach the Cordership, they are reflected 180 degrees and head back toward the decoder.
  • The two return gliders may reach the decoder at two possible timings (mod 256). Let's call these two timings "PULL" and "DFIRE".
  • Changing the position of the Cordership allows a free choice of "PULL" or "DFIRE" timings, for each of N sets of return gliders.
  • Adding another bit to the data stored in the Cordership's position requires increasing the Cordership's distance from the decoder by roughly a factor of two.
  • The return gliders always interrupt a suppressing glider stream, allowing a construction-arm shotgun to send a two-glider salvo southeast to the block-laying switch engine.
  • The two-glider salvo is the same one used in many previous construction arms including the Gemini spaceship.
  • When the salvo strikes a block -- an "elbow" of the construction arm -- the block moves forward by one diagonal.
  • If the gliders have the "DFIRE" timing, a third glider is also released, which destroys the elbow block but releases a sideways glider.
  • Because the block is used up, this is a "destructive FIRE" elbow operation, instead of the more normal "FIRE" which preserves the elbow.
  • "PULL" and "DFIRE" operations, when combined with an unlimited supply of elbow blocks, allow a series of same-color gliders to be released successively on any set of chosen lanes.
  • The gliders will all have the same phase, so this is a "monochromatic single-parity slow salvo".
  • It has been shown that monochromatic monoparity slow salvos are capable of constructing any pattern that can be constructed by colliding gliders together.

More recent fixed-cost construction designs include the proposal that the Cordership should be replaced with a c/12 puffer that is cheaper to synthesize -- 7 gliders instead of 9. This leaves a much larger mess to clean up, but it's still doable... and reducing the initial cost is the only thing that matters for this particular project.

The Cordership, or puffer, eventually generates its last bit and comes to a crashing halt. In the sample pattern shown in the previous post, the block that the Cordership/puffer crashes into is generated by two loafers, to make it clear that this block is a placeholder, not an official part of the initial glider construction! In the actual construction process, that block would be built by the construction arm, according to PULL and DFIRE instructions coming from the Cordership/puffer.

The construction arm also has to build a number of other "maintenance mechanisms":

  • a large structure made up of one-time glider splitters and glider turners, with four parts:
    1. a one-time circuit producing two gliders that stop the receding block-laying switch engine without releasing any gliders
    2. a one-time circuit producing a slow salvo of many gliders aimed at the ash from the stopped switch engine, rebuilding it into a clean one-time-use specialized Cordership eater
    3. a one-time circuit producing a specialized Cordership able to remove unused blocks from the block-laying switch engine's ash trail
    4. a one-time circuit producing a "meteor shower" slow salvo that completely cleans up the entire decoder/constructor mechanism.
  • a secondary "slow elbow" block at a safe distance from the construction arm (generated by colliding a series of monochromatic gliders into some of the block-laying switch engine's leftover ash).
  • a "hand block" to provide the construction arm with a usable target for incremental constructions

All of the above are necessary only if the pattern must be built with the absolute minimum of 329 gliders. If a larger number of gliders is allowed, on the rough order of 1000, then all this cleanup can be accomplished by adding gliders to the initial recipe instead. The resulting complete pattern would be many orders of magnitude smaller, though still very large. It might include several hundred more gliders in the initial recipe, but would be considerably more efficient at completing constructions.

For example, a more expensive Cordership-based block puffer could be constructed, and then could be shot down with gliders after it has produced exactly the right number of blocks. This would completely avoid any need to build the complex structures outlined in #1 through #3 above.

Similarly, building the "slow elbow" block as part of the construction recipe would cost only one or two gliders more than the minimum, but would reduce the size of the final pattern by a hundred or more orders of magnitude. That's not just a reduction by a factor of a hundred -- it's a factor of a googol, 10^100, and that's just a bare-minimum estimate. An even larger size reduction would result from adding two gliders to build the block that stops the incoming Cordership (the one built by loafers in the sample pattern).

When the constructor is in operation, it builds a series of one-time turners. The recipes are all monochromatic slow salvos. The purpose of the one-time turners is to to aim gliders at the hand block. These one-time turners fall into one of four categories, since they may change the parity and/or the color of the output glider relative to the input glider. This allows the "slow elbow" to convert a monochromatic single-parity slow salvo into a standard "P2 slow" salvo where the gliders may be either parity and either color.

13 June 2018

The Answer to Life's Ultimate Question is 42 -- But the Cost of Living is Capped at 329...59...58...50...44... 43... 35...32...17

Code: Select all
#C universal constructor based on reverse caber tosser
#C Completed 10 June 2018
#C Original design by Adam P. Goucher
#C Original glider synthesis by Goldtiger997
x = 5379, y = 5173, rule = B3/S23
#C [[ WIDTH 592 HEIGHT 500 X 5 Y -60 PAUSE 2 AUTOSTART ]]
#C [[ T 800 STEP 5 ]]
#C [[ T 2500 GPS 60 X 410 Y 456 Z 2 ]]
#C [[ T 2600 STEP 4 ]]
#C [[ T 2700 STEP 3 ]]
#C [[ T 2800 STEP 2 ]]
#C [[ T 2900 STEP 1 ]]
#C [[ T 3000 STEP 2 ]]
#C [[ T 3100 STEP 3 ]]
#C [[ T 3200 STEP 4 ]]
#C [[ T 3300 STEP 5 ]]
#C [[ T 7850 GPS 60 STEP 50 X 555 Y 628 Z -1.5 ]]
#C [[ T 28000 X 225 Y 300 Z -4 ]]
#C [[ PAUSE 5 LOOP 28050 ]]
There has been speculation for at least a couple of years** about the simplest possible form of universal constructor, where an arbitrarily complex construction recipe is encoded in the position of a single faraway object. The position of the object is measured by the simplest possible decoder mechanism, resulting in a series of bits that can then be interpreted to produce a slow salvo.
It has already been shown that slow salvos can construct any pattern that is constructible by gliders. So with the correct placement of the faraway object, the complete pattern is capable of building any possible glider-constructible pattern of any size. The same pattern is also capable of building a self-destruct mechanism that completely removes all trace of the universal constructor, after its work is done -- leaving only the constructed pattern and nothing else. A counterintuitive consequence is that any glider-constructible object, no matter what size, can be built with a specific fixed number of gliders.
And now the actual number has been calculated, and it's surprisingly small. The initial upper limit was 329 gliders, based on the pattern shown above. This has since been reduced several times, as indicated by the series of numbers in this article's title.
See the follow-up article for a full summary of the tasks that the universal constructor has to accomplish to be enable the 329-glider recipe to to construct any arbitrary pattern. The plans for the 58-, 43-, and 35-glider recipes are similar, but greatly simplified by the fact that the streams of gliders can all be generated by faraway glider-producing switch engines instead of local glider guns and reflectors. With the 58-glider recipe, no stationary circuitry is needed at all; a single block is needed as a catalyst in the 43- and 35-glider recipes.
** It seems likely that someone came up with this idea long before 2015 -- i.e., the inevitability of a fixed-cost construction with N gliders, for any possible glider-constructible object. Really it's more or less implied by the sliding-block memory units described in Winning Ways. But I don't know of anywhere that the fixed upper-limit cost of construction was mentioned explicitly. It would be interesting to see what early estimates of that upper limit might have been... it seems likely they were significantly higher than three digits, let alone two!
UPDATE 19 September 2020: Design improvements by MathAndCode and Adam P. Goucher make possible a reduced reverse caber tosser design requiring only 17 gliders, almost a 50% reduction from the previous fixed cost of 32 gliders.

10 March 2018

It Happened One Knight

On 6 March 2018 the first member of a new class of Conway's Life spaceships was discovered. This is Sir Robin, the first elementary spaceship that travels in an oblique direction. Its displacement is two cells horizontally and one cell vertically (or vice versa) every six generations, which is the fastest possible knightship speed. The name is a reference to Monty Python's "Brave Sir Robin", who bravely runs away as fast as possible.

Code: Select all
#C (2,1)c/6 knightship found by Adam P. Goucher,
#C based on a front end originally found by Josh Ball,
#C rediscovered and extended by Tomas Rokicki,
#C using a SAT solver-based search
x = 79, y = 31, rule = B3/S23

The new knightship was found by Adam P. Goucher based on initial results by Tom Rokicki, after about a month of automated searching. The program that completed the knightship was ikpx, a "multithreaded hybrid of LLS and gfind".

A detailed summary of the discovery process is now available.