Thread for basic questions

[pcallahan]

The closest thing we currently have to this kind of technology is the loopship, I think, but that takes glide-symmetry shortcuts again so it's not quite the same.

I don't think your link works, but I found it here. Very interesting. It runs much faster in Golly than Gemini.

I find it kind of hard to see the action. I tried watching a reflector at a fast enough speed to make progress (8^5), and but it's too fast to see when it's destroyed. It just disappears. One thing I like about Gemini is the deathstar-like construction of its copy. It's in no hurry. Time is on its side. But I guess in loopship, the gliders are the brain and the stationary parts can be built and erased very fast [edit: actually building takes many steps]. I need to think about that a little more. If I can figure out where it will build the next reflector, then it should be interesting to watch it happen.

And yes, I'm years behind on all this as I might have told you already. Giant constructor-based patterns never interested me much except to know they exist, since I don't have anything to contribute. Recently, though, I took another look while preparing a "show and tell" for coworkers and wanted to highlight new(ish) discoveries. Gemini is both very impressive and possible to explain without too much background. Loopship would have been tough.

Added: Now I see! Corderships. My Golly skills are fairly primitive, so to find this, i needed to watch for an elbow to appear. Zoom in. Memorize the coordinates, then restart the pattern and watch very carefully. I had assumed there was a glider collision to set up a stationary seed and wondered why LifeHistory showed no trace of a glider along an intersecting path.

Code: Select all

x = 106, y = 84, rule = B3/S23
5$bo$2bo$3o10$84b2o$84b2o7$92b2o$92b2o3$80b3o$80bobo$80bo2bo$81b3o$81b
3o$79bo2bo$82bo$79bo15b3o$94b4o$81bo12bo3bo$81bo12b2obo$79bo2bo11b2obo
$80b3o13bo$73bo6bobo$71bo2bo6b2o$71bo3bo20bobo$70bo4bo20bo2bo$70bo3b2o
20bobo$71bo2bo$72b2o$55b3o$48b2o4bo2bo$47bo2bo3bo3bo15bo$45bo4bo2bo4bo
13b2ob2o$44b6o4bobob2o14bo$43b2obo10bo$37bo2b2o2bobo15b2o$36bo8b2o15b
2o$36bo4bo$36bob2o15bobo$37b2o11b3o3bo$50bobo$50bo2bo$51b3o$51b3o$49bo
2bo$52bo$49bo15b3o$42b2o20b4o$42b2o7bo12bo3bo$51bo12b2obo$49bo2bo11b2o
bo$50b3o13bo$50bobo$51b2o$66bobo$66bo2bo$66bobo!

The conversion of this cordership collision (around generation 37 million) is fun to watch at a speed of 8^3, but it was no picnic to locate it.

[bibunsekibun]

Is it possible to build a PC equipped with a CPU that performs logical operations with CGoL?

[Gustone]

Is it possible to build a PC equipped with a CPU that performs logical operations with CGoL?

why

[dvgrn]

Added: Now I see! Corderships. My Golly skills are fairly primitive, so to find this, i needed to watch for an elbow to appear. Zoom in. Memorize the coordinates, then restart the pattern and watch very carefully...

The conversion of this cordership collision (around generation 37 million) is fun to watch at a speed of 8^3, but it was no picnic to locate it.

Primitive Golly skills, eh? Maybe you'll be in the market for the list of changes to Golly's defaults that I always recommend that everybody should make:

(1) most important: File > Preferences > View > uncheck "Reset/Undo will restore view". Suddenly you can go park over an area of interest, hit Ctrl+Z or Ctrl+R and re-run, and you don't stupidly lose your place in the pattern.

(2) change the step size under every algorithm from 8 to 2. This gives you much finer-grained speed control, at the price of having to tap + and - a little more often to accelerate or decelerate.

(3) check that your Alt+G, Alt+H, and Alt+J shortcuts are working -- they might not be mapped if you upgraded Golly according to the instructions (but I think nobody ever does that). Download Golly 4.0 if you don't have it yet. Alt+H switches to LifeHistory mode using a; for something like the loopship this quickly gives you a better sense of what's moving and where the action is happening. Alt+J switches you back to plain Life mode.

