Challenge: Super HBK

[Moosey]

I can make a thread but I have practically nothing to contribute, and my rule of thumb for making threads I like is:
Make the thread yourself iff you will contribute.

But If you say

It would be a good challenge thread if someone wanted to work on it. It's not technically difficult. All the pieces are known, but they've never been put together in this particular way before.

Then someone should make a thread. I can do it if nobody else wants to put their name on it but I think that you (dvgrn) or some other life pattern engineering expert should.

Seems like the "Life pattern engineering experts" would really like to train new Life pattern engineering experts, if anyone is interested. But that never happens if new Lifenthusiasts just sit around waiting for the tired old experts to build the next strange and wonderful design.

If you start the thread, you may find that you have more to contribute than you think. This Half-Baked Super Constellation can be divided up into relatively simple pieces, and you can make a high-level blueprint that maybe people will be inspired to fill in.

One useful task would be to build modern Spartan-ish replacements for some of the useful technology in calcyman's Osqrtlogt pattern. For example, the microprogram storage units could be rebuilt to be self-constructing -- those are the two vertical lines, with honeybits and eaters to distinguish 1 from 0. The bigger unit is activated for the first time at T=1,920,000, and finished its first read cycle at T=11,000,550.

Or start smaller and easier, with the two-bit binary to unary converter:

Code: Select all

snip

I forget what the inputs and outputs do, but you can figure that out by inspection -- and then you can rebuild the same circuit at an order of magnitude or more smaller. Notice the whole Osqrtlogt is made out of Silver reflectors and other pre-Snark, pre-syringe, and sometimes non-slsparse-constructible stuff.

There might not even be any timing constraints that would prevent each of the Osqrtlogt pieces from being replaced individually, eventually making the whole pattern smaller and lighter.

Well, I’m inspired now.
Basically, a superHBK is a giant constellation/SL which becomes a spaceship when hit by a glider-it turns into a UCC, reconstructs itself, and removes the UCC while simultaneously reconstructing the glider.

See discussion here for details.
Sorry for the OP post.


Re:
making things spartan:
which of these is more spartan? probably the bottom?
Otherwise there's an obvious improvement.

Code: Select all

x = 8, y = 16, rule = B3/S23
2o$o5b2o$b3obobo$3bobo$5bo$5bobo$6b2o5$2o$o5b2o$b3obobo$3bobo$4b2o!

EDIT:

Code: Select all

#C both are 5G, but I don't know which has a cheaper slow salvo synth. Near-certainly the bottom.
x = 29, y = 55, rule = B3/S23
24bo$22b2o$13bo9b2o$14b2o$13b2o3$15bo4bo$15b2o2b2o$14bobo2bobo2$27bo$
26b2o$26bobo16$15bobo$15b2o$8bo7bo$6bobo$7b2o3$9bo$10bo$8b3o3$11bo$11b
obo$11b2o9$2o$b2o$o!

I can't do this yet, of course, but I could perhaps help with the project in other ways.

[dvgrn]

Just ran into this in the Unanswered Posts list. Some of the ideas from the linked discussion never really got explored. Here's one of the ideas that seemed particularly interesting:

Can we make a copier for a specified region of the Life universe, if the contents are assumed to be very simple? For example, let's say we have a 1024x1024 Block-Filled Region. We know the BFR contains nothing but blocks, and each block has a ring of two empty cells around it. Can we build a scanner that makes an exact copy of those blocks -- or two simultaneous exact copies, while we're at it?

I think we could probably put together a new calculator component that can be run by APGsembly code, that could manage something along these lines. The scanner will have to check for the existence of a block at each possible location, returning a signal whenever a block is found, and avoid disturbing any nearby blocks when a block is not found.

I haven't come up with the perfect scanner reaction yet. Here are a couple of experiments that weren't quite good enough:

Code: Select all

