MWSS Single-Channel Construction

[Extrementhusiast]

While this is a subject I have a relative lack of experience in, I was alerted to the need for more study on slow XWSS salvos. I ended up focusing on single-channel MWSS operations, due to the relative simplicity of the current best stable G-to-MWSS converter:

Code: Select all

x = 165, y = 73, rule = B3/S23
115b2o$115b2o5b2o$2bo119b2o$obo86bo$b2o84b3o$86bo33b2o$86b2o32b2o$126b
2o$126b2o$63b2o4b2o$63b2o3bo2bo$69b2o$89b2o$89b2o5$64b2o$64b2o$99b2o$
100bo$97b3o$64b2o31bo$24bo38bobo$25bo37bo$23b3o36b2o53b2o$117b2o3$41bo
$39b3o$38bo$38b2o$23b2o$24bo$24bob2o$25bo2bo96bobobobobobobobobobobobo
bobobobobobobobo$26b2o$41b2o13b2o$41b2o13b2o2$106b2o$106bobo17bobobobo
bobobobobobobobobobobobobobobobo$107bo9b2o$80b2o34bo2bo$80b2o35b2o$44b
2obo6b2o$44b2ob3o3bobo$50bo2bo$44b2ob3o2b2o26b2o25bo$45bobo32b2o23b3o$
33b2o10bobo18b2o36bo15b2o$33b2o11bo18bobo36b2o14bo$65bo55b3o$64b2o8b2o
47bo$74bo$75b3o$77bo2$94b2o$93bobo5b2o$93bo7b2o$92b2o2$106bo$102b2obob
o$101bobobobo$98bo2bobobobob2o$98b4ob2o2bo2bo$102bo4b2o$100bobo$100b2o
!

This also limited the search space to the point where searching by hand became somewhat viable.

As there wasn't an "obvious" choice of target, not wanting to overly limit myself, I decided to develop a target notation system for some common objects and constellations, to use as stepping stones in the development of various operators. For example, here is the (very simple) step bk11-lf07a':

Code: Select all

x = 18, y = 9, rule = B3/S23
2bo$o3bo$5bo$o4bo$b5o3$16b2o$16b2o!

Pretty straightforwardly, the step bk11-lf07a' converts the target bk11 to the target lf07a'. Assuming eastbound MWSSs, let's break down this notation for the latter case:

Code: Select all

[lf][07][a][']

1. "lf" is a two-letter abbreviation that refers to the type of target being used, in this case, a loaf. For these abbreviations, I've been using Niemiec's shorthand for synthesis filenames, but without the bitcount.
2. "07" refers to the lane the target appears on. Lanes are numbered starting from 01, the northernmost placement per target and orientation, but for any phase, that the MWSS still affects, incrementing for every cell southward the target is moved, until the MWSS completely misses the target on the other side. As the MWSS is glide-symmetric and has speed 2c/4, in order to avoid duplicate targets, I add the restriction that the western edge of the target's bounding box over all phases aligns vertically with a northbound spark from the MWSS.
3. "a" refers to the phase and/or orientation of the target. Which phase/orientation receives which designation is actually rather arbitrary, but I tend to order the wider phases/orientations first. If all phases/orientations are identical by symmetry, omit this section.
4. If the resulting target ends up aligning with a southbound spark instead of a northbound spark, because of the MWSS's glide-symmetry, I remeasure the lane and orientation from south to north instead, adding a prime (') on the end to indicate this. (I generally try to avoid starting a step with a primed entry.)
5. If the resulting target cannot be modified any further because of dying out or being in the wrong place, I simply label it as X.
6. I don't track horizontal distance beyond mod 2/priming.

For further clarity, the first of every phase and orientation for some targets:

Code: Select all

