Shrinking Gemini: Four Ideas

[HartmutHolzwart]

dvgrn wrote: But what was left would definitely be just a ridiculously complicated puffer, until we get a good self-destruct mechanism working... and we already have plenty of puffers.

Did I miss something? Where are all this slow puffers moving in odd directions?

Btw., couldn't we feed the overall four left alone constructur arms after the construction of the next generation with another glider recipe to delete the four constructors of the previous generation? David Bell suggested something like this.

But I agree just having a different slope and seeing the whole thing run would be a great thing. Optimising the design might be a second stage, if possible.

On a different idea: In ordinary chip design, to speed up things you create parallel execution paths. Is there an analogue for glider reflectors?

[dvgrn]

Btw., couldn't we feed the overall four left alone constructor arms after the construction of the next generation with another glider recipe to delete the four constructors of the previous generation? David Bell suggested something like this.

I guess this might work, but then again it might be too slow to be an improvement. If you're using a standard kickback reaction, you have to make sure the returning SW-travelling glider doesn't hit any recipe gliders in the channels (for the southeast replicator unit), and it has to avoid colliding with the construction-arm elbow as well. The repeat rate will be much slower than the usual 576 ticks, because you can't fire kickback glider #2 on the same or a nearby path until kickback glider #1 has passed the westward arm. I think that's something like 15,000 ticks between SW gliders. And then you need several of those hitting some junk to produce each SE glider that will actually do the deletions. You might end up averaging 50,000 or 100,000 ticks or more between these SE deletion gliders.

The current Gemini spaceship takes a little under 17 million ticks to complete a replicator construction/destruction cycle. The destructor arm is running for over half that time -- almost 10 million ticks. (I may not have these numbers quite right, but I think they're in the ballpark.) Now, getting rid of the destructor arm would mean there are fewer still lifes to shoot down, but it still seems as if you'll need more deletion gliders than you can produce in a reasonable amount of time -- especially because, if you're using just the east and west construction guns, you can't run the destruction in parallel with the construction as well as in the current design, so the period is likely to get much longer. Please feel free to come up with better estimates if the above numbers don't look right --

But I agree just having a different slope and seeing the whole thing run would be a great thing. Optimising the design might be a second stage, if possible.

This evening I finished running a (x,2x) knightship through its paces -- it turns out to be a (4096,8192)/c35567490 spaceship (macrocell file). I only had to make a one-line change in program.yaml, recompile the gliders for the twelve channels using asm.py, and feed them into two standard copies of the replicator unit. Just changing the relative output location for the new copy doesn't alter any of the math for the glider stream crossings, or any of the other "magic numbers" in lifelib.py.

Keep the cheer,


DaveG

[HartmutHolzwart]

dvgrn wrote : Meaning a slope of 3 in a 45-degree coordinate system? Can't we just call this a slope of 2? You should be able to produce a true (2x, x)

I really meant a slope of (3x,x) which would be (-1,2) in the degree 45 diagonal coordinate system. I still do not understand why this slope is more complex to build than the original (5x,x)!

BTW: Your second gemini indeed shows that the concept is really flexible. This should give you much confidence in the development of further modifications!

If you compare that to the caterpillar: Nobody ever tried to modify that construction.

So I think this is just the beginning.

Cheers,
Hartmut

[calcyman]

So I think this is just the beginning.

Indeed. I have already created a script to convert an arbitrary arrangement of (sufficiently spaced) blocks, eaters, boats, tubs, beehives and loaves into a synchronised glider-pair synthesis, and am in the process of accumulating a collection of constructible components (those that can be constructed in all eight orientations).

My ultimate objective is to build a working self-replicating configuration, which I believe would fit within a 200 000 * 200 000 box when completed. It will incorporate a universal computer, and a dedicated architecture to facilitate recursive subroutines. That means that the tape could be massively compressed, as a particular recipe (such as a reflector in a particular orientation) could be called hundreds of times by the program. Furthermore, the tape is contained within a two-dimensional array, similar to the one used in my O(sqrt(log(t))) pattern.

Unfortunately, my replicator is likely to take 10^15 generations to copy itself.

[dvgrn]

I really meant a slope of (3x,x) which would be (-1,2) in the degree 45 diagonal coordinate system. I still do not understand why this slope is more complex to build than the original (5x,x)!

It's just the same -- you only have to change the coordinates of the new Gemini on line 1831 of program.yaml, and ask Andrew's asm.py to recompile the gliders in the channels to avoid collisions. Takes just a few minutes to calculate the new recipe, and then maybe a little longer to paste in a couple of replicator units, and an hour of Golly's time to test the resulting pattern.

Here's a slope-3 Gemini with a minor design variation: instead of building and destroying replicator units at both ends at the same time, this double-length spaceship finishes all of its work on the northwest replicator before starting on the southeast replicator. There's enough space between the replicator units for the entire recipe glider stream, not just half of it.

Not too surprisingly, though, this doesn't seem to make Golly's hashlife algorithm significantly more efficient, or at least not enough to make up for doubling the number of ticks needed for a construction cycle.

If you compare that to the caterpillar: Nobody ever tried to modify that construction.

I've thought about it some, though. I don't think it would be too difficult to make various 17c/45 puffers and rakes by extending one of the sections toward the end, after the helix construction was all done on one side let's say, and adding some standard components to shoot gliders off to that side. But I've never really wanted a puffer or a rake quite that big...!

[HartmutHolzwart]

One more crude idea: Is it really necessary to have the full flexibility with both constructors? If one could do with a considerably simpler second construction arm, that might save a few gliders.

I was thinking about a sort of very regular program for the second arm and the simplifying the arm itself.

Probably a very vague option.

Cheers,
Hartmut

[HartmutHolzwart]

At the danger of asking something very stupid: Would it be possible to use just gliders of one color in the destruction process? Would this simplify the logic necessary in the respective constructor arm?

Also, the same idea could maybe be applied to one of the real constructor arm.

All about saving tape...

[calcyman]

Would it be possible to use just gliders of one color in the destruction process?

Possibly. Statistically, firing random gliders at an object should decompose it into simpler objects, and very rarely create more complex objects. Blocks and binkers can be destroyed by gliders on either parity. Using induction, this suggests that any pattern composed of still-lifes can be destroyed in this way, unless it has been designed specifically to be glider-proof.