x = 207, y = 80, rule = LifeHistory
46.A$45.A$45.3A4$41.A$40.A$40.3A11$27.A$26.A$12.2A3.2A7.3A95.D49.D$
12.2A3.2A100.2C2.2C44.2C2.2C$20.D98.2C2.2C44.2C2.2C$8.2A9.D104.D49.D$
8.2A3.2A3.D3.A101.D49.D$13.2A2.D3.A95.2C3.2CD42.2C3.2CD$16.D4.3A93.2C
3.2CD42.2C3.2CD$15.D108.D49.D$5.2A3.2E2.D109.D49.D$5.2A3.2E.D105.2C2.
2C44.2C2.2C$12.D106.2C2.2C44.2C2.2C7.2A$11.D103.2C7.D7.2A31.2C7.D6.A
2.A$3.2A5.D104.2C7.D6.A2.A30.2C7.D7.A.A$3.2A2.2AD2.2D110.D7.A.A39.D8.
A$7.2A3.2D2.2D104.2ED8.A38.2ED5.2D$7.D8.2D98.2C4.2ED5.2D34.2C4.2ED5.
2D$6.D109.2C6.D5.2D34.2C6.D$3.2AD3.2D113.D49.D$3.2A4.2D110.2C.D46.2C.
D$3.D117.2C.D46.2C.D$2.D114.2C5.D42.2C5.D$.D115.2C5.D42.2C5.D$D121.2C
D47.2CD$122.2CD47.2CD$124.D49.D$117.2C5.D42.2C5.D$117.2C2.2C.D42.2C2.
2C.D$121.2C48.2C$30.2A$30.A.A$30.A$24.3A$24.A$25.A2$30.3A$30.A$31.A2$
204.3A$154.3A47.A$154.A50.A$155.A7$49.2A$49.A.A$49.A$43.3A$43.A$44.A
2$49.3A$49.A$50.A!

On the left side, the idea is to scan the BFR along diagonals from northeast to southwest, and get a glider out whenever a block is present. Unfortunately the output glider is two lanes too close to the block array: if a block is present just one or two lanes back from the edge, like the yellow block shown, the scanner will miss it correctly but the output glider will hit it.

Similarly, on the right side, the idea is to scan the edge of the BFR vertically from south to north. Again, the yellow block shows a location that the scanner will correctly miss, but a block successfully detected nearby will interfere with it. I haven't shown a glider-producing test for the displaced block, in the event that a scan reaction successfully finds a block. With that much clearance that part of the problem seems relatively easy.

-- Again, the reason that it would be useful to be able to make perfect copies of large regions of scattered blocks, is that Blockic seeds can be built for all kinds of interesting objects, possibly up to and including the constellation spaceship that Moosey described.

Is there any known technology for doing this kind of scan in the least invasive way possible? If not, can anyone come up with some new technology that works better than the above?

[Moosey]

Those bring to mind another idea-- a spaceship consisting primarily of a sea of blocks which look randomly arranged. I think that could work, possibly as a SHBK as well

I remember that you started a different thread for the same subject here, by the way, at which point SHBK became SS-SS

[mscibing]

Is there any known technology for doing this kind of scan in the least invasive way possible?

One of the two glider block creation reactions is fit for purpose and can accommodate very tight block spacing (I think anything short of a bi-block). With a couple of extra steps you can encode the read result in the timing of a kickback glider. I've put the kickback gliders from the two reads on separated lanes so they don't interfere with each other.

Code: Select all

x = 180, y = 150, rule = LifeHistory
144.A$142.2A$143.2A47$95.A$80.2A3.2A6.2A$80.2A3.2A7.2A$88.D$76.2A9.D$
76.2A3.2A3.D$81.2A2.D$84.D$83.D$73.2A3.2E2.D$73.2A3.2E.D$80.D$79.D$
71.2A5.D$71.2A2.2AD3.2D$75.2A4.2D$75.D$74.D$71.2AD$71.2A9.2D$71.D10.
2D$70.D$69.D$68.D8$69.3A$71.A$70.A5$57.2A4.2A$56.A.A3.A.A$58.A5.A2$
117.A$116.2A$116.A.A38$18.3A$20.A$19.A5$6.2A4.2A$5.A.A3.A.A$7.A5.A2$
176.A$175.2A$175.A.A!

I guess though that you'd really want the salvos at right angles rather than coming directly at each other.

[dvgrn]

One of the two glider block creation reactions is fit for purpose and can accommodate very tight block spacing (I think anything short of a bi-block). With a couple of extra steps you can encode the read result in the timing of a kickback glider. I've put the kickback gliders from the two reads on separated lanes so they don't interfere with each other.
...
I guess though that you'd really want the salvos at right angles rather than coming directly at each other.

Yup, that looks about as good as a test can get. Here it is rearranged and re-colored a little bit, and labeled with where the output gliders end up at T=100:

Code: Select all

x = 140, y = 34, rule = LifeHistory
96.2A$15.2A6.B72.2A2.2A$15.2A2.2A.B77.2AB$19.2AB71.2A6.B$12.2A6.B72.
2A2.2A.B$12.2A2.2A.B77.2AB$16.2AB79.B$17.B72.2A2.2A.B$9.2A2.2A.B73.2A
2.2AB3.C$9.2A2.2AB3.C75.B2.2C$14.B2.2C68.2A5.B4.2C36.D$6.2A5.B4.2C36.
D30.2A2.2DB29.D3.D9.D$6.2A2.2EB29.D3.D9.D34.2D30.D3.D9.D$10.2E30.D3.D
9.D34.B20.3D.3D4.3D.D.3D.3D.D.D$10.B20.3D.3D4.3D.D.3D.3D.D.D29.2AB14.
D.D4.D.D.D.D4.D.D.D.D.D.D3.2D$7.2AB14.D.D4.D.D.D.D4.D.D.D.D.D.D3.2D
30.2A16.2D4.D.D.3D4.3D.D.3D.3D.D.D$7.2A16.2D4.D.D.3D4.3D.D.3D.3D.D.D
29.B17.D$7.B17.D61.B$6.B79.B47.D$5.B47.D31.B8.3C23.D3.D9.D$4.B8.3C23.
D3.D9.D30.B11.C14.D.D6.D3.D9.D$15.C14.D.D6.D3.D9.D29.B11.C16.2D6.3D.D
.3D.3D.D.D$14.C16.2D6.3D.D.3D.3D.D.D56.D7.D.D.D.D.D.D3.2D$31.D7.D.D.D
.D.D.D3.2D65.3D.D.3D.3D.D.D$39.3D.D.3D.3D.D.D2$82.2C4.2C$.2C4.2C72.C.
C3.C.C$C.C3.C.C74.C5.C$2.C5.C$122.C$41.C79.2C$40.2C79.C.C$40.C.C!

I don't see any particular problem with gliders coming from three directions, if that's what's necessary. The amount of circuitry that would be needed to do one of these scans is fairly significant, but doesn't seem impossible. It ought to work to add a few more gliders to get two right-angle salvos, if needed.

I can see how to do it with five extra gliders for sure, but it probably won't need that many. It's just a little expensive to edge-shoot that glider that has to come in from the northeast, without ever letting anything cross the blue diagonal line.

Maybe the easiest way to do the detection part of the reaction, turning those different glider placements into different output gliders, would be to add a second kicked-back glider that leads the return signal. That glider could either be routed around to be kicked back itself, if the return glider is in the trailing "no block" position, or could pass behind the "block" glider signal and be eaten.

What about Rebuilding, Though?
Now that I think of it, it might be a tougher job to rebuild blocks in the same diagonal order that they're being scanned. Is there a known recipe that can do this?

Code: Select all

x = 22, y = 28, rule = LifeHistory
.A12.A$2.A9.2A$3A10.2A2$7.2D$6.D2.D$6.3BD12B$6.B2D12B$6.BD12B$6.13B$
6.BD10B3.B$6.5BD2BD2B3.B$6.6BDBD2B2.2A$.3A2.7B2D2B.B2A$3.A2.5B4D2B$2.
A3.10B2D$6.10B2D2.2A$6.6B2.B5.2A$6.5B2.B$6.4B2.B2A2.2A$6.3B2.B.2A2.2A
$6.2B2.B$6.B2.B2A$8.B.2A2.2A$7.B6.2A$6.B2A$7.2A2.2A$11.2A!

Or will it be necessary to forbid blocks in the BFR that are one cell away diagonally, making quasi constellations with other blocks? In which case there's a little more room to work:

Code: Select all

x = 23, y = 29, rule = LifeHistory
.A12.A$2.A9.2A$3A10.2A2$7.2D$6.D2.D$6.3BD12B$6.B2D12B$6.BD12B$6.13B$
6.BD10B3.B$6.5BD2BD3B2.2A$6.6BDBD3B.B2A$.3A2.7B2D4B$3.A2.5B4D3B$2.A3.
10B2D3.2A$6.10B2D3.2A$6.6B2.B$6.5B2.B$6.4B2.B2A2.2A$6.3B2.B.2A2.2A$6.
2B2.B$6.B2.B$8.B2A3.2A$7.B.2A3.2A$6.B2$10.2A$10.2A!