x = 113, y = 617, rule = B3/S23
100b3o2$o7bo4b3o4bo18bo4bo5bo4bo30bo$o7bo3bo3bo2b2o17bo4b2o4b2o5bo27bo
3bo$ob2o4bo3bo2b2o3bo4b2obo8bo6bo5bo6bo31bo$2o2bo3bo3bobobo3bo3bo2b2o
8bo6bo5bo6bo26bo4bo$o3bo3bo3b2o2bo3bo3bo3bo8bo6bo5bo6bo27b5o$2o2bo3bo
3bo3bo3bo3bo2b2o9bo5bo5bo5bo$ob2o5bo3b3o3b3o3b2obo10bo3b3o3b3o3bo23$
101bo$101bo$101bo$o7bo4b3o4bo3bo14bo4bo5bo4bo30bo$o7bo3bo3bo2b2o3bo13b
o4b2o4b2o5bo27bo3bo$ob2o4bo3bo2b2o3bo3bob2o9bo6bo5bo6bo31bo$2o2bo3bo3b
obobo3bo3b2o2bo8bo6bo5bo6bo26bo4bo$o3bo3bo3b2o2bo3bo3bo3bo8bo6bo5bo6bo
27b5o$2o2bo3bo3bo3bo3bo3b2o2bo9bo5bo5bo5bo$ob2o5bo3b3o3b3o2bob2o11bo3b
3o3b3o3bo23$100b2o$100b2o2$o5bo6b3o4bo12bo4bo4b3o3bo36bo$o5bo5bo3bo2b
2o11bo4b2o3bo3bo3bo33bo3bo$ob2o2bo3bobo2b2o3bo10bo6bo7bo4bo37bo$2o2bob
ob2o2bobobo3bo10bo6bo6bo5bo32bo4bo$o3bob2o4b2o2bo3bo10bo6bo5bo6bo33b5o
$2o2bobob2o2bo3bo3bo11bo5bo4bo6bo$ob2o2bo3bo2b3o3b3o11bo3b3o2b5o2bo23$
101bo$100bobo$101bo$bo4bo6b3o4bo12bo4bo5bo4bo36bo$bo4bo5bo3bo2b2o11bo
4b2o4b2o5bo33bo3bo$4o2bob2o2bo2b2o3bo10bo6bo5bo6bo37bo$bo4b2o2bobobobo
3bo10bo6bo5bo6bo32bo4bo$bo4bo3bob2o2bo3bo10bo6bo5bo6bo33b5o$bo2bob2o2b
obo3bo3bo11bo5bo5bo5bo$2b2o2bob2o3b3o3b3o11bo3b3o3b3o3bo23$100b2o$100b
obo$101bo$o6bo5b3o4bo18bo4bo4b3o3bo30bo$o6bo4bo3bo2b2o17bo4b2o3bo3bo3b
o27bo3bo$ob2o2b4o2bo2b2o3bo4b2obo8bo6bo7bo4bo31bo$2o2bo2bo4bobobo3bo3b
o2b2o8bo6bo6bo5bo26bo4bo$o3bo2bo4b2o2bo3bo3bo3bo8bo6bo5bo6bo27b5o$2o2b
o2bo2bobo3bo3bo3bo2b2o9bo5bo4bo6bo$ob2o4b2o3b3o3b3o3b2obo10bo3b3o2b5o
2bo23$101b2o$100bobo$101bo$o6bo5b3o4bo3bo14bo4bo4b3o3bo30bo$o6bo4bo3bo
2b2o3bo13bo4b2o3bo3bo3bo27bo3bo$ob2o2b4o2bo2b2o3bo3bob2o9bo6bo7bo4bo
31bo$2o2bo2bo4bobobo3bo3b2o2bo8bo6bo6bo5bo26bo4bo$o3bo2bo4b2o2bo3bo3bo
3bo8bo6bo5bo6bo27b5o$2o2bo2bo2bobo3bo3bo3b2o2bo9bo5bo4bo6bo$ob2o4b2o3b
3o3b3o2bob2o11bo3b3o2b5o2bo22$101bo$100bobo$101b2o2$o6bo5b3o4bo18bo4bo
4b3o3bo30bo$o6bo4bo3bo2b2o17bo4b2o3bo3bo3bo27bo3bo$ob2o2b4o2bo2b2o3bo
4b3o9bo6bo7bo4bo31bo$2o2bo2bo4bobobo3bo3bo3bo8bo6bo6bo5bo26bo4bo$o3bo
2bo4b2o2bo3bo3bo12bo6bo5bo6bo27b5o$2o2bo2bo2bobo3bo3bo3bo3bo9bo5bo4bo
6bo$ob2o4b2o3b3o3b3o3b3o11bo3b3o2b5o2bo22$101bo$100bobo$100b2o2$o6bo5b
3o4bo7bo10bo4bo4b3o3bo30bo$o6bo4bo3bo2b2o7bo9bo4b2o3bo3bo3bo27bo3bo$ob
2o2b4o2bo2b2o3bo4b2obo8bo6bo7bo4bo31bo$2o2bo2bo4bobobo3bo3bo2b2o8bo6bo
6bo5bo26bo4bo$o3bo2bo4b2o2bo3bo3bo3bo8bo6bo5bo6bo27b5o$2o2bo2bo2bobo3b
o3bo3bo2b2o9bo5bo4bo6bo$ob2o4b2o3b3o3b3o3b2obo10bo3b3o2b5o2bo22$100b2o
$100bobo$101b2o2$6bo6b3o4bo18bo4bo4b3o3bo30bo$6bo5bo3bo2b2o17bo4b2o3bo
3bo3bo27bo3bo$b4obob2o2bo2b2o3bo4b2obo8bo6bo7bo4bo31bo$o5b2o2bobobobo
3bo3bo2b2o8bo6bo5b2o5bo26bo4bo$b3o2bo3bob2o2bo3bo3bo3bo8bo6bo7bo4bo27b
5o$4bobo3bobo3bo3bo3bo2b2o9bo5bo3bo3bo3bo$4o2bo3bo2b3o3b3o3b2obo10bo3b
3o3b3o3bo22$101b2o$100bobo$100b2o2$6bo6b3o4bo3bo14bo4bo4b3o3bo30bo$6bo
5bo3bo2b2o3bo13bo4b2o3bo3bo3bo27bo3bo$b4obob2o2bo2b2o3bo3bob2o9bo6bo7b
o4bo31bo$o5b2o2bobobobo3bo3b2o2bo8bo6bo5b2o5bo26bo4bo$b3o2bo3bob2o2bo
3bo3bo3bo8bo6bo7bo4bo27b5o$4bobo3bobo3bo3bo3b2o2bo9bo5bo3bo3bo3bo$4o2b
o3bo2b3o3b3o2bob2o11bo3b3o3b3o3bo22$101b2o$100bo2bo$101b2o2$o12b3o4bo
18bo4bo4b3o3bo30bo$o11bo3bo2b2o17bo4b2o3bo3bo3bo27bo3bo$ob2o2bo3bobo2b
2o3bo4b2obo8bo6bo7bo4bo31bo$2o2bobo3bobobobo3bo3bo2b2o8bo6bo5b2o5bo26b
o4bo$o3bobo3bob2o2bo3bo3bo3bo8bo6bo7bo4bo27b5o$o3bo2bobo2bo3bo3bo3bo2b
2o9bo5bo3bo3bo3bo$o3bo3bo4b3o3b3o3b2obo10bo3b3o3b3o3bo22$101bo$100bobo
$100bobo$101bo$o12b3o4bo3bo14bo4bo4b3o3bo30bo$o11bo3bo2b2o3bo13bo4b2o
3bo3bo3bo27bo3bo$ob2o2bo3bobo2b2o3bo3bob2o9bo6bo7bo4bo31bo$2o2bobo3bob
obobo3bo3b2o2bo8bo6bo6bo5bo26bo4bo$o3bobo3bob2o2bo3bo3bo3bo8bo6bo5bo6b
o27b5o$o3bo2bobo2bo3bo3bo3b2o2bo9bo5bo4bo6bo$o3bo3bo4b3o3b3o2bob2o11bo
3b3o2b5o2bo22$101b2o$100bo2bo$100bobo$101bo$2bo5b2o3b3o4bo18bo4bo4b3o
3bo30bo$2bo4bo2bobo3bo2b2o17bo4b2o3bo3bo3bo27bo3bo$2bo4bo4bo2b2o3bo4b
2obo8bo6bo7bo4bo31bo$2bo3b3o3bobobo3bo3bo2b2o8bo6bo5b2o5bo26bo4bo$2bo
4bo4b2o2bo3bo3bo3bo8bo6bo7bo4bo27b5o$2bo4bo4bo3bo3bo3bo2b2o9bo5bo3bo3b
o3bo$3bo3bo5b3o3b3o3b2obo10bo3b3o3b3o3bo22$101b2o$100bo2bo$101bobo$
102bo$2bo5b2o3b3o4bo3bo14bo4bo4b3o3bo30bo$2bo4bo2bobo3bo2b2o3bo13bo4b
2o3bo3bo3bo27bo3bo$2bo4bo4bo2b2o3bo3bob2o9bo6bo7bo4bo31bo$2bo3b3o3bobo
bo3bo3b2o2bo8bo6bo5b2o5bo26bo4bo$2bo4bo4b2o2bo3bo3bo3bo8bo6bo7bo4bo27b
5o$2bo4bo4bo3bo3bo3b2o2bo9bo5bo3bo3bo3bo$3bo3bo5b3o3b3o2bob2o11bo3b3o
3b3o3bo21$102bo$101bobo$100bo2bo$101b2o2$2bo5b2o3b3o4bo18bo4bo4b3o3bo
30bo$2bo4bo2bobo3bo2b2o17bo4b2o3bo3bo3bo27bo3bo$2bo4bo4bo2b2o3bo4b3o9b
o6bo7bo4bo31bo$2bo3b3o3bobobo3bo3bo3bo8bo6bo5b2o5bo26bo4bo$2bo4bo4b2o
2bo3bo3bo12bo6bo7bo4bo27b5o$2bo4bo4bo3bo3bo3bo3bo9bo5bo3bo3bo3bo$3bo3b
o5b3o3b3o3b3o11bo3b3o3b3o3bo21$101bo$100bobo$100bo2bo$101b2o2$2bo5b2o
3b3o4bo7bo10bo4bo4b3o3bo30bo$2bo4bo2bobo3bo2b2o7bo9bo4b2o3bo3bo3bo27bo
3bo$2bo4bo4bo2b2o3bo4b2obo8bo6bo7bo4bo31bo$2bo3b3o3bobobo3bo3bo2b2o8bo
6bo5b2o5bo26bo4bo$2bo4bo4b2o2bo3bo3bo3bo8bo6bo7bo4bo27b5o$2bo4bo4bo3bo
3bo3bo2b2o9bo5bo3bo3bo3bo$3bo3bo5b3o3b3o3b2obo10bo3b3o3b3o3bo21$101b2o
$100bo2bo$100bo2bo$101b2o2$10bo2b3o4bo12bo4bo6bo3bo36bo$10bobo3bo2b2o
11bo4b2o5b2o4bo33bo3bo$ob2o3b2obobo2b2o3bo10bo6bo4bobo5bo37bo$2o2bobo
2b2obobobo3bo10bo6bo3bo2bo5bo32bo4bo$o3bobo3bob2o2bo3bo10bo6bo3b5o4bo
33b5o$2o2bobo2b2obo3bo3bo11bo5bo6bo4bo$ob2o3b2obo2b3o3b3o11bo3b3o5bo3b
o$o$o15$104bo$104bo$104bo2$100b3o3b3o2$104bo$104bo$104bo$bo6bo4b3o4bo
18bo4bo3b5o2bo30bo$bo6bo3bo3bo2b2o17bo4b2o7bo3bo27bo3bo$4o4bo3bo2b2o3b
o4b2obo8bo6bo6bo5bo31bo$bo6bo3bobobo3bo3bo2b2o8bo6bo6bo5bo26bo4bo$bo6b
o3b2o2bo3bo3bo3bo8bo6bo5bo6bo27b5o$bo2bo3bo3bo3bo3bo3bo2b2o9bo5bo5bo5b
o$2b2o5bo3b3o3b3o3b2obo10bo3b3o4bo4bo18$103b3o2$101bo5bo$101bo5bo$101b
o5bo2$103b3o2$bo6bo4b3o4bo3bo14bo4bo3b5o2bo30bo$bo6bo3bo3bo2b2o3bo13bo
4b2o7bo3bo27bo3bo$4o4bo3bo2b2o3bo3bob2o9bo6bo6bo5bo31bo$bo6bo3bobobo3b
o3b2o2bo8bo6bo6bo5bo26bo4bo$bo6bo3b2o2bo3bo3bo3bo8bo6bo5bo6bo27b5o$bo
2bo3bo3bo3bo3bo3b2o2bo9bo5bo5bo5bo$2b2o5bo3b3o3b3o2bob2o11bo3b3o4bo4bo
13$106bo$105bobo$105bobo$106bo2$101b2o7b2o$100bo2bo5bo2bo$101b2o7b2o2$
106bo$105bobo$105bobo$106bo$o7b2o3b3o4bo12bo3b3o4bo4bo36bo$o6bo2bobo3b
o2b2o11bo3bo3bo2b2o5bo33bo3bo$ob2o3bo4bo2b2o3bo10bo8bo3bo6bo37bo$2o2bo
b3o3bobobo3bo10bo7bo4bo6bo32bo4bo$o3bo2bo4b2o2bo3bo10bo6bo5bo6bo33b5o$
o3bo2bo4bo3bo3bo11bo4bo6bo5bo$o3bo2bo5b3o3b3o11bo2b5o2b3o3bo!