(Sometimes switching back via Ctrl+Z is better, though, depending on what you're doing. Generally once you've done item (1) above, hitting tab, Ctrl+Z and Shift+Ctrl+Z a bunch of times each will become your preferred method of stepping forward and backward through complex evolving patterns to see what's going on.)

[C28]

can this be made into a converter?

Code: Select all

x = 11, y = 15, rule = B3/S23
9bo$8bobo$8bobo$9bo8$b3o$b3o$obo$2o!

[dvgrn]

I don't think your link works, but I found it here. Very interesting. It runs much faster in Golly than Gemini.

I find it kind of hard to see the action. I tried watching a reflector at a fast enough speed to make progress (8^5), and but it's too fast to see when it's destroyed. It just disappears. One thing I like about Gemini is the deathstar-like construction of its copy. It's in no hurry. Time is on its side. But I guess in loopship, the gliders are the brain and the stationary parts can be built and erased very fast [edit: actually building takes many steps].

[Yup, my link had an extra 'f' in it -- fixed, thanks.]

Heh, really the biggest difference between Gemini and a loopship is that with Gemini, Golly really can't run it quickly (unless you cheat and load it into a Golly timeline, anyway) -- so you're forced to watch it at slow speeds and you can see all the construction details.

For the loopship, Golly just happily lets you turn up the speed, so the construction can seem to go quite quickly. Single-channel construction is really a much slower and more painful process than Gemini-style two-arm construction, which is part of why it quickly becomes very tempting to turn up the speed so far that you can't see the individual gliders moving any more.

-- There is a difference in the destruction method, though. Gemini does its cleanup incrementally with a separate destruction arm, whereas the loopship is much more modern and does everything with near-instantaneous self-destruct circuitry.

[pcallahan]

Heh, really the biggest difference between Gemini and a loopship is that with Gemini, Golly really can't run it quickly (unless you cheat and load it into a Golly timeline, anyway) -- so you're forced to watch it at slow speeds and you can see all the construction details.

I think it's also easier to guess where the action is happening. To see the construction in loopship, you have to know where the reflector is going to be built. It's also a more diffuse design overall with a lot of little components in different places. I will have to find out where those corderships come from.

Side note: what would really have been useful when demo-ing to non-Life people would be a script that consisted of a series of commands to move the position, zoom, and generate to a different step. Is there anything like that?

-- There is a difference in the destruction method, though. Gemini does its cleanup incrementally with a separate destruction arm, whereas the loopship is much more modern and does everything with near-instantaneous self-destruct circuitry.

Yes, running it in LifeHistory was sufficient to identify the MWSSs of doom. It's quite dramatic seeing that green line heading down the screen.

But I really was mystified how a stream could elbow like that. In fact, briefly thought "something running at a slower speed than a glider" but my resistance to thinking of corderships as disposable was too strong to pursue the idea further.

Now I'm starting to think about my ancient design for an extensible delay line store. It did not bother me at the time that the backward spaceships are created wastefully by a puffer, but I wonder what would be the simplest design for a Turing-equivalent machine with an extensible tape loop: I.e. with a fixed reflector that could be pushed out or pulled back with a signal (pull back is optional, since that does not affect universality) . There are many ways to do it now. (Note: this is different from an infinity-hotel style pattern where the loop is always receding. A machine based on that will have exponential slowdown because the return time goes up by a constant factor with each trip around.)

[dvgrn]

I think it's also easier to guess where the action is happening. To see the construction in loopship, you have to know where the reflector is going to be built.

Yup. I've internalized my standard Golly workflow so thoroughly by now that it doesn't even occur to me that this might be a difficulty. Once the "Reset/Undo will restore view" checkbox has been unchecked in Preferences, I always just run a pattern until I see where the action is, zoom in on that spot, hit Ctrl+Z a few times or Ctrl+R to get the action to un-happen, and then pick a step size and start running again -- or hit Tab a lot of times if I want to save undo points so that I can run forwards and backwards through the action with Ctrl+Shift+Z and Ctrl+Z.

Side note: what would really have been useful when demo-ing to non-Life people would be a script that consisted of a series of commands to move the position, zoom, and generate to a different step. Is there anything like that?

Well... it's not terribly difficult to write a Python or Lua script to do that kind of thing in the Golly universe. I think heisenburp.lua is one of the few examples. It's ancient (or at least heisenburp.py is) but might give the idea. Selection and view changes happen in some of the layers once the 2c/3 wire signal is created, so you just have to wait a while for that.

This kind of thing would be a lot easier to do in just a single layer, it just hasn't been done very often. Partly that's because LifeViewer waypoint scripts are quite a bit more user-friendly, anyway. Are you familiar with them?

First, to make things simpler, go to Preferences > Keyboard, and map something like Ctrl+Shift+L to the script "showinviewer.lua". Then you can run the LifeViewer animation/labels/whatever associated with a pattern just by opening the pattern in Golly and hitting Ctrl+Shift+L.

Try opening any of the patterns in Golly's Patterns/Life/Rakes folder, and hitting Ctrl+Shift+L once you've set it up. Try them all, they're all a bit different from each other -- some of them have defined Points of Interest that you can jump between, for example, where others are more about the labels/arrows/polylines and others are all about the animation.

The first time you try running the showinviewer.lua script (with Ctrl+Shift+L or otherwise) you'll have to follow some pop-up instructions to download the latest version of LifeViewer to your local computer. Don't worry, it's harmless -- it's just the same thing your computer does every time you look at a LifeViewer pattern here on the forums. And there are LifeViewer waypoint scripts old and new(er) posted in various threads on the forums, if you'd rather just look at those.

... I wonder what would be the simplest design for a Turing-equivalent machine with an extensible tape loop: I.e. with a fixed reflector that could be pushed out or pulled back with a signal (pull back is optional, since that does not affect universality) . There are many ways to do it now.

You can say that again. Probably just use slsparse to compile a recipe for two Snarks making a 180-degree turn, with some self-destruct circuitry so they can both be cleaned up by a single glider. Then you arrange an elbow to point at the next valid location for those Snarks, and a little fixed-size memory loop to hold that recipe, and a timer to turn the memory loop on and off at the right times.

The new Snarks get built safely behind the existing ones, and then the glider gets sent to knock out the Snarks (at the right time again -- more slightly tricky timing details here, handwave handwave) and the elbow gets pushed a little farther out.

[C28]

would this be called a converter?

Code: Select all

x = 4, y = 16, rule = B3/S23
2bo$bobo$2bo10$b3o$b3o$obo$2o!

[dvgrn]

would this be called a converter?

Code: Select all

x = 4, y = 16, rule = B3/S23
2bo$bobo$2bo10$b3o$b3o$obo$2o!

No. It doesn't make any controlled changes to just part of a larger still life, without affecting the rest of it. This is more of an Arbitrary Destroyer and Re-Creator, and those aren't exactly in short supply...!

[pcallahan]

The new Snarks get built safely behind the existing ones, and then the glider gets sent to knock out the Snarks (at the right time again -- more slightly tricky timing details here, handwave handwave) and the elbow gets pushed a little farther out.

The obvious question I've resisted asking: would it be cheaper to use a pair of buckaroos instead of snarks? The timing of the bit loop would be constrained to a multiple of 30 but that's not obviously a deal breaker . You should be able to convert back and forth to any period greater than 30, (e.g. 43 for high-frequency snark logic), as long as you resync the periods when reading and writing memory.

I had been hoping to find a p30 180° reflector based on two mutually stabilizing queen bees (saving the cost of eaters) but I couldn't find one with incoming and outgoing gliders separated enough to pass. Anyway, two buckaroos seem like they should be easier to synthesize than two snarks, but I'm not sure if synchronization is a problem.

Added question: So how hard it is to convert a period n signal to period m for n > m? Is there a nice name for this component? I am sure I have seen the basic idea in some patterns but I have not seen the nicest general solution. The way I think it could be done is to have a stable circuit that converts a glider to a still life blocking the other signal path. So now it gets the inverse bits from the input signal but at its own period. This will fail if the output pulse hits some time when the blocking still life is not ready, so you also have glider-to-spark components that serve the purpose of the blocking still life for just these periods, but let other gliders pass ensuring that no gliders are present until the block is ready. This works, right? Is there a nice example anywhere or a much simpler solution?

[dvgrn]

The obvious question I've resisted asking: would it be cheaper to use a pair of buckaroos instead of snarks? The timing of the bit loop would be constrained to a multiple of 30 but that's not obviously a deal breaker . You should be able to convert back and forth to any period greater than 30, (e.g. 43 for high-frequency snark logic), as long as you resync the periods when reading and writing memory.

I had been hoping to find a p30 180° reflector based on two mutually stabilizing queen bees (saving the cost of eaters) but I couldn't find one with incoming and outgoing gliders separated enough to pass. Anyway, two buckaroos seem like they should be easier to synthesize than two snarks, but I'm not sure if synchronization is a problem.

It's not an unsolvable problem, but it's not a solved problem... whereas Snark construction and destruction is a solved problem -- slsparse can pretty much tell us the recipe (with a little added fiddling around for the input glider for the self-destruct circuit.)

We won't really know if two buckaroos are cheaper than two Snarks, until someone builds a completely optimal recipe for two buckaroos in two different orientations. Even then we won't really know, because it's possible that slsparse's Snark recipes could be improved. People have been building up a lot of experience at optimizing construction recipes in the last few years, and its possible that some new mechanisms could be applied to the known slow-salvo Snark recipes.

Added question: So how hard it is to convert a period n signal to period m for n > m? Is there a nice name for this component? I am sure I have seen the basic idea in some patterns but I have not seen the nicest general solution. The way I think it could be done is to have a stable circuit that converts a glider to a still life blocking the other signal path. So now it gets the inverse bits from the input signal but at its own period. This will fail if the output pulse hits some time when the blocking still life is not ready, so you also have glider-to-spark components that serve the purpose of the blocking still life for just these periods, but let other gliders pass ensuring that no gliders are present until the block is ready. This works, right? Is there a nice example anywhere or a much simpler solution?

Sounds like you're looking for universal regulators. Finally just last year Jormungant found some really nice direct mechanisms for doing this -- "safe" for all relative phases. Basically it's a glider-to-boat converter, where the boat pushes a cell into a key location just as it's finished being constructed -- and the glider stream that's being converted only interacts with that protruding cell of that boat, for just one tick so there's no danger of the boat arriving "too late". Before that we'd been relying on some awkward Rube Goldbergian devices that Paul Chapman and I had cobbled together.

[creeperman7002]

I remember that there was a collection of common evolutionary sequences somewhere in the forums, however I can't find it now. Where is the collection?

[dvgrn]

I remember that there was a collection of common evolutionary sequences somewhere in the forums, however I can't find it now. Where is the collection?

This thread by MathAndCode, maybe?

[hotdogPi]

I remember that there was a collection of common evolutionary sequences somewhere in the forums, however I can't find it now. Where is the collection?

I think it was this one.

[GUYTU6J]

Given a pattern with two sub-patterns at variable relative positions, there is an immediate intuition to define some functions where each assigns one of the metrics of a pattern to the relative location. For example, take an R-pentomino (oriented and centered as in the conduits collection) and a block (represented by the top-left cell), and consider the lifespan of their union. At (-4,3) the corresponding pattern lasts 1139 ticks:

Code: Select all

x = 6, y = 6, rule = B3/S23
4bo$4b2o$3b2o2$2o$2o!

Plotting the lifespan on a square grid gives a diagram like the following MSpaint work, in which R-pentomino is marked in deeper gray and light gray depicts a forbidden zone. It looks like 1139 is a local maximum.

two_component_diagram.png (7.9 KiB) Viewed 2819 times

So the question is, is there recent attempts to enumerate, record and represent these datas with modern technology?
I would not be surprised if similar investigation has been done in the 1970s Lifeline era, as it is very obvious. However, there does not seem to be similarly obvious and accesible repositories for these results.
I imagined lifelib could help, so previously I asked in a different thread but got no response.

Is lifelib capable of analyzing methuselahs, i.e. given a pattern RLE, can any function output its lifespan, bounding box, MCPS, final population, etc?

The thought could be generalized to patterns with more sub-patterns. For instance, it visually defends the idea of 40514M being a notable methuselah by showing that moving any of the five sub-patterns within some neighbourhood always results in a smaller lifespan and thus 40514 is a local maximum.

[MathAndCode]

Is lifelib capable of analyzing methuselahs, i.e. given a pattern RLE, can any function output its lifespan, bounding box, MCPS, final population, etc?

No. Because ConwayLife is Turing-complete, one can build a Turing machine in it and run an example of why the halting problem has no general solutions, so there can be no general algorithm capable of telling whether or not any pattern in ConwayLife will eventually settle.

[mniemiec]

Is lifelib capable of analyzing methuselahs, i.e. given a pattern RLE, can any function output its lifespan, bounding box, MCPS, final population, etc?

No. Because ConwayLife is Turing-complete, one can build a Turing machine in it and run an example of why the halting problem has no general solutions, so there can be no general algorithm capable of telling whether or not any pattern in ConwayLife will eventually settle.

While eventual halting is not computable, it should be possible to answer the question, "Does this pattern settle by generation n?" for some arbitrarily large n. Just set n to a value that is high enough to deal with most patterns, and then manually examine any patterns that don't settle within that time.

[dvgrn]

Is lifelib capable of analyzing methuselahs, i.e. given a pattern RLE, can any function output its lifespan, bounding box, MCPS, final population, etc?

No. Because ConwayLife is Turing-complete, one can build a Turing machine in it and run an example of why the halting problem has no general solutions, so there can be no general algorithm capable of telling whether or not any pattern in ConwayLife will eventually settle.

While eventual halting is not computable, it should be possible to answer the question, "Does this pattern settle by generation n?" for some arbitrarily large n. Just set n to a value that is high enough to deal with most patterns, and then manually examine any patterns that don't settle within that time.

On a more practical note, there's a "methuselah" category on Catagolue, so there's already code out there that is doing a lifespan analysis for long-lived patterns. Does anyone know specifically where the methuselah-processing code is hiding? I assume it's in the apgmera project somewhere, not in the Catagolue back-end code.

[creeperman7002]

Why are the higher symmetries of b3s23 barely searched anymore? Surely there's still a lot of potential to discover new things by doing that.

[Sokwe]

Why are the higher symmetries of b3s23 barely searched anymore? Surely there's still a lot of potential to discover new things by doing that.

I have the same question. Back when Carybe and Apple Bottom were searching them, we got several new interesting oscillators. Since they stopped almost two years ago, we've not found many new objects. I'm especially hopeful that a new spaceship can be found, and I think this would be much more likely in a symmetric search.

[ihatecorderships]

I have the same question. Back when Carybe and Apple Bottom were searching them, we got several new interesting oscillators. Since they stopped almost two years ago, we've not found many new objects. I'm especially hopeful that a new spaceship can be found, and I think this would be much more likely in a symmetric search.

I think it's partly because there are no incentives. If you discovered a new thing in a higher symmetry, it won't show up in your discoveries, and so the person who discovered it won't know it. After some time, they'll begin to think that there is nothing to discover in higher symmetries, so they'll just switch to something else.
Also, I think the precompiled versions of all symmetries should be listed on the catagolue apgsearch page, because some windows users who do not want to install cygwin etc will just download that, and right now there is only C1.

I might start apgsearching them more, though.

[pcallahan]

Is lifelib capable of analyzing methuselahs, i.e. given a pattern RLE, can any function output its lifespan, bounding box, MCPS, final population, etc?

No. Because ConwayLife is Turing-complete, one can build a Turing machine in it and run an example of why the halting problem has no general solutions, so there can be no general algorithm capable of telling whether or not any pattern in ConwayLife will eventually settle.

Just to chime in (though it's been addressed already), I had heuristics that worked well enough when I was working with Nick Gotts to find small infinite growth patterns. Roughly: (1) run it until the population has a low periodicity (30 or less) or it has gone 30000 steps (I think that was what I used) (2) If it has a low periodicity, remove escaping gliders and see if the rest really consists of low period oscillators. (3) If so, check to see when it stabilized and report if the generation is high enough to be of interest. If not, report as undetermined.

Most of the time (perhaps all the time), an undetermined result was a switch engine, which it is what I was looking for.

Anyway, yes, of course this fails if the pattern happens to be an implementation of a Turing complete pattern for which its halting problem is undecidable. That would show up as undetermined, and would certainly be interesting to take a look at whether or not it was the point of my search.

This was nearly 25 years ago, so I'm sure there a much more convenient ways to do it now.

[ihatecorderships]

What exactly is the textbook that Nathaniel Johnston is writing? What will be in it? When will it be published?

[dvgrn]

What exactly is the textbook that Nathaniel Johnston is writing? What will be in it? When will it be published?

Here's what the table of contents looks like at the moment:

Preface . . . . . . . . . . . . . . . . . . . . . . . . . . xi
The Goal . . . . . . . . . . . . . . . . . . . . xi
Intended Audience . . . . . . . . . . . . . . . . . . . . xi
How to Use . . . . . . . . . . . . . . . . . . . . xii
Acknowledgments . . . . . . . . . . . . . . . . . . . . xiii

I Classical Topics
1 Early Life . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1 Our First Technique: Random Fumbling . . . . . . . . . . . . . . . . . . . . 5
1.2 Common Evolutionary Sequences . . . . . . . . . . . . . . . . . . . . 7
1.3 The Queen Bee . . . . . . . . . . . . . . . . . . . . 9
1.4 The B-Heptomino and Twin Bees . . . . . . . . . . . . . . . . . . . . 11
1.5 The Switch Engine . . . . . . . . . . . . . . . . . . . . 12
1.6 Methuselahs and Stability . . . . . . . . . . . . . . . . . . . . 15
1.7 Gardens of Eden . . . . . . . . . . . . . . . . . . . . 19
1.8 Notes and Historical Remarks . . . . . . . . . . . . . . . . . . . . 24
Exercises . . . . . . . . . . . . . . . . . . . . 26

2 Still Lifes . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.1 Strict and Pseudo Still Lifes . . . . . . . . . . . . . . . . . . . . 32
2.2 Still Life Grammar . . . . . . . . . . . . . . . . . . . . 35
2.3 Eaters . . . . . . . . . . . . . . . . . . . . 36
2.4 Welded and Constrained Still Lifes . . . . . . . . . . . . . . . . . . . . 39
2.5 Still Life Density . . . . . . . . . . . . . . . . . . . . 41
2.6 Notes and Historical Remarks . . . . . . . . . . . . . . . . . . . . 45
Exercises . . . . . . . . . . . . . . . . . . . . 47

3 Oscillators . . . . . . . . . . . . . . . . . . . . . . . 51
3.1 Billiard Tables . . . . . . . . . . . . . . . . . . . . 52
3.2 Stabilizing Corners . . . . . . . . . . . . . . . . . . . . 53
3.3 Composite Periods and Sparks . . . . . . . . . . . . . . . . . . . . 54
3.4 Hasslers and Shuttles . . . . . . . . . . . . . . . . . . . . 59
3.5 Glider Loops and Reflectors . . . . . . . . . . . . . . . . . . . . 62
3.6 Herschel Tracks . . . . . . . . . . . . . . . . . . . . 64
3.7 Omniperiodicity . . . . . . . . . . . . . . . . . . . . 69
3.8 Phoenices . . . . . . . . . . . . . . . . . . . . 71
3.9 Notes and Historical Remarks . . . . . . . . . . . . . . . . . . . . 73
Exercises . . . . . . . . . . . . . . . . . . . . 75

4 Spaceships and Moving Objects . 79
4.1 The Glider . . . . . . . . . . . . . . . . . . . . 80
4.2 The Light, Middle, and Heavyweight Spaceships . . . . . . . . . . . . . . . . . . . . 83
4.3 Corderships . . . . . . . . . . . . . . . . . . . . 86
4.4 Puffers and Rakes . . . . . . . . . . . . . . . . . . . . 88
4.5 Speed Limits . . . . . . . . . . . . . . . . . . . . 93
4.6 Speed and Period Status . . . . . . . . . . . . . . . . . . . . 100
4.7 Notes and Historical Remarks . . . . . . . . . . . . . . . . . . . . 104
Exercises . . . . . . . . . . . . . . . . . . . . 107

II Circuitry and Logic
5 Glider Synthesis . . . . . . . . . . . . . . . . 113
5.1 Two-Glider Syntheses . . . . . . . . . . . . . . . . . . . . 114
5.2 Syntheses Involving Three or More Gliders . . . . . . . . . . . . . . . . . . . . 116
5.3 Incremental Syntheses . . . . . . . . . . . . . . . . . . . . 118
5.4 Synthesis of Moving Objects . . . . . . . . . . . . . . . . . . . . 121
5.5 Developing New Syntheses . . . . . . . . . . . . . . . . . . . . 123
5.6 A Gosper Glider Gun Breeder . . . . . . . . . . . . . . . . . . . . 125
5.7 Slow Salvo Synthesis . . . . . . . . . . . . . . . . . . . . 127
5.8 Notes and Historical Remarks . . . . . . . . . . . . . . . . . . . . 135
Exercises . . . . . . . . . . . . . . . . . . . . 138

6 Periodic Circuitry . . . . . . . . . . . . . . . 143
6.1 Period 30 Circuitry . . . . . . . . . . . . . . . . . . . . 144
6.2 Primer . . . . . . . . . . . . . . . . . . . . 148
6.3 Period 46 Circuitry . . . . . . . . . . . . . . . . . . . . 152
6.4 Bumpers and Bouncers . . . . . . . . . . . . . . . . . . . . 159
6.5 Glider Timing and Regulators . . . . . . . . . . . . . . . . . . . . 161
6.6 Notes and Historical Remarks . . . . . . . . . . . . . . . . . . . . 164
Exercises . . . . . . . . . . . . . . . . . . . . 167

7 Stable Circuitry . . . . . . . . . . . . . . . . . 171
7.1 Herschel Conduits . . . . . . . . . . . . . . . . . . . . 171
7.2 Gliders to Herschels and Back . . . . . . . . . . . . . . . . . . . . 175
7.3 Glider-to-Herschel converters . . . . . . . . . . . . . . . . . . . . 176
7.4 Synthesizing Objects via Conduits . . . . . . . . . . . . . . . . . . . . 178
7.5 Period Multipliers and Small High-Period Guns . . . . . . . . . . . . . . . . . . . . 182
7.6 Converters for Other Objects . . . . . . . . . . . . . . . . . . . . 188
7.7 Factories . . . . . . . . . . . . . . . . . . . . 191
7.8 Notes and Historical Remarks . . . . . . . . . . . . . . . . . . . . 194
Exercises . . . . . . . . . . . . . . . . . . . . 196

8 Guns and Glider Streams . . . . . . . . 201
8.1 Glider Deletion . . . . . . . . . . . . . . . . . . . . 201
8.2 Glider Insertion . . . . . . . . . . . . . . . . . . . . 204
8.3 Streams of Other Spaceships . . . . . . . . . . . . . . . . . . . . 206
8.4 Glider Guns of Any Period . . . . . . . . . . . . . . . . . . . . 208
8.5 True-Period Guns . . . . . . . . . . . . . . . . . . . . 209
8.6 Slide Guns . . . . . . . . . . . . . . . . . . . . 221
8.7 Armless Construction . . . . . . . . . . . . . . . . . . . . 224
8.8 Slow and Irregular Guns . . . . . . . . . . . . . . . . . . . . 228
8.9 Notes and Historical Remarks . . . . . . . . . . . . . . . . . . . . 233
Exercises . . . . . . . . . . . . . . . . . . . . 236

III Constructions
9 Universal Computation . . . . . . . . . . 241
9.1 A Computer in Life . . . . . . . . . . . . . . . . . . . . 241
9.2 A Compiled APGsembly Pattern: Adding Registers . . . . . . . . . . . . . . . . . . . . 247
9.3 Multiplying and Re-Using Registers . . . . . . . . . . . . . . . . . . . . 251
9.4 A Binary Register . . . . . . . . . . . . . . . . . . . . 252
9.5 A Character Printer . . . . . . . . . . . . . . . . . . . . 260
9.6 A Pi Calculator . . . . . . . . . . . . . . . . . . . . 262
9.7 A 2D Printer . . . . . . . . . . . . . . . . . . . . 268
9.8 Notes and Historical Remarks . . . . . . . . . . . . . . . . . . . . 272
Exercises . . . . . . . . . . . . . . . . . . . . 273

10 Self-Supporting Spaceships . . . . . 277
10.1 The Silverfish . . . . . . . . . . . . . . . . . . . . 277
10.2 The Caterpillar . . . . . . . . . . . . . . . . . . . . 285
10.3 Oblique Helices and the Waterbear . . . . . . . . . . . . . . . . . . . . 292
10.4 Caterloopillars . . . . . . . . . . . . . . . . . . . . 295
10.5 Notes and Historical Remarks . . . . . . . . . . . . . . . . . . . . 300
Exercises . . . . . . . . . . . . . . . . . . . . 304

11 Universal Construction . . . . . . . . . . 307
11.1 Gemini and Geminoids . . . . . . . . . . . . . . . . . . . . 307
11.2 Single-Channel Glider Synthesis with a 90-Degree Elbow . . . . . . . . . . . . . . . . . . . . 314
11.3 Single-Channel Glider Synthesis with a Zero-Degree Elbow . . . . . . . . . . . . . . . . . . . . 319
11.4 Duplicating and Reflecting Single-Channel Recipes . . . . . . . . . . . . . . . . . . . . 323
11.5 A Slow Demonoid . . . . . . . . . . . . . . . . . . . . 328
11.6 A Middling Demonoid . . . . . . . . . . . . . . . . . . . . 330
11.7 A Fast Demonoid . . . . . . . . . . . . . . . . . . . . 332
11.8 Notes and Historical Remarks . . . . . . . . . . . . . . . . . . . . 337
Exercises . . . . . . . . . . . . . . . . . . . . 341

12 The 0E0P Metacell . . . . . . . . . . . . . . 345
12.1 Rule Emulation . . . . . . . . . . . . . . . . . . . . 345
12.2 Structure of the Metacell . . . . . . . . . . . . . . . . . . . . 346
12.3 Memory Tape . . . . . . . . . . . . . . . . . . . . 347
12.4 Logic Circuitry . . . . . . . . . . . . . . . . . . . . 348
12.5 Construction . . . . . . . . . . . . . . . . . . . . 348
12.6 Encoding Other Cellular Automata in Life . . . . . . . . . . . . . . . . . . . . 348
12.7 Notes and Historical Remarks . . . . . . . . . . . . . . . . . . . . 348
Exercises . . . . . . . . . . . . . . . . . . . . 349

Appendices and Supplements
A Mathematical Miscellany . . . . . . . 353
A.1 Modular Arithmetic . . . . . . . . . . . . . . . . . . . . 353
A.2 Greatest Common Divisor and Least Common Multiple . . . . . . . . . . . . . . . . . . . . 353
A.3 Big-O Notation . . . . . . . . . . . . . . . . . . . . 354
B Extra Details . . . . . . . . . . . . . . . . . . . . 355
B.1 Universality of the Clock Inserter . . . . . . . . . . . . . . . . . . . . 355
B.2 Snarkmaker Timings . . . . . . . . . . . . . . . . . . . . 358
B.3 Scorbie Splitter Maker Timings . . . . . . . . . . . . . . . . . . . . 360
B.4 Scorbie Splitter Destroyer Timings . . . . . . . . . . . . . . . . . . . . 364
B.5 Cordership Maker Timings . . . . . . . . . . . . . . . . . . . . 364
B.6 Pi APGsembly Code . . . . . . . . . . . . . . . . . . . . 367
C Solutions to Selected Exercises . . 371

Bibliography . . . . . . . . . . . . . . . . . . . 387
Index . . . . . . . . . . . . . . . . . . . . . . . . . . 391

It's definitely still a work in progress, but coming along nicely. Just recently work has started on illustrations for the final chapter -- though there's also a painful programming task that I've been avoiding, relating to Chapter 9.

Nathaniel has gotten through a "final" re-read and cleanup through Chapter 6. Once that cleanup pass is complete through Chapter 12, it will be time to recruit some beta readers... watch for a new thread in, I don't know, maybe a few months!