Unless I've done the infile.mc wrong, slsparse doesn't know how to do even the easier one of these block pushes. I suspect the harder one is provably impossible, and I have some vague memory that the easier one is also, but I'm not finding a reference (or a proof) offhand. The best recipe slsparse can find has an extra row of clearance on one side:

Code: Select all

x = 48, y = 45, rule = LifeHistory
23.25D$47.D$47.D$24.4B14.2D3.D$23.6B11.2B2D3.D$23.7B4.4B.6B2.D$23.7B
3.3B2A7B2.D$21.15B2A7B2.D$21.20B2A2B2.D$21.20B2A2B2.D$21.24B2.D$13.B
8.14B2A7B2.D$10.5B.B3.16B2A4B2AB2.D$8.10B.22BA2BA2.D$8.33BA2BA2.D$9.
33B2A3.D$7.B2.33B4.D$3.B2.3B.34B3.D$2.31B2.9B3.D$.29B5.8B4.D$31B3.8B
5.D$31B2.8B6.D$30B2.8B7.D$30B.8B8.D$38B9.D$37B10.D$36B11.D$35B$34B$
33B$33B$32B$31B$29B$29B$28B$26B$25B$24B$10B4.9B$9B4.5B3AB$8B4.8BA$7B
4.8BA$6B4.9B$5B4.9B!

EDIT: JLS doesn't seem to tell me instantly that pushing a block into the corner of its reaction envelope is obviously impossible. Somebody must have investigated this question before (and I hope it wasn't me).

Code: Select all

x = 12, y = 10, rule = LifeHistory
2.A$.4A3.A$7.A$.A4.3A$.A.4A$2.A.A4.A$5.A.2A.A$3.2A3.A.A$3.A2.3A.2C$
10.2D!

[Jormungant]

Another target to do that corner insert can be :

Code: Select all

x = 6, y = 6, rule = LifeHistory
3.A$2.2A$2.2A$.A2.A$2.A.CD$A3.CD!

but how to get there, I do not know, but it is simpler than what you linked.

there are many variants, and some qualify for the harder insert:

Code: Select all

x = 6, y = 6, rule = LifeHistory
.A$2.2A$2.2A$.A2.A$A.A.CD$4.CD!

[mscibing]

Easier insert:

Code: Select all

x = 507, y = 524, rule = LifeHistory
2.A$A.A$.2A29$23.A$21.A.A$22.2A29$53.A$51.A.A$52.2A34$82.A$80.A.A$81.
2A36$121.A$119.A.A$120.2A41$180.A$178.A.A$179.2A29$188.A$186.A.A$187.
2A35$245.A$243.A.A$244.2A39$274.A$272.A.A$273.2A33$315.A$313.A.A$314.
2A26$347.A$345.A.A$346.2A31$381.A$379.A.A$380.2A31$413.A$411.A.A$412.
2A29$436.A$434.A.A$435.2A39$485.A$483.A.A$484.2A9$499.2C$499.2C4$505.
B$504.2A$503.B2A$502.B$501.B$500.2D3.2A$499.B2D3.2A$498.B$497.B$496.B
2A2.2A$495.B.2A2.2A$494.B$493.B$492.B2A3.2A$491.B.2A3.2A$490.B2$494.
2A$494.2A!

I found this with a new program that shoots random gliders at a block and picks out solutions with a promising reaction envelope; it ran overnight. I did not restrict the envelope except near the corner, this may be why this worked and slsparse didn't.

Edit: The program is here: https://gitlab.com/andrew-j-wade/ajw_life_search. But I think I got lucky: the program is not very fast and it's not finding anything further unless I dial the depth of the corner way down.

[dvgrn]

Easier insert...

Nice find! It's still a fair distance from being able to incrementally insert any configuration that can be read by the scanning reaction, though.

It occurs to me that these reads are destructive anyway, meaning that at least two simultaneous copies have to be made every time a constellation is scanned, or we won't end up with a working spaceship.

That being the case, why shouldn't the original and one of the copies be an "exploded" version, with everything twice as far apart as the actual constellation?

Then I think a scan could be done orthogonally, and the build (at both double-size and actual size) could also be done orthogonally, and everything would suddenly be a lot easier. (?)