The first complete operation I found was this INC6+PARITY (from bl01b), measured in what one might call "full orthogonals", to mirror the concept of full diagonals for gliders:

Code: Select all

x = 190, y = 13, rule = B3/S23
189bo$189bo$189bo$2bo53bo117bo$o3bo49bo3bo113bo3bo$5bo53bo48b2o67bo$o
4bo48bo4bo2bobobobobobobobobobobobobobobobobobobobobo2b3ob2o61bo4bo$b
5o49b5o45b5o63b5o$106b3o4$8b2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob
2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2o!

Any operations involving half orthogonals must also reflect across the axis of glide symmetry. (I use dashes of length n to signify delays adjustable by multiples of n, assuming the previous reaction has time to settle.)

An earlier result was this partial operation that releases a sideways LWSS (from tl07b):

Code: Select all

x = 135, y = 8, rule = B3/S23
130b3o2$57bo55bo14bo5bo$55bo3bo51bo3bo12bo5bo$3b2o55bo55bo11bo5bo$3ob
2o2b2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2ob2o3bo4bo3b2ob2ob2ob2ob2o
b2ob2ob2ob2ob2ob2ob2ob2ob2ob2o3bo4bo$5o51b5o51b5o13b3o$b3o!

Some final notes on the search itself:

• While the G-to-MWSS has repeat time 90, I started my hand search from a minimum delay of 72, the repeat time for the underlying H-to-MWSS, to allow for possible improvements in the delivery mechanism. I set the maximum delay between consecutive MWSSs at 328, i.e. 256 above the minimum. However, I set no such limit for the total delay between the first and last MWSSs.
• I did most of my searches at depth two (i.e. firing salvos of at most two MWSSs at the target before letting the result stabilize), with occasional extensions to depth three if a reaction reduces to a small active object near the firing line. However, I never set an explicit limit on the number of salvos until a preset target is reached again, with one case requiring seven. (On the other hand, most of these salvos were of depth one, as the result often settled before a second MWSS could reach the reaction.) Under these restrictions, I still managed to collect a pretty good variety of results.
• Crystals can form with the correct spacing of MWSSs.
• When trying to assemble a complete operation, I ignore phase, as one can just wait for an extra generation if the other phase is needed. Distance beyond mod 2 is also ignored.
• Some Xs that are complete eliminations can still be useful for target variations with extra debris behind the original target.

[MathAndCode]

It's good to see that the Life community is finally getting around to developing better single-direction XWSS construction. Have you considered using the fact that the MWSS's dot spark allows one MWSS to activate several reactions to help with synchronization (think a one-cell seed for a glider, possibly with objects left behind to serve as a new elbow).
A more permanent Heisenburp could be useful for an orthogonal loopship where the construction recipe must be split, with one copy being used to construct the next part and one copy saved for constructing everything after that. I think that Kazyan is working on a dot spark→something converter based on a transparent beehive, although getting that particular dot spark acceptor to work with MWSSes is not possible.

Code: Select all

x = 13, y = 15, rule = B3/S23
2o$bo6b5o$bobo3bo4bo$2b2o8bo$6bo4bo$5bobo$5bobo$6bo5$7b2o$6bo2bo$7b2o!

I'm sure that other dot spark acceptors, including some compatible with MWSSes, could be created.

Also, about the target, obviously being able to use any previous debris would be most efficient, but since starting from one target is more practical, I propose using a target that can be created by a collision between one MWSS and one glider, or if that isn't feasible, that can be created relatively easily and quickly using one lane of MWSSes and one lane of gliders. This will be useful for my idea for a self-constructing spaceship (which I plan to start once this is finished) and likely other instances of self-construction.

[Extrementhusiast]

I ended up settling on using bk04a as the "default" target, as there are a multitude of target variations that give the same overall result (much like the glider+block->pi collision, but perhaps even more so), and I found ways to change it to other small targets. Here are some results that have come from this:

PULL5:

Code: Select all

x = 621, y = 7, rule = B3/S23
281bo189bo133bo13b2o$279bo3bo185bo3bo50b3o76bo3bo11b2o$3b2o160b2o68b5o
44bo40b5o47b5o43b2o47bo48b5o80bo$3ob2o156b3ob2o66bo4bo39bo4bo39bo4bo
46bo4bo40b3ob2o41bo4bo48b3ob2o74bo4bo$5o157b5o72bo40b5o44bo51bo40b5o
43b5o51b2o76b5o$b3o159b3o68bo3bo85bo3bo47bo3bo42b3o$236bo89bo51bo!

PUSH3.5:

Code: Select all

x = 697, y = 7, rule = B3/S23
439bo107bo133bo13b2o$104b3o330bo3bo103bo3bo50b3o76bo3bo11b2o$b5o43b2o
52b5o57b5o43b2o72b5o43b2o105bo46b5o56bo48b5o80bo$o4bo40b3ob2o51b3ob2o
55bo4bo40b3ob2o70bo4bo40b3ob2o99bo4bo45bo4bo51bo4bo48b3ob2o74bo4bo$5bo
40b5o55b2o61bo40b5o76bo40b5o101b5o50bo52b5o51b2o76b5o$o3bo42b3o114bo3b
o42b3o72bo3bo42b3o152bo3bo$2bo163bo121bo201bo!

PULL20+LWSS (of one of four possible parities):

Code: Select all

