ConwayLife.com

Continued from the Demonoid thread:

Here's a proof-of-concept almost-Spartan orthogonal Geminoid design -- just as an upper bound, not something I necessarily want to program to construct itself.

However, it would be relatively easy now to write a compiler that could build a slow salvo for it. The clearance problems are really minimal this time around, so an automatically generated recipe should work just fine:


It would be nice to reduce the circuitry by as much as possible, though. How can this be done with fewer eater2s, but if possible without building eater2s in close proximity to other still lifes?

What are the Official Orthogonoid Construction Rules? In other words, what does qualify as an Orthogonoid? Is it enough to say, that it is an orthogonal self-constructing spaceship based on stationary universal constructor, or must it be also glide-symmetric?

Hehe nice to see my small lucky discovery there Still, the search for "dependent-H-to-X-suppressing-g10?-glider-output" was not comprehensive, and oneay find smaller conduits with bellman. I am not sure what catalysts I used with ptbsearch.

Also, I think p120 circuitry + Herschel duplicator + dependent H-to-M seems like a good combo.
Perhaps one can smash simkin's glider gun to a sparky glider eater ro delete the beehive with more time clearence.

codeholic wrote:What are the Official Orthogonoid Construction Rules? In other words, what does qualify as an Orthogonoid? Is it enough to say, that it is an orthogonal self-constructing spaceship based on stationary universal constructor, or must it be also glide-symmetric?

Well, I was working by analogy to the Demonoid. If the recipe turns 45 degrees, then the direction of travel has to do the same, or you can't use the glide-symmetry trick.

"Orthogonoid" is really just a portmanteau of "orthogonal Geminoid", so there's nothing there to rule out non-glider-symmetric designs. I'd be very interested to see alternate blueprints on this thread.

It's possible to design a spaceship with a vertical loop, for example, with two identical halves passing a long stream of MWSSes back and forth. Construction would have to be done with freeze-dried salvos, because one of the new construction sites will be right in the way of the returning MWSSes. But with freeze-dried salvos we could delete and rebuild the circuitry at any offset we wanted, including (-2, 0)... or even (-1, 0), I think, if we make sure that the two MWSS emitters in the replicator unit produce different color MWSSes.

Or even (0,0), I suppose, if we wanted an infinite family of very high-period oscillators with 100% volatility. It could be arranged to include an infinite number of prime periods, if that was interesting to anyone. I guess the goal here would be to build a script that could program the system to rebuild itself at any desired offset.

With any non-glide-reflecting design you have to have pretty near twice as much circuitry in the replicator unit, though. You have to be able to catch an MWSS signal from two directions -- either from the top or the bottom, in the case I described above -- and feed it to the construction arm. The two halves might as well be completely separate, especially if we're using the single-channel toolkit. One half of the circuitry would edge-shoot gliders onto the other half's construction-arm lane.

Scorbie wrote:Also, I think p120 circuitry + Herschel duplicator + dependent H-to-M seems like a good combo.
Perhaps one can smash simkin's glider gun to a sparky glider eater ro delete the beehive with more time clearence.

I don't think you can get any more time clearance than the design from the other thread makes available -- 90-tick separation and 150-tick separation can both be made to work, and if you don't keep gliders strictly within that 120N+/-30 window, they'll get out of step with the gun and crash everything.

It's true that a spark would be better when you're starting the stream back up again after skipping some p120 cycles. Then at least you wouldn't have a glider crossing the Herschel conduit. On the other hand, it will have to be a pretty big sparky eater, won't it? Close to (syringe+something) sized. The beehive isn't quite on the edge of the H-to-MWSS's reaction envelope, so it's a little bit protected.

You could have the glider cross the MWSS stream instead. Looks to me like that gives a fairly large range of time clearances -- the glider is mostly crossing at a time when an MWSS couldn't be going through anyway.

Here's the variation I'm describing -- it's just the Orthogonoid blueprint from the Demonoid thread, with the second p120 removed, and the beehive-cleaning p120 re-oriented. So this would be a "limited single-channel" replicator unit -- gliders inside 120N+/-30 only. Will have to filter single-channel elbow operations and make sure there's still a universal toolkit, but I'm not too worried.


Notice that you can take out the middle MWSS without doing any damage -- but you can't slow it down by 60 ticks. You can slow it down by 52 ticks, though, or a small range below that, but only if you skip the next MWSS signal -- it's complicated. I think the safe following distance for that initial MWSS timing is 90-121 ticks, but you can change the safe following range by slowing down the initial MWSS as well.

