After a couple of years away from Life projects, I’ve thought of a couple of minor new tricks. My latest Geminoid replicator units are now almost two orders of magnitude smaller than the ones in the original Gemini:
#C one-armed Geminoid with single-use startup circuitry
x = 914, y = 995, rule = LifeHistory
This particular piece of circuitry can't be programmed to be a true replicator. I think it will be a useful step along the way, but the inputs and outputs don't line up right for replication and there's no mechanism yet for copying the data stream non-destructively to multiple targets.
I'll explain the above pattern just briefly for now, with more detail to come in future postings -- but any and all questions are welcome!
- 1) This Geminoid has only one construction arm, where the original Gemini spaceship had three. One arm is enough to construct any pattern made of well-separated small still lifes. And this Geminoid's constructor arm is symmetrical, so it can perfectly well be turned in the other direction for re-use as a destructor arm, once its construction work is done.
I'll save for a separate posting my accumulated evidence that a one-armed Geminoid can build anything that a two-armed Gemini can -- not very efficiently, true, but it's not as bad as one might think.
2) This Geminoid uses just a single coded data channel -- i.e., one stream of gliders to specify its construction recipe. This makes it much easier to program than the original Gemini's precisely-synchronized twelve-channel design. In a one-arm Geminoid, there are actually no signal crossings needed, either for the northwest replicator unit or for the southeast one. So construction data can be sent as quickly as the circuitry can accept it. In the long run, this should also make it much easier to copy construction data from a parent pattern to a child.
3) A sample 6-glider input stream is shown coming in from the southeast, and being reflected back to the southeast. State-5 (yellow) still lifes are single-use startup circuitry. Their purpose is to open an appropriate output channel depending on where the input gliders come in from. There are probably more efficient ways to arrange these single-use circuits, so this is just a proof of concept.
4) The state-4 (red) input glider at the left side the above pattern shows where the reflected gliders will enter a second copy of this pattern. If you paste another R.U. (replicator unit -- the entire pattern except for the "live" green gliders) to the right of the first one, lining up the red gliders, you'll see that the recipe has exactly the same effect on the constructor arm in each R.U. in succession -- it doesn't matter which direction the gliders came from.
For now you can just imagine that the second R.U. is very far to the southeast of the first one, in order to leave room for a huge self-construction recipe... just like in the original Gemini spaceship.
5) The 6-glider recipe doesn't do anything very exciting; it simply shows how pairs of gliders following each other on a single input lane can be copied, delayed and sent out in precisely synchronized pairs to manipulate a "construction elbow" (the block at the upper left). In this case, they simply delete the elbow.
However, if one of the gliders in the original 6-glider stream is delayed or advanced by a generation -- or any number of generations within certain limits -- then one of the output gliders heading for the construction elbow will end up being delayed or advanced by the same number of ticks, and something different will happen at the elbow.
There are known recipes, discovered by Paul Chapman a couple of years ago, for glider-pair salvos on these 9-cell-separated lanes that will push the elbow back various distances, pull it forward, and/or fire 90-degree gliders of both colors.
-- That's it for tonight, I think. Further wild speculations will be appearing tomorrow...!