x = 1959, y = 7, rule = B3/S23
87bo89bo167bo99bo91bo135bo153bo89bo185bo225bo89bo447bo75bo13b2o$85bo3b
o85bo3bo163bo3bo95bo3bo87bo3bo42b3o86bo3bo58b3o88bo3bo85bo3bo42b3o136b
o3bo132b3o86bo3bo85bo3bo42b3o137b3o59b3o196bo3bo71bo3bo11b2o$3b2o85bo
40b5o44bo118b5o44bo52b2o45bo44b2o45bo40b5o43b2o45bo56b5o41b5o46bo40b5o
44bo40b5o43b2o48b2o45bo40b5o43b2o40b5o43b2o45bo40b5o44bo40b5o45b5o43b
2o40b5o57b5o43b2o46b5o104bo75bo$3ob2o79bo4bo39bo4bo39bo4bo117bo4bo39bo
4bo49b3ob2o39bo4bo41b3ob2o39bo4bo40b3ob2o39b3ob2o39bo4bo56b3ob2o39bo4b
o41bo4bo39bo4bo39bo4bo40b3ob2o39b3ob2o44b3ob2o39bo4bo39bo4bo40b3ob2o
39b3ob2o39b3ob2o39bo4bo39bo4bo39bo4bo40b3ob2o43bo4bo40b3ob2o39b3ob2o
56b3ob2o39b3ob2o44bo4bo99bo4bo70bo4bo$5o81b5o44bo40b5o122bo40b5o49b5o
41b5o41b5o41b5o43b2o40b5o41b5o59b2o45bo42b5o44bo40b5o43b2o40b5o45b5o
41b5o44bo40b5o43b2o40b5o41b5o44bo40b5o43b2o49bo40b5o43b2o60b2o40b5o50b
o100b5o71b5o$b3o126bo3bo163bo3bo96b3o89b3o133b3o148bo3bo87bo3bo132b3o
47b3o86bo3bo42b3o87b3o86bo3bo135bo3bo42b3o149b3o46bo3bo$132bo167bo479b
o91bo275bo225bo139bo247bo!

There was also this more efficient PULL14, but it is unusable alone with the PUSH3.5 over divisibility constraints:

Code: Select all

x = 499, y = 7, rule = B3/S23
107bo299bo75bo13b2o$105bo3bo96b3o196bo3bo71bo3bo11b2o$b5o55b5o44bo40b
5o49b5o43b2o46b5o104bo75bo$o4bo54bo4bo39bo4bo39bo4bo49b3ob2o39b3ob2o
44bo4bo99bo4bo70bo4bo$5bo59bo40b5o44bo52b2o40b5o50bo100b5o71b5o$o3bo
55bo3bo85bo3bo96b3o46bo3bo$2bo59bo89bo149bo!

(I elected to go for minimum separation instead of dashing.)

Also, a rather messy Python script to run such a depth-2 search:

Code: Select all

import golly as g

g.new("work")
g.setalgo("QuickLife")
g.setrule("B3/S23")
work_layer = g.getlayer()
results_layer = g.addlayer()
g.setname("results")
g.update()
g.setlayer(work_layer)

# display parameters
x_spacing = 256
y_spacing = 64

# search parameters
min_delay = 90
num_delays = 256
num_salvos = 5
max_population = 36
max_semiwidth = 16
max_length = 50
initial_targets = ["13$2o$2o!"] # assumes RLE starts from max_semiwidth
base = 2
exponent = 4
runtime = 2 ** 10
gaptime = 5 * 2 ** 8
if gaptime % 2 != 0:
	g.exit("gaptime must be divisible by 2.")

target_cells = [[] for i in range(num_salvos)] # actual cell lists
target_hashes = [[] for i in range(num_salvos)]
previous = [{} for i in range(num_salvos)]
# standardize target_hashes[0]
for t in initial_targets:
	g.setstep(0)
	g.putcells(g.transform(g.parse(t),0,-max_semiwidth))
	these_rects = [[0,0,1,1] for i in range(3)]
	these_hashes = [0 for i in range(3)]
	these_cells = [[] for i in range(3)]
	for i in range(2):
		these_rects[i] = g.getrect()
		g.step()
	
	intervals = [[min([these_rects[j][i] for j in range(2)]),max([these_rects[j][i] + these_rects[j][i + 2] for j in range(2)]) - 1] for i in range(2)]
	final_rect = [intervals[0][0],-max_semiwidth,intervals[0][1] - intervals[0][0] + 1,2 * max_semiwidth + 1]
	g.select(final_rect)
	if intervals[0][0] % 2 == 1:
		g.flip(1)
	
	these_cells[0] = g.transform(g.getcells(final_rect),-intervals[0][0],0)
	these_hashes[0] = g.hash(final_rect)
	g.step()
	these_cells[1] = g.transform(g.getcells(final_rect),-intervals[0][0],0)
	these_hashes[1] = g.hash(final_rect)
	
	for i in range(2):
		if these_hashes[i] not in target_hashes[0]:
			target_cells[0] += [these_cells[i]]
			target_hashes[0] += [these_hashes[i]]
	g.new("")
MWSS = [g.parse("2bo$o3bo$5bo$o4bo$b5o!"),g.parse("$b3o$5o$3ob2o$3b2o!"),g.parse("2$b5o$o4bo$5bo$o3bo$2bo!"),g.parse("2$3b2o$3ob2o$5o$b3o!")]
x_offset = 0
y_offset = 0