-- If this ends up being the design, it will be necessary to filter the single-channel library very carefully... or maybe it will be easier to just re-do the search.

I'm currently running a 3-object CatForce search to see if there's a way to convert MWSSs to signals directly, or at least do so in a way more convenient for Orthogonoid geometry. Estimated completion time is in 33 hours--hoping something nice shows up.

How about something like this:

simsim314 wrote:How about something like this...

Looks like a reasonably competitive design. There are a couple of limitations that I see with this model, though.

If I've done the analysis right, the adjustability of the incoming MWSSes is down around 24 ticks, and the p120 G-to-H beehive cleanup means that you can't ever skip an MWSS. Quite possibly the lack of an MWSS could trigger the self-destruct mechanism, but that's another story...! Here's a version with the MWSSes in their most advanced position, except one of them is moved back 23 ticks:


Extra gliders at the right edge are just a cheap trick to suppress the top gun's output. You'll see that there's trouble if you try to delete those gliders. Really the gun should not be started up until just before the first construction signal gets to the H-to-MWSS converter.

With the other model you can skip 120N ticks when you need to, to let a long-running elbow operation settle. (I think it will be safe to start the stream up again, though the timing of the first couple of gliders will have some scary limitations, so that might not turn out to work very well. I guess you could say, you can skip all you want as long as the next glider in the recipe is a singleton.)

I have no idea how many recipes will be excluded by the limitations of this new design. If you combine the no-skip problem with the reduced adjustability, I wouldn't be surprised if you were looking at a 25-50% reduction in the efficiency of the construction arm.

The other thing that I've added is a 90-degree reflector. The construction arm will have to reach forward, not backward, so this seems like a much cheaper option than adding a second slow elbow to reach around two corners.

EDIT: It's kind of annoying, because 90-degree MWSS turners are fairly small -- it's just the 180-degree ones that are big and awkward:


EDIT2: A slightly less silly idea -- seems a little tighter, anyway, with fewer eater2s than my original revision:

@dvgrn From my previous games with this design, you need to work from the "other side" of the destruction, you'll get 29 ticks of operations:



If you're intending to use second glider from p120, you'll need recipes where one of the gliders is of the same internal state.

I've previously compiled such recipes for 9 lane options. For my design you'll need p30 reflector as well as p120. The recipes showed no deterioration by the small gate.

There are two main reasons for this:

1. Larger gate gives you more options, but most of the valuable options don't use wide gate range.

2. This is exponent where you need to get to 8-10 gliders anyhow most of the time. So we speak about high order exponent, which can compensate the narrowness by single glider, when the glider length is ~8-10. Basically we're speaking about 10-15% of cost, and because of #1 I think it comes down to 5-7%.

Also I've found no serious reduction by the lack of 'SKIP' operations, they don't add you so much.

----

Basically what I'm saying is: have a good design with gate > ~20-22 (gate 19 didn't work so well), the recipes costs will be minor.

EDIT Also 10-hd is not the best option as far as my experiments went. I think 2-3 lanes worked best. As I remember, the additional p30 reflector was definitely worth it.

EDIT2 Thinking a bit about the design - we don't actually need an edge shooter. What we need is "clearance" from some lane in both directions.

I've added anothe p120 + reflector. And then I saw this:



This brings a question: do we want the orthogonoid to travel diagonally or orthogonally?

- Diagonally the front and the rear will have to be different.
- Orthogonally there are additional limitations on the geometry.

Doesn't the NE shooting version of L156 come in handy for this design?

Wow! I think Chris's design is very close to optimal. Turns out that syringe does beat p120 + spartan G receiver if you need Lx on the G->H output. Add to it a higher gap, stability and not destructiveness it's really better.

Now we only need to pack an extra p120 and we good to go.

simsim314 wrote:This brings a question: do we want the orthogonoid to travel diagonally or orthogonally?

- Diagonally the front and the rear will have to be different.
- Orthogonally there are additional limitations on the geometry.

I've been assuming that the Orthogonoid will move orthogonally. This is mostly because it's possible to have no construction clearance issues at all for a change, and that seemed like a really nice feature. The elbow will be out by itself in empty space. Thanks to the glider stage the output can be trivially adjusted to any MWSS lane you want, to provide plenty of clearance between one replicator unit and the next adjacent one.

I don't think I have a good picture for what a diagonally-travelling Orthogonoid would look like. I mean, yes, you can build twice as much circuitry, use only half of it on the left and the other half on the right, and then you can re-use the same recipe -- but that works for an oblique Orthogonoid as well.

