Is it practical to create ______?

[Kiran]

This thread is for ideas of questionable practicability, and attempts to create such objects.
The goal is to combine threads such as viewtopic.php?f=2&t=1813.

Is it practical to, perhaps for a Wolfram 1D, non-B0 rule, create a self supporting metapixel (a metapixel in which dead cells are not needed and live cells create their neighbours using construction arms)?

[BlinkerSpawn]

Is it practical to create a self supporting metapixel (a metapixel in which dead cells are not needed and live cells create their neighbours using construction arms)?

How would a given cell know when and where to construct a new cell?

[Kiran]

How would a given cell know when and where to construct a new cell?

All live cells are synchronized and, after a signalling stage, construct new cells at the end of each cycle, after which they can remain or self-destruct depending on the signals they receive from other cells.
The location of the new cell is another slot on the large grid defining the positions.

[M. I. Wright]

This is nowhere near as ambitious as the proposed metapixel (which doesn't sound practical at all, by the way - although definitely possible, and I'd certainly be interested in seeing it) but has anyone ever tried to create a moving prepulsar hassler, in the style of the various LOM pushers? I'm not sure it's possible, actually - here are two (un-repeatable) examples:

Code: Select all

x = 50, y = 22, rule = LifeHistory
41.2D3.2D$41.3D.3D$40.D.2D.2D.D$40.3D3.3D$39.A.C5.C.A$42.A3.A$42.A3.A
$39.A2.A3.A2.A$40.3A3.3A$D27.D$.2D2.A17.A2.2D$2D.A.A17.A.A.2D$4.2A17.
2A8$10.3A3.3A21.3A3.3A$11.A5.A23.A5.A!

[Kazyan]

This is nowhere near as ambitious as the proposed metapixel (which doesn't sound practical at all, by the way - although definitely possible, and I'd certainly be interested in seeing it) but has anyone ever tried to create a moving prepulsar hassler, in the style of the various LOM pushers? I'm not sure it's possible, actually - here are two (un-repeatable) examples:

Code: Select all

x = 50, y = 22, rule = LifeHistory
41.2D3.2D$41.3D.3D$40.D.2D.2D.D$40.3D3.3D$39.A.C5.C.A$42.A3.A$42.A3.A
$39.A2.A3.A2.A$40.3A3.3A$D27.D$.2D2.A17.A2.2D$2D.A.A17.A.A.2D$4.2A17.
2A8$10.3A3.3A21.3A3.3A$11.A5.A23.A5.A!

There's a demonstration of a way to do this in Golly's orthogonal.rle:

Code: Select all

x = 153, y = 15, rule = B3/S23
79bo35bo5bo$79bo35bo5bo$31bo5bo35bo4bobo33bobo3bobo$31bo5bo35bo5bo35bo
5bo$30bobo3bobo33bobo4bo35bo5bo$31bo5bo35bo19bo7bo33bo7bo$31bo5bo35bo
13b2obobob2o3b2obobob2o21b2obobob2o3b2obobob2o$9bo7bo33bo7bo24b3obob3o
9b3obob3o15b3obob3o9b3obob3o$3b2obobob2o3b2obobob2o7bo13b2obobob2o3b2o
bobob2o18bo3bobo5bobo5bobo3bo15bo3bobo5bobo5bobo3bo$3obob3o9b3obob3o4b
o10b3obob3o9b3obob3o19b2o6bobo6b2o23b2o6bobo6b2o$o3bobo5bobo5bobo3bo2b
2obo9bo3bobo5bobo5bobo3bo16b2o9bobo9b2o17b2o9bobo9b2o$4b2o6bobo6b2o8bo
14b2o6bobo6b2o20b2ob2o15b2ob2o17b2ob2o15b2ob2o$b2o9bobo9b2o5bo11b2o9bo
bo9b2o21bo15bo25bo15bo$b2ob2o15b2ob2o17b2ob2o15b2ob2o$5bo15bo25bo15bo!

AFAIK there's no version using gliders or LWSSs.

[codeholic]

There is even an article on LifeWiki.

[BlinkerSpawn]

How would a given cell know when and where to construct a new cell?

All live cells are synchronized and, after a signalling stage, construct new cells at the end of each cycle, after which they can remain or self-destruct depending on the signals they receive from other cells.
The location of the new cell is another slot on the large grid defining the positions.

I should have rephrased my question: How would a cell know that another cell is being born adjacent to it, and which of a new cell's three neighbors would construct it?

[Extrementhusiast]

How would a given cell know when and where to construct a new cell?

All live cells are synchronized and, after a signalling stage, construct new cells at the end of each cycle, after which they can remain or self-destruct depending on the signals they receive from other cells.
The location of the new cell is another slot on the large grid defining the positions.

I should have rephrased my question: How would a cell know that another cell is being born adjacent to it, and which of a new cell's three neighbors would construct it?

Hypothetically, one system could be the first cell encountered going (counter)clockwise around the center, starting from a certain cell (the same one every time)

[Kiran]

For Wolfram 1D rules it could be easier because geminoid technology can be used, however each geminoid must be able to build in both directions, self destruct and communicate with other geminoids.
Also, the question of which geminoid creates the new cell between them still remains.

[Kiran]

Is it practical to create a "spacefiller" which fills the plane with a grid of Unit cells?
It is theoretically possible because the OTCA metapixel has a virtual speed of light of 4c/69 and this is much slower then c/2 or c/4.