for depth in range(num_salvos): # depth index
	for target in range(len(target_cells[depth])): # target index for given depth
		keep = [False for i in range(num_delays + 1)]
		duplicate = [True for i in range(num_delays + 1)]
		box_hash_list = [[[0,0,0,0,0],[0,0,0,0,0]] for i in range(num_delays + 1)] # usual box four, hash
		miss = False
		# any pre-setup needed
		for delay in range(min_delay - 1,min_delay + num_delays):
			g.show("Analyzing depth-" + str(depth + 1) + " result #" + str(target + 1) + " of " + str(len(target_cells[depth])) + ", delay " + str(delay) + "....")
			
			# initialize starting pattern
			g.new("")
			g.setbase(base)
			g.setstep(exponent)
			g.putcells(target_cells[depth][target],16,0)
			g.putcells(MWSS[0],0,-3)
			if delay >= min_delay: # otherwise gives single-MWSS case
				g.putcells(MWSS[delay % 4],-(delay / 2),-3)
			
			# run pattern
			for i in range(runtime / (base ** exponent)):
				g.step()
			g.select([(runtime + 1) / 2,-3,6,7])
			g.shrink(True)
			if len(g.getselrect()) > 0: # first MWSS misses
				miss = True
				break
			
			# evaluate result
			these_rects = [[0,0,1,1] for i in range(3)]
			these_hashes = [0 for i in range(3)]
			these_pops = [0 for i in range(3)]
			these_cells = [[] for i in range(3)]
			g.setstep(0)
			if not g.empty():
				these_rects[0] = g.getrect()
			these_hashes[0] = g.hash(these_rects[0])
			box_hash_list[delay - min_delay + 1][0] = [these_rects[0][i] for i in range(4)] + [g.hash(these_rects[0])]
			these_pops[0] = int(g.getpop())
			g.step() # gives noop if empty pattern
			if not g.empty():
				these_rects[1] = g.getrect()
			these_hashes[1] = g.hash(these_rects[1])
			these_pops[1] = int(g.getpop())
			g.step() # gives noop if empty pattern
			if not g.empty():
				these_rects[2] = g.getrect()
			these_hashes[2] = g.hash(these_rects[2])
			box_hash_list[delay - min_delay + 1][1] = [these_rects[2][i] for i in range(4)] + [g.hash(these_rects[2])]
			these_pops[2] = int(g.getpop())
			
			intervals = [[min([these_rects[j][i] for j in range(3)]),max([these_rects[j][i] + these_rects[j][i + 2] for j in range(3)]) - 1] for i in range(2)] # final bounding box ranges
			if max(these_pops) <= max_population and these_hashes[0] == these_hashes[2] and intervals[1][0] >= -max_semiwidth and intervals[1][1] <= max_semiwidth and intervals[0][1] - intervals[0][0] + 1 <= max_length:
				keep[delay - min_delay + 1] = True
				if delay >= min_delay + 2 and box_hash_list[delay - min_delay + 1][1][0] == box_hash_list[delay - min_delay - 1][0][0] and box_hash_list[delay - min_delay + 1][1][1] == box_hash_list[delay - min_delay - 1][0][1] and box_hash_list[delay - min_delay + 1][1][2] == box_hash_list[delay - min_delay - 1][0][2] and box_hash_list[delay - min_delay + 1][1][3] == box_hash_list[delay - min_delay - 1][0][3] and box_hash_list[delay - min_delay + 1][1][4] == box_hash_list[delay - min_delay - 1][0][4]:
					keep[delay - min_delay + 1] = False
					continue
				# evaluate subsequent target
				if g.empty() or depth == num_salvos - 1: # don't store nonexistent or unnecessary targets
					continue
				final_rect = [intervals[0][0],-max_semiwidth,intervals[0][1] - intervals[0][0] + 1,2 * max_semiwidth + 1]
				g.select(final_rect)
				if intervals[0][0] % 2 == 1:
					g.flip(1)
				these_cells[0] = g.transform(g.getcells(final_rect),-intervals[0][0],0)
				these_hashes[0] = g.hash(final_rect)
				g.step()
				these_cells[1] = g.transform(g.getcells(final_rect),-intervals[0][0],0)
				these_hashes[1] = g.hash(final_rect)
				for i in range(2):
					unique = True
					for j in range(depth + 2):
						unique = unique and (these_hashes[i] not in target_hashes[j])
					if unique:
						target_cells[depth + 1] += [these_cells[i]]
						target_hashes[depth + 1] += [these_hashes[i]]
						previous[depth][len(target_hashes[depth + 1]) - 1] = [target,delay,i]
						duplicate[delay - min_delay + 1] = False
		if miss:
			continue
		g.setlayer(results_layer)
		for delay in range(min_delay - 1,min_delay + num_delays):
			if keep[delay - min_delay + 1]:
				past_info = [[target,delay,0]]
				for i in range(depth):
					past_info = [previous[depth - i - 1][past_info[0][0]]] + past_info
				parity = 0
				g.putcells(target_cells[0][past_info[0][0]],16 + x_spacing * x_offset,y_spacing * y_offset)
				for i in range(depth + 1):
					g.putcells(MWSS[(gaptime + parity) % 4],-i * gaptime / 2 + x_spacing * x_offset,-3 + y_spacing * y_offset)
					if past_info[i][1] >= min_delay: # otherwise gives single-MWSS case
						g.putcells(MWSS[(gaptime + past_info[i][1] + parity) % 4],-i * gaptime / 2 - ((past_info[i][1] + parity) / 2) + x_spacing * x_offset,-3 + y_spacing * y_offset)
					parity = (parity + past_info[i][2]) % 2
				if duplicate[delay - min_delay + 1]:
					g.setcell(x_spacing * (x_offset + 1),y_spacing * y_offset,1)
				y_offset += 1
		g.fit()
		g.update()
		g.setlayer(work_layer)
g.show("")
g.setlayer(results_layer)
g.fit()
g.update()

[MathAndCode]

I ended up settling on using bk04a as the "default" target, as there are a multitude of target variations that give the same overall result (much like the glider+block->pi collision, but perhaps even more so), and I found ways to change it to other small targets. Here are some results that have come from this:

Yes, that two-glider octomino reaction looks very useful, which is understandable since it creates a fairly large cloud of ash without emitting any gliders. Have you found any good target-creating reactions?

[Roger]

Given the 'hammer' conversion of a MWSS to a LWSS, you might also want to look at mixed MWSS/LWSS salvos. Or, given a triggered HWSS gun and two triggered hammer conversions, even a full 3-type *WSS mixed salvo. Not sure what the repetition rate limits on those would be.

Another potential technology that might be worth investigating is a single lane *WSS salvo running parallel to a light-speed telegraph wire, assuming that we can also find or construct a c/2-o (presumably 5c/10-o) puffer that lays light-speed telegraph wire, a.k.a. a 'wire-stretcher' or 'wire-layer'. That also give you a purely orthogonal way to create an initial target, by sending a telegraph signal pulse chasing the wire-layer (and possible escorting c/2-o ships), much like the approach used in the speed demonoid. The c-speed signal pulse moving down the telegraph wire can move it either closer to or further from the *WSS lane, and move its 5-cell repetition units lengthwise, and the signal pulses have a dot spark at the side so can probably safely perturb some targets without the wire being destroyed. (Synchronizing the arrival of a c/2 *WSS and c signal pulse would either need to have the construction distance precompiled into the recipe or use a sizable delay loop, but that's a solvable problem.) That would also require a practical design for the glider synthesis that injects the signal pulses into the source end of the movable telegraph wire -- I'm not sure what the constraints are there, standardly in a lightspeed telegraph a fixed cycle of 10 signal pulse types is used, but for remote construction use you might want more variation and perhaps move the wire by wider distances. Obviously clearance between the wire and the *WSS lane at the source end is an interesting question, though the fact that the telegraph pulses can be sent well after the *WSS salvo and the telegraph wire is movable might provide a simple solution, as long as your construction distance is long compared to your total salvo length. Or there may be an easy solution based on interlacing the glider syntheses for both *WSS and telegraph wire signal pulses

[MathAndCode]

Given the 'hammer' conversion of a MWSS to a LWSS, you might also want to look at mixed MWSS/LWSS salvos. Or, given a triggered HWSS gun and two triggered hammer conversions, even a full 3-type *WSS mixed salvo. Not sure what the repetition rate limits on those would be.

While that would be more efficient per spaceship, I don't think that the greater number of spaceships required to build it would be worth it.

[Roger]

I guess it depends on whether you're trying to optimize construction rate, or simplicity of building the constructor. A more capable constructor can presumably build itself faster, which may or may not sufficiently compensate for it being inherently more complex. Overall, we're probably most often trying to optimize total recipe size (in cells or bounding box), so the optimum may depend whether you're just self-reproducing the constructor (in which case a simpler one is likely to be best), or also then using it to construct a lot of other circuitry (or at least to build a glider-based universal construction arm for further local construction), in which case a more efficient constructor that can encode information more densely into the *WSS recipe stream may win out overall. I don't think a triggered hammer adds that much to constructor complexity (four glider channels), and it adds another bit of information per *WSS (at least doubling the search space per *WSS), so I don't think it would take that long for that to win out. So long-term I think both toolkits might be useful. But I'm probably suggesting running before we can walk -- I applaud any advances towards achieving a c/2-o universal construction toolkit: optimizing it for maximum recipe density can wait, if that's all this adds.

However, I suspect we're going to find that *WSS are harder to work with than gliders (since they're bigger, so there's less incoming information per impacter cell, likely producing more ash during the construction and needing more clearance between the parts of whatever we're building): in some sense they're a 'blunter tool' -- imagine trying to do this with Sir Robins, if we had a signal converter for them and were trying to develop knight-move construction tech!) So we may find the extra bit or so of information packed in by having a choice of spaceship type is actually needed to keep cleanup costs under control during construction. But it may not be necessary, and it's certainly worth trying this first without the added complexity -- if we find we're spending most of the recipe on ash cleanup or that's causing runaways, so the corresponding 'c/2-o Spartan' requirements are too strict, this is an avenue to explore to see if it helps.