Turning the MWSS stream 90 degrees instead of 180 degrees would make a very interesting diagonal glide-reflecting design, but we'd have to have each new replicator unit build a Cordership or some such, to travel far ahead and provide a target for the next replicator unit's constructor arm. Not sure if the timing could be made to work out, though -- might have to build one-time LWSS turners ahead of the spaceship instead, so that the LWSS arrives just as the slow salvo gets to the next construction site.

Anyway, it seems like there will inevitably be construction clearance issues and lots more complexity with any such design. An orthogonal Orthogonoid is so much more elegant!

simsim314 wrote:Wow! I think Chris's design is very close to optimal. Turns out that syringe does beat p120 + spartan G receiver if you need Lx on the G->H output. Add to it a higher gap, stability and not destructiveness it's really better.

Now we only need to pack an extra p120 and we good to go.

We don't _have_ to pack an extra p120. It would work fine -- but on the other hand, this might be a good design for showing off the single-channel toolkit. Simplify the design, avoid the various startup/shutdown headaches. It might save enough still lifes to make up for the relative inefficiency of single-channel construction.

I thought of one other design detail. With the single-channel design, it is possible to add a 90-degree reflector to the output, and use it to very cheaply shoot down the previous inactive replicator unit, before sending one last
glider back to disable the reflector and start the construction of the next replicator unit.

"One last glider" shown:

Then, along with no painful low-clearance recipes, there'd also be no painful mucking around with setting up self-destruct circuitry. Could probably just shoot down the p120 gun with the last glider from the construction arm, so that the destruction stage could deal with a p1 or p2 mess, instead of something that's p120.

If this variant is acceptable, we might actually want to switch back to a regular L156 to get a SE output stream. Being able to build the new upper replicator unit first, and then break the 90-degree reflector and delete the lower inactive replicator unit, allows the bounding box to be cut down by almost a factor of two.

The design still looks fairly elegant, as these things go:

@dvgrn well if we're willing to go back to L instead Lx for the self destruct, and dry out single eater2 (or maybe p120 assisted reflector would work there), then my initial design looks better I think:

http://www.conwaylife.com/forums/viewtopic.php?p=31225#p31225

simsim314 wrote:@dvgrn well if we're willing to go back to L instead Lx for the self destruct, and dry out single eater2 (or maybe p120 assisted reflector would work there), then my initial design looks better I think...

I don't quite understand "L instead Lx for the self destruct". It still seems worth checking whether the nearly 60 ticks of adjustability that you can get with a syringe+Lx200 design, would make a single-channel toolkit really significantly more efficient. It's still surprising to me that single-channel works at all, and I'd like to try a design that gives a good chance of developing it a little further.

With a design that uses a p120 gun to add a second glider, I can see that a more limited range of adjustability probably won't make very much difference.

A possible advantage of a more limited range is that gliders could safely cross either the input or output MWSS streams:


The first output glider lane from a syringe+Lx200 could actually be used for construction, if the distances were adjusted so that that stream could cross the output MWSS stream. That idea may be slightly too crazy, though...!

This idea could be worth considering if someone wants to use a supporting p120 stream. Two Simkin glider guns and a block are sufficient to make gliders at 9hd separation without any interference:

dvgrn wrote:It's still surprising to me that single-channel works at all,

I think the single chanel is more of a gimmik at this point. Adding single p120 will give you much much more construction options. It will have problems of its own but all in all for ~10 SLs you get recipes twice shorter at the least. Unless you have something extremelly minimalistic I would add p120 second glider for the construction arm without hesitation.

I'm not sure whether extra p120 for 9hd worth it, or even extra p30 reflector. I do think that Chris's design of the whole unit is better (or your last version) and allows much more options than my p120 based G->H.

simsim314 wrote:I think the single chanel is more of a gimmik at this point. Adding single p120 will give you much much more construction options.

I don't entirely disagree. If the goal is size or speed or total-population records, then a single-channel design isn't usually going to set any.

On the other hand, single-channel is incredibly simple, with no hidden costs in many cases -- no worrying about startup and shutdown details, especially, and no need to add an edge-shooter or an expensive p30 reflector (both of which move the 10sL estimate quite a bit higher).

In particular, there is no reasonable p120 equivalent to the multi-directional construction arm trick I posted yesterday, where you add a stable 90-degree reflector, and then disable it when it's no longer needed. With a p120 second-glider design you'd have to start up one p120 gun, run it to build the Orthogonoid new replicator unit ahead of the current one, then stop that gun and start up a new p120 gun at 90 degrees, and shut it down also when it's no longer needed. Maybe a synchronized p30 reflector for each gun, too, to get an efficient set of glider lanes.