[BlinkerSpawn]

Is it practical to create a "spacefiller" which fills the plane with a grid of Unit cells?
It is theoretically possible because the OTCA metapixel has a virtual speed of light of 4c/69 and this is much slower then c/2 or c/4.

Technically, yes, but it wouldn't be a spacefiller per se, it would be a series of high-period c/2 rakes and puffers which would produce other) c/2 rakes and puffers which would in turn construct individual parts of the metapixel.
Saying that the resulting quadratic-growth pattern would probably be a million cells to a side seems (to me) like a conservative estimate.

[codeholic]

I think it would be practical to optimize the OTCA metapixel using modern technology first

[Scorbie]

I think it would be practical to optimize the OTCA metapixel using modern technology first

Huh! I wonder how small (or easy to construct) would that be now.

[drc]

Can OCTA metapixel emulate itself?

[SuperSupermario24]

Can OCTA metapixel emulate itself?

In theory it can, but the completed pattern would be disgustingly large.

[dvgrn]

Can OCTA metapixel emulate itself?

Theoretically, yes, of course. As a bonus, the OTCA metapixel is a pure power of two in width and height, so if you're careful, the metacell representation of a meta-metapixel should only be about twice as big as a plain metapixel. The biggest hashtiles are made out of metapixel-sized hashtiles instead of single cells, but a hashtile of any size is just a number. Everything else is exactly the same (!). You could encode a meta-meta-meta-metapixel without an unmanageable file size.

But Will It Run?
Practically, in Golly with its currently available algorithms... probably a meta-metapixel won't be runnable. Maybe it could be done on a fast computer with enough terabytes of memory available for hash tables, but even then it would have to run for a long time before Golly could run it at top speed.

The metapixel circuitry is built with p46 technology and takes 35328 ticks to complete a cycle, which is 69 times a power of two. That means that Golly has to memorize 69 phases of each metapixel, along with all the variations that occur in the pattern of hashtiles containing overlapping half-metapixels in different states. With that factor of 69 in there the job gets unmanageable very quickly.

Might Work If Everything Was a Power of Two
A pure-stable rebuild of the metapixel wouldn't have that problem. Some other method would have to be used to make the ON state visible, but that shouldn't be too hard -- maybe just a switchable period 2^N gun feeding a couple of perpendicular chains of Fx77s, to make long streams of gliders crossing the pixel area.

It doesn't even have to be entirely stable. P8 figure-8 reflectors wouldn't cause Golly any trouble at all, and that would give a toolkit with color-preserving reflectors (Snarks), small color-changing reflectors (the P8s), and a p8 G-to-H that's even smaller than a syringe, that might come in handy for signal-splitting,

Won't Look Too Good, Though
There will still be a problem. With Golly's current display system for subpixel zooms, a view of a meta-metapixel would probably always look ON, no matter if the constituent metapixels were ON or OFF. Empty square rings look pretty much just like filled square rings if you zoom out far enough.

Maybe Golly 3.0?
There might possibly be a version of Golly coming up that could address that problem, by keeping track of how many ON cells there are in each hashtile and applying some kind of color gradient. If it's possible to manually adjust the color gradient, then it should be easy to set things up so that a meta-metapixel pattern looks good.

-- If the color gradients are adjustable enough, actually, the big pixel area wouldn't be necessary any more. We could go back to something like David Bell's original unit cell, and adjust the colors so that the OFF circuitry looked black when you were zoomed out far enough, but the ON circuitry (i.e., OFF circuitry plus a single glider) looked white...!

[dvgrn]

Is it practical to create a "spacefiller" which fills the plane with a grid of Unit cells?
It is theoretically possible because the OTCA metapixel has a virtual speed of light of 4c/69 and this is much slower then c/2 or c/4.

Technically, yes, but it wouldn't be a spacefiller per se, it would be a series of high-period c/2 rakes and puffers which would produce other) c/2 rakes and puffers which would in turn construct individual parts of the metapixel.
Saying that the resulting quadratic-growth pattern would probably be a million cells to a side seems (to me) like a conservative estimate.

Horrible thought, yes! We could crunch down a unit cell into a smaller space nowadays, or we could make it Spartan (and thus much easier to construct). But probably not both.

David Bell's original unit cell wouldn't be impossible to construct, and there's probably even a recipe for Brice Due's metapixel out there somewhere. But to make a spacefiller, the recipes would have use gliders coming from just two directions, so as to leave already-constructed unit cells alone.

That makes the problem a good bit more painful. It would probably be worth redesigning a unit cell from the ground up with constructibility in mind -- lots of room between the pieces, and never mind how big the bounding box is.

Once we're doing that much work anyway, it would be much more entertaining to build self-supporting unit cells, of the type Kiran mentioned at the beginning of this thread. If we build them right, they'd probably be a lot smaller and simpler than the c/2-rakes-building-c/2-rakes mess. Then just drop them into the universe in a spacefiller pattern, and you have unit cells expanding to fill the universe at, um, half the speed of meta-light. That's not very fast -- but really, what's the rush?

Calcyman did some design work for this kind of thing several years back, and there aren't any absolutely insurmountable roadblocks -- it's just a very very ambitious project. Calcyman's idea was to build a pattern that could emulate any 16-state body-centered cubic automaton. The state table could be chosen to emulate any Lifelike rule.