If this 'blunt tool' problem is as bad as I suspect, then it wouldn't surprise me if we find that *WSS construction is hard/limited enough that the right thing to do is to use it to build a slow widely-spaced glider-based universal constructor arm controlled by a *WSS-reciever, than use that to build a faster more compact glider-based universal constructer arm, then switch to that to build our main circuitry. Which is going to be a bit of a tour-de-force to compile recipes for.

On the speculative parallel light-speed telegraph wire idea I threw out above, I checked, and it can be glider-constructed at c/2-o by four simple rakes (two forward and two back, each individually made from five ships): one of the recent light-speed telegraph designs (see in LifeViewer at https://www.conwaylife.com/forums/view ... =50#p97188) rebuilds the transmitter and receiver ends of the wire that way each time it gets worn down by use. Here's a copy of that (unnecessarily spaced-out) set of rakes reconstructed from the transmitter, being chased down by a signal pulse (in one possible phase) -- it doesn't end well (though I'm reasonably sure one phase or another could be stabilized with a *WSS in the right place):

Code: Select all

x = 809, y = 470, rule = B3/S23
b4o5b2o$bo3bo3b2ob2o$bo8b4o$2bo2bo5b2o3$4b2o7bo$3bobo3b2o7b5o$3bo18bo
$3b3o13b3o$14b2o4bo$14b2o3$b4o26bo$bo3bo26b2o$bo17b4o8b2o$2bo2bo13bo3b
o$19bo$20bo2bo22bo$47b2o$46b2o3$61bo$62b2o$61b2o3$76bo$77b2o$76b2o3$91b
o$92b2o$91b2o3$106bo$107b2o$106b2o3$121bo$122b2o$121b2o3$136bo$137b2o
$136b2o3$151bo$152b2o$151b2o3$166bo$167b2o$166b2o3$181bo$182b2o$181b2o
3$196bo$197b2o$196b2o3$211bo$212b2o$211b2o3$226bo$227b2o$226b2o3$241b
o$242b2o$241b2o3$256bo$257b2o$256b2o3$271bo$272b2o$271b2o3$286bo$287b
2o$286b2o3$301bo$302b2o$301b2o3$316bo$317b2o$316b2o3$331bo$332b2o$331b
2o3$346bo$347b2o$346b2o3$361bo$362b2o$361b2o3$376bo$377b2o$376b2o3$391b
o$392b2o$391b2o3$406bo$407b2o$406b2o3$421bo$422b2o$421b2o3$436bo$437b
2o$436b2o3$451bo$452b2o$451b2o3$466bo$467b2o$466b2o3$481bo$482b2o$481b
2o3$496bo$497b2o$496b2o3$511bo$512b2o$511b2o3$526bo$527b2o107b2o$526b
2o92b2o13b2ob2o$619b4o13b4o$618b2ob2o14b2o$541bo77b2o$542b2o$541b2o81b
o21bo$626bo17b2o$622b2o2bo3bo14b2o$556bo64bo5bob3o2bo$557b2o61b2o2bob
o2b5obo$556b2o63b2o3bo5b2ob2o14bo$622b3o7bo2bo13b2o$650b2o$571bo61b2o
$572b2o46b2o$571b2o46b4o4b4o25bo$618b2ob2o4bo3bo22b2o$619b2o6bo27b2o$
586bo41bo2bo$587b2o$586b2o73bo$659b2o$660b2o$601bo$602b2o$601b2o63bo$
664b2o$665b2o$616bo$617b2o$616b2o53bo$669b2o$670b2o$631bo$632b2o$631b
2o43bo$674b2o$675b2o$646bo$647b2o$646b2o33bo$679b2o$680b2o$661bo$662b
2o$661b2o23bo$684b2o$685b2o$676bo$677b2o$676b2o$776b2o3b2o3b2o3b2o3b2o
3b2o3b2o$690b2o3b2o3b2o3b2o3b2o3b2o3b2o3b2o3b2o3b2o3b2o3b2o3b2o2b2o4b
4obo4b3o2bo2bobo2bobo2bobo2bobo2bobo2bobo2bo$684b2o3bo2bobo2bobo2bobo
2bobo2bobo2bobo2bobo2bobo2bobo2bobo2bobo2bobo2bob2o4b2obo2bo5bo3b2o3b
2o3b2o3b2o3b2o3b2o3b2o$683bobo4b2o3b2o3b2o3b2o3b2o3b2o3b2o3b2o3b2o3b2o
3b2o3b2o3b2o2b2o4b4o2bo$685bo78b2o3bobo$687b2o81bo$687bobo$669b2o16bo
$668bobo$670bo$682b2o$682bobo$654b2o26bo$653bobo$655bo$677b2o$677bobo
$639b2o36bo$638bobo$640bo$672b2o$672bobo$624b2o46bo$623bobo$625bo$667b
2o$667bobo$609b2o56bo$608bobo$610bo$662b2o$662bobo$594b2o66bo$593bobo
$595bo$657b2o$657bobo$579b2o38bo2bo5b2o27bo$578bobo37bo8b4o$580bo37bo
3bo3b2ob2o$618b4o5b2o23b2o$652bobo$564b2o86bo$563bobo57bobo$565bo56bo
3b2o$620b2obob3o8bo10b2o$620bo4b3o19bobo$549b2o69bo3bo15b2o5bo$548bob
o70b3o10bo7bo$550bo72bo10bobobo3bo$639b3o$619bo2bo$534b2o82bo$533bobo
82bo3bo$535bo82b4o13b4o$635bo3bo$635bo$519b2o115bo2bo$518bobo$520bo3$
504b2o$503bobo$505bo3$489b2o$488bobo$490bo3$474b2o$473bobo$475bo3$459b
2o$458bobo$460bo3$444b2o$443bobo$445bo3$429b2o$428bobo$430bo3$414b2o$
413bobo$415bo3$399b2o$398bobo$400bo3$384b2o$383bobo$385bo3$369b2o$368b
obo$370bo3$354b2o$353bobo$355bo3$339b2o$338bobo$340bo3$324b2o$323bobo
$325bo3$309b2o$308bobo$310bo3$294b2o$293bobo$295bo3$279b2o$278bobo$280b
o3$264b2o$263bobo$265bo3$249b2o$248bobo$250bo3$234b2o$233bobo$235bo3$
219b2o$218bobo$220bo3$204b2o$203bobo$205bo3$189b2o$188bobo$190bo3$174b
2o$173bobo$175bo3$159b2o$158bobo$160bo3$144b2o$143bobo$145bo3$129b2o$
128bobo$130bo3$114b2o$113bobo$115bo3$99b2o$98bobo$100bo3$84b2o$83bobo
$85bo3$69b2o$68bobo$70bo3$54b2o$53bobo$55bo3$20b2o17b2o$19b4o15bobo$2b
2o14b2ob2o17bo$b4o14b2o$2ob2o$b2o21b2o$25b2o2$26b2o$4b2o$3bobo3b3o$2b
2obo6b3o$3b2o9bo$4bo7b3o3$2b2o$b4o4b4o$2ob2o4bo3bo$b2o6bo$10bo2bo!

So a known c/2-o telegraph-wire-layer puffer exists (searching for/constructing an elementary 5c/10-o one might still be interesting, if one isn't already known, but the flotilla of rakes is likely to be easier to synthesize). If the four glider-producing rakes are well separated like the above (as they will be if fired from simple guns, as in the light-speed telegraph design), then a signal pulse chasing them is likely to cause a short break in the wire surrounded by ash (as above) rather than stopping all the rakes as well, but likely that can be fixed either by compacting the formation sufficiently to allow it to all catch fire or adding more well-chosen spaceships to the flotilla to act as a flying fuse -- it would be more elegant to use a line-layer that can be stopped completely when a signal catches it, leaving just an ash-cloud that could then be cleared down to a single target, with no escaping rakes, ships, or gliders, and no back-reflected burn or signal down the wire like the one that happens above. (Or ideally, find just the right set of escorting ships so that it all burns down to just a single target near the wire -- over-optimistic, I know.) Of course, then there's the question of building a seed or glider construction to fire this compact wire-laying flotilla, but it doesn't need to be a gun, and the flotilla can presumably be built up incrementally while it's flying. Fortunately there's to be a way to build the rakes in a mode where they don't fire gliders until the last ship is added to the group (the telegraph design does this), which should help. The closer together the flotilla is the harder it may be to build -- it needs to be near enough that the chasing signal pulse can set it all on fire, without that actually happening during its construction, which will be an interesting balancing act.

At a higher level, on the telegraph wire idea: obviously any sort of c/2-o wickstretcher and fuse (speed-demoid-style) is likely to be simpler if all you want is a c/2-o means of creating a suitable distant target for your *WSS-stream construction technology. The main appeal to me of the telegraph wire idea is also having a c/2-o way of laying a line for later sending lightspeed signals to what you're building, and of course that doesn't have to be directly integrated into your construction technology as a second arm in order to be usable once you have a universal constructor elbow set up at the far end, and the bandwidth of current telegraph-tech on the lightspeed wire is fairly limited. There are multiple ways of speeding it up using encodings based on signal timings, as we would be if we were using sparks off the telegraph wire as one arm of a construction toolkit, and the latter has the advantage of not needing a fancy receiver already built: we can presumably just use the sparks off the side of the bare wire. However wire-end erosion is a big problem without a proper receiver to rebuild the wire -- unstabilized, the far end of a bare wire tends to burn messily producing a lot of ash when signal pulses hit it, and can initiate various kinds of back-burn along the wire. In the telegraph this is stabilized by the receiver sending a stream of LWSS parallel to the wire to stabilize the far end of it to burn cleanly, though this still causes wire-end loss (a normal telegraph reciever uses a rake like the telegraph-line-layer to rebuild the line periodically). The required LWSS could have been pre-sent from the transmitter, correctly timed and placed for stabilizing the end of the movements the line will be making in the construction recipe, but that adds clearance problems both with what you're building and with any significant movements of the wire against the LWSS paralleling it, and if the wire is moving by more than one cell the needed LWSS will no longer be in a single lane, so that makes construction-arm use of the wire seem impractical. (You could could even periodically send a wide ready-for-triggering wire-rebuilding rake.) But if the wire isn't being repaired, you would need to lay enough extra wire past the construction site to allow for the wire-end erosion during construction, which is going to delay construction start by an amount proportional to the number of signal pulses in the recipe, and create a huge swath of ash, which arguably counteracts the advantage of the pulses moving at lightspeed. So all-in all unless there's some other simple way to stabilize the far end of the wire that the *WSS construction arm could build quickly (maybe a eater array of some sort along with a beehive catalyst?), that makes the use of the lightspeed wire as a second construction arm rather impractical unless the number of uses made of it is pretty limited, perhaps just during the initiation of construction, e.g. to create multiple well-separated targets for parallel *WSS streams. And of course that could be done via c/2-o wick-stretchers, just using one wick per signal sent, just as the speed demonoid does. If you wanted to create a significant but-not huge number of well separated elbows this could probably be done with side-sparks off one signal pulse or signal-pulse pair as it overtakes multiple parallel-traveling *WSS, but then the same could also probably be done with a single burning wick if it had suitable sparks. So I think I've mostly shot my own idea down.

Anyway, I should really get Golly set up so I can experiment and do something useful, and stop just armchair-speculating like a noob.

[dvgrn]

I guess it depends on whether you're trying to optimize construction rate, or simplicity of building the constructor. A more capable constructor can presumably build itself faster, which may or may not sufficiently compensate for it being inherently more complex.

Yup, that's exactly the trade-off. And you're absolutely right that there are likely to be universal constructor designs that can replicate themselves significantly faster, by building more complicated circuitry. Not sure that building *WSS hammer reactions is going to be one of those designs, but the details don't matter too much.

Once you're keeping track of the choice between MWSS and LWSS, or the choice between HWSS, MWSS, and LWSS -- or the choice between HWSS-even, HWSS-odd, MWSS-even, MWSS-odd, LWSS-even, and LWSS-odd! -- then probably what you really have is two or three or six separate data streams being combined at the universal constructor arm. Once you have that, you can also start looking at the possibility of *WSS streams offset by some amount. Even if you used only MWSSes, for example, it might turn out that two streams of MWSSes offset by just a lane or two or three, might allow for much more efficient construction than plain single-channel MWSSes.

This is certainly true for gliders. See the old 0hd and 10hd Demonoids -- those 0hd and 10hd streams are several times more efficient than single-channel technology. And the two-construction-arm approach used by Andrew Wade in the original Gemini was even more efficient than that.

But efficiency isn't always as important as being able to finish a project. Single-channel is so incredibly simple to work with that it's often what ends up getting used for really big ambitious projects like the Speed Demonoid or the 0E0P metacell.

Anyway, I should really get Golly set up so I can experiment and do something useful, and stop just armchair-speculating like a noob. :D

Well, but on the other hand, we do need good noob armchair-speculators around here every now and then! A lot of the really impressive recent advances in Life technology have come from newcomers showing up and not knowing that something was thought to be impossible or unworkable, and just doing it anyway.

[Roger]

Yup, that's exactly the trade-off. And you're absolutely right that there are likely to be universal constructor designs that can replicate themselves significantly faster, by building more complicated circuitry. Not sure that building *WSS hammer reactions is going to be one of those designs, but the details don't matter too much.

Once you're keeping track of the choice between MWSS and LWSS, or the choice between HWSS, MWSS, and LWSS -- or the choice between HWSS-even, HWSS-odd, MWSS-even, MWSS-odd, LWSS-even, and LWSS-odd! -- then probably what you really have is two or three or six separate data streams being combined at the universal constructor arm. Once you have that, you can also start looking at the possibility of *WSS streams offset by some amount. Even if you used only MWSSes, for example, it might turn out that two streams of MWSSes offset by just a lane or two or three, might allow for much more efficient construction than plain single-channel MWSSes.

This is certainly true for gliders. See the old 0hd and 10hd Demonoids -- those 0hd and 10hd streams are several times more efficient than single-channel technology. And the two-construction-arm approach used by Andrew Wade in the original Gemini was even more efficient than that.

But efficiency isn't always as important as being able to finish a project. Single-channel is so incredibly simple to work with that it's often what ends up getting used for really big ambitious projects like the Speed Demonoid or the 0E0P metacell.

All of that makes a lot of sense. I guess I was applying computer-science/physics instincts and trying to maximize bandwidth and information density -- but of course maximal information density is achieved via an incoming fast four-sided glider synthesis, and we're not building a glider-synthesis-based gun here.

I've been reading up on single-lane glider construction tech to try to appreciate why it's so easy to work with: is it basically the availability of slparse, combined with the way that it allows a single instruction tape path (so no issues with synchronizing multiple parallel streams as they get routed around corners) with all the data contained in signal timings but that can have gaps added to if so that it can be made to pass through itself? What I hadn't understood is that (within reasonable limits) speed of construction isn't a design constraint you're interested in: a single-channel glider stream feeding slow-salvo glider synthesis is already pretty slow, we need to just not slow it down further.

I assume all we really need in a single lane MWSS toolkit is a suitable set of elbow push/pull moves and at least a pair of 135-degree glider emitting moves (one per glider color, I presume?), then we've reduced the remaining problem to slow-salvo glider synthesis? So MWSS being a blunt tool isn't really a problem except that it may result in the moves being less efficient, because you're not using the MWSS directly as a constructor, just as a way to create a slow-salvo of gliders (which is already a pretty blunt tool). Hoping for an equivalent of a snark and snarkmaker/snarkbreaker for turning MWSS seems way too much, so presumable once we have some initial local construction done the business end of the final universal-construction arm is going to use single-lane gliders bouncing off snarks to and elbow that fires a slow-glider salvo?

So all we really need is some c/2-o tech capable of constructing creating a reflector that turns a single lane of MWSS into a single lane of gliders (plus an elbow block in that lane, obviously, which could presumabaly be created via a glider + well-spaced parallel *WSS collision if you didn't want to have to push it a long way), with a sufficiently short refresh time to support a relatively efficient set of single-glider-lane moves, and then feed that lane to a fairly standard (modulo possible increases in refresh time) single-lane glider feed to a glider-based construction arm? This could be the above MWSS toolkit, but any other c2-o construction tech would also do, as long as it could make that one specific MWSS-to-glider reflector -- a c/2-o fuse-puffer flying-seed for it would also work if someone posted one).

Incidentally, I originally got into Life in the early '70s thanks to Martin Gardner's "Mathematical Games", back when the Gosper glider gun was an amazing discovery and Life's universality was suspected but unproven (in fact that's what started my interest in computers, since doing Life by hand is a pain). I pretty-much hadn't been following events in Life for decades (until reading an obituary of Conway), and I'm amazed how far it's progressed in the meantime: it's almost like 2-dimensional nano-tech now (well, other than being deterministic, non-reversible, and non-conservative: anyone want to figure out rules for reversible unitary quantum cellular automata with conservation laws?)

I'm still rather taken with the fuse puffer idea, so let me throw out a pipe-dream for an entirely different c/2-o construction tech. Suppose you had a Spartan single-glider-seed for a small c/2-o fuse puffer, likely plus some accompanying *WSS, which when the right clean-burning-fuse signal reaches it (many fuses support more than one burn mode) burns up cleanly creating just a single forward or backward glider. I have no idea if these exist, or how hard they would be to find or construct (if you only have one that doesn't burn up cleanly, it might still be usable, but you'd have a lot more cleanup to do and a lot of constraints on glider lanes for combinations of them). You fire a well-spaced flotilla of these, spaced so they're not running into each other's fuses, and launched from well spaced seeds, and while they're flying you build the circuitry around their fenceposts so that at the right set of times you can ignite each of their fuses in the desired burn pattern. They fly out at c/2-o, their fuse burns catch up, and they all turn into gliders, arranged and timed so these are converging on a particular area (so they form a sort of one-shot rake -- or maybe that would be a flying seed?). Using 2g->g glider-turning reactions you can make a 2-sided glider slavo into a 4-sided one. Now you can do a four-sided glider synthesis on your target patch -- not necessarily with very close timings, but probably with a lot closer timings than a slow salvo (and you can certainly do a 4-sides slow-ish salvo spread over as many lanes as you like). That should be able to build a MWSS-lane-to-glider-lane conduit plus an elbow for the glider lane. It doesn't have to be a universal constructor, this is more like a snark-maker. So while the setup to launch all this is really complex, that only has to be designed once.

More generally, this sort of one-shot rake/flying seed tech, if it were possible, would probably let you gradually build up a fairly general set of c/2-o flying seeds for all sorts of moderate-sized things (at a minimum, anything constructible by a wide 4-sided slow salvo): having a reasonable way to compile a c/2-o flying seed that allows you to do 4-sided slowish glider synthesis of a chosen moderate-sized pattern at a long distance could be a really powerful tech.

Once again, I seem to be prioritizing speed of construction over launcher simplicity, so this is probably a bad idea, but I've nearly talked myself into going off and researching c/2-o fuse stretchers and how they burn up.

EDIT: I've done a little hand experimenting so far. Using a blinker puffer 1 as the fuse-puffer, there are three different 2c/3 o fuse types that can cleanly burn its blinker line and catch it, and due to their relative periods and symmetries there are a total of 6 ways that can happen. By themselves none of those stop the blinker puffer 1 (some burn cleanly all the way including the collision point, some produce a couple of still lives of ash near it, but the blinker puffer 1 flies on puffing more fuse). However, by adding even a single close-following MWSS to the blinker puffer 1 flotilla you can ensure that it instead burns up when the fuse catches it: so far all the results I've found produce a significant puff of ash, and often a glider or two. Cleaning up that ash (or all but one block of it) with a suitable following trailing salvo (or probably even slow single-lane salvo) of *WSS enough lanes from the blinker line that the fuse can safely pass between them is going to be a searchable problem. So the basic idea is almost certainly feasible. For using the gliders for doing a c/2-o-to-arbitrary-distance complex glider synthesis it would be nice to find reactions that edge-shoot the glider, but just being able to generate a 4-sided slow salvo of gliders at c/2-o-to-arbritrary-distance is probably more than sufficient -- we don't need a universal construction kit (even though we might be able to build one), just enough let us compile a recipe make a MWSS->g conduit plus an elbow.

EDIT 2: Someone is way ahead of me on this -- here's the clean single-glider-launching version already found: viewtopic.php?f=2&t=2166#p30190. Next we need something comparable that instead creates a single block, then someone needs to compile single-glider seeds for launching those. (Sadly we can't just do a two-lane slow salvo of the glider producing version, since the fuse and the puffer travel at different speeds.) But still, a suitably laid-out array of those, launched and lit at the right times should be able to construct a specific object, such as a MWSS->g conduit.

[dvgrn]

I've been reading up on single-lane glider construction tech to try to appreciate why it's so easy to work with: is it basically the availability of slparse, combined with the way that it allows a single instruction tape path (so no issues with synchronizing multiple parallel streams as they get routed around corners) with all the data contained in signal timings but that can have gaps added to if so that it can be made to pass through itself?

Yes, slsparse's ability to build really complicated recipes with no user intervention is really the big deal. We have nothing at all like that for any competing universal construction technology; many of the early self-constructing patterns were assembled almost completely by hand. Maybe some of the code simsim314 wrote for the Remini might be a step in the same direction, but it isn't taken nearly as far.

It's actually quite easy to string together custom single-channel recipes manually, using just Golly -- up to and including recipes with integrated Snarkmaker / construction / Snarkbreaker sequences. By comparison, earlier toolkits like the 10hd and 0hd universal constructors were a huge headache to work with.

The ability of a single-channel recipe to pass through a copy of itself is kind of an optional extra, so far. There are some interleaved Cordership recipes in the loopship, and a sort of similar trick in the camelship, but otherwise most recipes are just squashed down to their minimum timings. Nobody has gotten around to building a rectangular Orthogonoid with lots of internal signal crossings yet.

What I hadn't understood is that (within reasonable limits) speed of construction isn't a design constraint you're interested in: a single-channel glider stream feeding slow-salvo glider synthesis is already pretty slow, we need to just not slow it down further.

The biggest point here is actually that Golly's ability to run a pattern quickly has very little to do with the number of ON cells or the number of ticks in the pattern, and a whole lot to do with how many unique hashtiles (of any size) there are in a pattern. Long strings of single-channel gliders don't need very many hashtiles to store at all -- unless you double a recipe back on itself. So recent designs like the Speed Demonoid make sure to have only 90-degree corners and gliders all traveling in the same direction, no nearby boustrophedonic streams at all -- and the pattern runs really fast, even in a copy.sh/life browser window.

Once again, I seem to be prioritizing speed of construction over launcher simplicity, so this is probably a bad idea, but I've nearly talked myself into going off and researching c/2-o wickstretchers and how they burn up.

Something to look at as a start would be the design for an Orthogonoid with limit speed c/2 orthogonally, or some similar ideas for a Caterloopillar.