By the time you're done with all that, the single-channel Orthogonoid might win after all. So of course you wouldn't design a p120-assisted Orthogonoid that way -- you'd use a self-destruct system similar to the Demonoid's. But that, I can say from experience, is a very far from trivial custom design problem, which has to be done at the last moment: if there are any changes to the circuitry, even trivial ones, you usually have to start all over with the self-destruct circuit design.

Alternatively you might use a more expensive "universal self-destruct" design that could be compiled on demand for any circuitry -- generating a slow salvo to delete everything, along the lines of the original Gemini but created by triggering a large stable seed constellation, a "meteor-shower seed".

The self-destruct problem also gets a little uglier when some of the circuitry is p120. Single-channel looks to me like a great way to stay away from that whole mess -- but of course anyone else is welcome to tackle the problem, and prove by construction that it's cheaper over all...!

In any case, it seems to me that if there's ever a race to build some new type of self-constructing circuitry, a single-channel design is very likely to be completed first -- which is another kind of speed record, I suppose.

dvgrn wrote:there is no reasonable p120 equivalent to the multi-directional construction arm trick I posted yesterday, where you add a stable 90-degree reflector, and then disable it when it's no longer needed.

Why we can't just add extra p30 reflector and then disable it in the same way (in worst case you'll need extra p120)?

dvgrn wrote:The self-destruct problem also gets a little uglier when some of the circuitry is p120.

If you have even single p120 (and I think for the H->MWSS you'll pretty inevitably will use one if you don't want to pay for extra X2-3 longer tape). Having one p120 or three is the same regarding the self destruct.

One interesting option for the self destruct is to destroy the eater that blocks p120 output (like the universal regulator), this will "lock" the self destruct automatically mod 120.

dvgrn wrote: if there's ever a race to build some new type of self-constructing circuitry, a single-channel design is very likely to be completed first

I do agree it somewhat simpler. On the other hand, you're paying X2-X3 price for relatively small simplification.

There is another somewhat more esoteric point: have a design that show-case the newest advances in the field. This I do agree is interesting concern, but I think that adding p120 extra glider is also somewhat new idea.

----

Thinking of it from other direction: you get simplified design, without much headache, showcasing new technology - and still being in good range from optimality.

As for the p120 synchronization problem - we could build p120 that when triggered - destroys itself, while all the other "static" parts could be destroyed by extra arm.

dvgrn wrote:In particular, there is no reasonable p120 equivalent to the multi-directional construction arm trick I posted yesterday, where you add a stable 90-degree reflector, and then disable it when it's no longer needed.

The following pattern contains some ideas to deal with that issue. I am not planning on building this this but it should be noted that if someone builds a version using only single-channel construction then hopefully the construction/destruction recipes for that design can be carried over into the more complicated version. The only difference would be the addition of the extra p120 guns and reflectors and a completely different elbow-op library.

chris_c wrote:The following pattern contains some ideas to deal with that issue. I am not planning on building this this but it should be noted that if someone builds a version using only single-channel construction then hopefully the construction/destruction recipes for that design can be carried over into the more complicated version. The only difference would be the addition of the extra p120 guns and reflectors and a completely different elbow-op library.

That seems like a good way to break down this Orthogonoid design problem into stages.

Stage 0 would be the stable single-channel version, no oscillators at all. At the moment the smallest design looks something like this:


It may be a little oversized, but it's completely ready to be programmed, and there are no restrictions on when MWSS can come in (except separation >=90, of course.)

EDIT: Stage 1 would be to add just one p120 gun to suppress the extra beehive in the H-to-MWSS. That converts the Unlimited Single-Channel design to a p120-limited single channel design, but you get to throw away all the extra p90 reflectors needed to synchronize the beehive-killing glider with the MWSS-producing one.

Stage 2 would involve bolting another one (or two? or possibly four?) p120 guns on to the construction arm, with p30 reflectors to get the glider streams into alignment, or just a block if we use chris_c's design (which looks pretty good -- just seven blocks plus some synchronized startup headaches.)

Kazyan wrote:I'm currently running a 3-object CatForce search to see if there's a way to convert MWSSs to signals directly, or at least do so in a way more convenient for Orthogonoid geometry. Estimated completion time is in 33 hours--hoping something nice shows up.

It took longer than 33 hours, and due to moving-related difficulties, I had to cut it short at 80.1% completion. Here is the one non-trivial result, which I haven't figured out how to extract a signal from:

@dvgrn are we still compiling this stuff by hand? Don't we have some automated script for this kind of things by now?

