lukebradford wrote:Sorry to derail this on such a philosophical note, but this really got me thinking!
The thread's title is "What is a replicator?" -- a fairly philosophical subject, so I think really you're right on topic.
I've been thinking along somewhat similar lines lately. It's funny that I actually think of this Geminoid replicator project of mine as being "reasonable sized", because the replicator body can be cut down to 66 still lifes or so. Never mind that the two halves are separated by three million cells diagonally or thereabouts, and that there's a lot of data flowing between them. As far as self-constructors go, it's conceptually a fairly simple object -- a reduction of at least several orders of magnitude, I think, from the early general replicator blueprints from the 1970's and 1980's (Conway, Gosper, and Poundstone).
I'm hoping Golly will agree that it's simple, so that it can run the pattern at breakneck speed. There should be far fewer hashtiles than the Gemini or Caterpillar spaceships -- but probably not few enough that Golly can really run away with the replicator, mostly because of the phase shift between copies. The gliders in each loop are slowed down by 277 ticks relative to the last -- so at best Golly won't see a new replicator that's tile-for-tile identical with the original until after about 90,000 replication cycles (~25 million ticks per cycle of the memory loop, divided by 277). And that's only if I have the estimated recipe length about right, which I'm increasingly uncertain about...
In any case, Golly has really skewed the idea of what "reasonable sized" is. In 2003 when the first prototype B3/S23 universal constructor came out, it seemed clear that a self-constructing spaceship or replicator based on the prototype was going to be so huge and slow that actually building one was something of an academic exercise. You could prove that each piece of it worked, perhaps, and you could string all the pieces together, but it looked like it would take years to run the whole thing through even one replication cycle. Paul Chapman and I were half-planning to write some kind of special-purpose simulator that knew how each of the pieces worked, and could quickly calculate the state of the whole system far into the future.
Then it turned out that Golly was a general-purpose simulator that could do exactly the same thing, and we didn't even have to worry about telling it all the details of how the pieces interacted -- the Hashlife algorithm can happily figure all that out just by running the pattern and seeing what happened.
So now almost any non-chaotic pattern that can run very quickly in Golly seems pretty reasonable-sized -- even if its bounding box happens to be enormous, it's still in some sense a "simple" pattern.
The current question I'm puzzling over is this: how much more complicated should I make this Geminoid replicator project, just so that it looks "simpler" or more "reasonable"
to Golly? It happened to be very easy to make the replicator's spatial offset a nice simple power of two -- it's (0,-256) in the current version, but it could be (-256, -512) or anything in between just by moving two "hand" blocks, or by adding a few thousand more gliders to the recipe.
But adding sixty or eighty more still lifes to the replicator body could probably produce a memory loop that was an exact power of two in size, as opposed to the current 82546+/-8N which is definitely not so Hashlife-friendly. Many more gliders would be needed in the recipe that builds the replicator body... so it would be "slower" to build -- it would take more ticks to finish a cycle -- but immeasurably faster to run, since Golly would stop seeing new hashtiles much sooner and could run away with the replication.