simsim314 wrote:@dvgrn are we still compiling this stuff by hand? Don't we have some automated script for this kind of things by now?

I don't know of one, besides Calcyman's synthesise-pattern2.py script for compiling two-arm recipes for Spartan patterns (presumably for two-arm Geminoids, which no one has built an example of yet).

I've produced all the slow salvo recipes for Geminoid self-constructing patterns so far -- not that there have been very many. The old Blockic-seed loafer gun, the linear propagator, the spiral-growth pattern, and then the two Demonoids. The 0hd re-used the 10hd's TileA recipe, which could be re-compiled to use a lot less than 540 gliders now.

I wrote some one-off scripts to help put together those recipes, but in the end it was always a manual process with decisions made one still life at a time.

There have always been compiler scripts for the second-level compilation (i.e., starting with a slow salvo recipe, and producing a list of timings for the glider pairs that manipulate the construction elbow to produce that slow salvo).

The next task on my list for the all-stable Stage 0 design is to write a first-level compiler that accepts an "hand" target and a list of Spartan or near-Spartan objects, and produces a slow salvo that builds those objects by manipulating the target. I don't think I'll be able to get started on that project until June, though, and would be very glad if someone else wanted to tackle it instead!

One useful subtask will be to compile all the recent discoveries that weren't known for the Demonoid, into complete slow-salvo recipes -- especially the small-envelope eater2 recipes for different orientations, and simeks' fishhook eater recipe that's compatible with a pre-existing eater2 in the syringe+Lx200 combination.

That's probably where I'll start. It would be good to define a standard format, and maybe a standardized test script for that format, so that anyone who wants to can contribute recipes to the library.

@dvgrn I think we should have some automated script that just generates some solution. Then people could contribute to it and improve it.

We actually need two scripts:

1. Single arm construction from pattern. Like calcyman had done but for single arm.
2. Given slow salvo recipe generate construction arm.

Then we could play and optimize those scripts as much as we want. I would go as far as using heuristics from traveling salesmen problem to optimize the construction order using a run for couple of days.

dvgrn wrote:The next task on my list for the all-stable Stage 0 design is to write a first-level compiler that accepts an "hand" target and a list of Spartan or near-Spartan objects, and produces a slow salvo that builds those objects by manipulating the target.

I think we can keep the the scripts separated. The slow salvo construction though can just use more complex metric rather than just glider count. Say it can get "cost" list, i.e. a distance metric that counts arm operations instead of just glider count (in second order it can accept table of distance pairs etc.).

I think for slow salvo the major challenge is the management of pairs of SLs, but for starters I would make something that just robust and simple that simply always work.

simsim314 wrote:@dvgrn I think we should have some automated script that just generates some solution. Then people could contribute to it and improve it.
...
I think for slow salvo the major challenge is the management of pairs of SLs, but for starters I would make something that just robust and simple that simply always work.

My plan exactly -- especially if I decide to go through with the construction of a Stage 0 stable Orthogonoid. That's finally a recipe that I'm not crazy enough to try to put together manually.

simsim314 wrote:We actually need two scripts:

1. Single arm construction from pattern. Like calcyman had done but for single arm.
2. Given slow salvo recipe generate construction arm.

The first task could be split into two parts:

0. Near-Spartan constellation plus initial target (or list of possible initial targets) to ordered list of single still lifes, or small constellations to be built simultaneously.

I'm planning to tackle this one with a script that takes user input, at first -- have someone manually select the build order. Could try several different build orders and pick the one that compiles to the shortest slow-salvo recipe.

Once we have a sense of what a good build order is, we might be able to come up with an automated selection algorithm -- but I suspect this is one of the cases where it will take a very clever algorithm or a lot of brute force to improve on human intuition.

I guess the basic idea will be to recursively divide a large pattern into smaller and smaller clusters, and then construct from far to near inside each cluster. But if you watch the Tile A Demonoid construction, you'll notice that there are often (what appear to be) good reasons to make exceptions to that rule, especially when there are constraints due to neighboring circuitry, or when the location is dangerously close to the construction arm.

I'll probably try to switch allegiance to Lua for these scripts, since they'll run faster, and will be usable by people that can't install Python.

A more practical question: do we have some block->SL recipes list? Preferably limited list, of say 10 good recipes per SL per orientation? ( + we need block moving list) I know you post the recipes time after time in the discussions, maybe we could have a thread with all recipes on the first page like we have with Conduits? Maybe we need similiar thread, something like - the hunt for the optimal slow salvo compiler?