Anyway, by flipping the G->MWSS vertically I came up with a cheaper 1-Snark Orthogonoid that has 367 cells and is HashLife friendly. Among similar 1-Snark Orhogonoids it should be difficult to beat but maybe the 2-Snark version is still better:

dvgrn wrote:In the absence/presence of the key piece, it would all self-destruct without doing anything. The left-side construction arm ends up doing a complicated NOP operation, and the right-side arm gets the minor adjustment it needs.

I am thinking that the left-side construction arm builds:

1. A far away 180 degree reflector on the construction lane.
2. A 0 degree glider aiming at the the 180 degree reflector.
3. (Soon after 2) An eater on the construction lane.

Eventually the glider returns and destroys the eater. This gives a certain period of time where the gliders on the construction lane will be absorbed without effect.

On the right construction arm the presence of a key piece of junk prevents 3 from happening. In the meantime gliders that encode the adjustments to the hand and elbow as well as the building of the key piece of junk in the child pattern are sent.

Might this work? Any better ideas?

EDIT: Rather, the key piece of junk needs to prevent 3 from happening and make a usable mess near the construction lane instead.

1. A far away 180 degree reflector on the construction lane.
2. A 0 degree glider aiming at the the 180 degree reflector.
3. (Soon after 2) An eater on the construction lane.

Eventually the glider returns and destroys the eater. This gives a certain period of time where the gliders on the construction lane will be absorbed without effect.

On the right construction arm the presence of a key piece of junk prevents 3 from happening. In the meantime gliders that encode the adjustments to the hand and elbow as well as the building of the key piece of junk in the child pattern are sent.

Might this work?

Tricky! Yes, seems like that will work. The faraway one-time reflector can be as simple as a couple of blocks or a long boat. It may need to be pretty far away, though, so it might be necessary to use Calcyman's Cordership build/launch/shoot-down trick.

-- Come to think of it, is the range of 0-degree gliders wide enough now that the Cordership seed could be built directly on the construction arm? EDIT: Not quite -- somewhere around 136 lanes would be needed, and we "only" have 119. Of course we can build any missing ones if we want to, with an elbow-to-hand then converting the hand to a one-time turner.

EDIT2: But now that we have a 2-engine Cordership seed, it's really easily constructible with a 0-degree salvo!

Anyway, I guess that's not necessary -- the Cordership could be pointed diagonally backwards just as well. For some reason I was visualizing it as launching in the direction the construction arm is pointing.

chris_c wrote:EDIT: Rather, the key piece of junk needs to prevent 3 from happening and make a usable mess near the construction lane instead.

Also, when the reflected glider comes back, it can't just delete the eater, it has to leave some junk. Or if it does delete the eater, there has to be something behind it that can get turned into an elbow... and that absorbs gliders exactly the same as whatever is left behind after the hand&elbow-adjustment/key-junk-building recipe. So probably simplest if it's just a standard elbow.

chris_c wrote:Anyway, by flipping the G->MWSS vertically I came up with a cheaper 1-Snark Orthogonoid that has 367 cells and is HashLife friendly. Among similar 1-Snark Orhogonoids it should be difficult to beat but maybe the 2-Snark version is still better...

No, I think I like this one the best out of the whole collection so far. I think it's time to get an Orthogonoid actually running. I'll probably compile Orthogonoid367 and Orthogonoid372 with slmake next -- see if the integral is really cheaper than two eaters.

Then --

What's the smallest number of slow SW gliders that can clean up an old Orthogonoid construction arm safely? At 128 spacing this design is just a little bit tight along the NW edge (see below). But it looks as if it will be easy to find cleanups. For example, here are two slow gliders that leave only one blinker just out of reach, to be cleaned up at some point, presumably by a stray NW glider or just a lucky spark:

In case it isn't clear, it seems like this would be a perfect occasion to use the new 0-degree Snarkmaker recipe to bend the construction arm around to do the destruction. The rectangular Orthogonoid will need different tricks, but I'll save that for later.

That was found with the dumbest possible greedy algorithm, so I'm sure it can be radically improved. If nothing else, the gliders badly need to be shuffled into a more sensible order, generally NW to SE.

dvgrn wrote:What's the smallest number of slow SW gliders that can clean up an old Orthogonoid construction arm safely?

The number is apparently less than or equal to 45 gliders...

Last-minute circuitry adjustments are no fun at all. I had a nice 45-glider near-to-far slow salvo all compiled into single-channel form -- Calcyman explained that slmake will cheerfully produce a single-channel recipe if the infile.mc consists of a slow salvo of gliders aimed to miss an initial block.

But then it seemed like a good idea to get the output glider from earlier in the Herschel circuit, so that the Snark on the construction arm could be pre-built, and then removed by a Snark-destroy recipe when it was time to shoot down the parent constructor. So the Orthogonoid construction arm should look like this:

Just one eater had to move, but of course it was one that participated in a big explosive reduction in the early part of the last cleanup recipe. So my mediocre greedy destruction script only seems to be able to manage 52 gliders now.

Anyway, when the circuitry gets retired, what's left to be destroyed will look like this:

Can somebody write a better meteor-shower search utility, or should I just leave it as it is? It probably won't make any difference to the size of the Orthogonoid, because it will be adjusted to a power-of-two period anyway, and the population increase will be a fraction of a percent... but this cleanup recipe just seems excessive somehow.

dvgrn wrote:Can somebody write a better meteor-shower search utility, or should I just leave it as it is? It probably won't make any difference to the size of the Orthogonoid, because it will be adjusted to a power-of-two period anyway, and the population increase will be a fraction of a percent...

I thought it could be nice to have a utility for this, so I'm working on one...
Here's a sample result using 36 gliders in a 32 lanes wide firing window:

dvgrn wrote:I thought it could be nice to have a utility for this, so I'm working on one...
Here's a sample result using 36 gliders in a 32 lanes wide firing window...

Looks good! In practice a different window will be needed, though -- my last pattern included the eater-tie-eater/block constellation in the right position to mark the allowable edge of the firing range.

The Orthogonoid is working as a puffer now -- should be all done pretty soon. I'll probably just compile the meteor shower recipe I have, since it won't make any difference to the period of the (Hashlife-friendly) spaceship.

EDIT: Looks like it will take something over 6GB of RAM for Golly to be able to "run away" with this one -- lots of different hash tiles with the signals going back and forth next to each other, as usual. Does anyone have a test system with some unreasonable number of gigs of RAM available? Golly's memory use should stabilize at some point, but I have no idea when -- my best system has only 8GB available.

I'm hopeful that it will be a much more reasonable number of gigabytes for Scorbie's new Demonoid...!

biggiemac wrote:I'm giving golly 10GB of my RAM and still getting 99% garbage collections when trying to run at 2^18.

Edit: Pushed it to 13 GB and still got 99% GCs so probably my 16GB laptop can't run away either.

Hmm. Not too surprised -- this is an ambitious amount of circuitry, and all the different ways the recipe can fold over on itself add up to a lot of hashtiles. The fact that you were testing the puffer rather than the spaceship would have added a few tiles, though probably not a significant number.

Here's a completed period 2^23 Orthogonoid spaceship to try -- it should have fewer hashtiles than a 2^22 model, though again probably not enough fewer to make any difference.

Looks like this one will fit in a 2096822x565 rectangle a lot of the time. That's less than half of the size of the Demonoid if we go by bounding box -- 1,184,704,430 cells in this bounding box versus 3,023,569,640 for the Demonoid.

... Which just goes to show what a silly measurement the bounding box is. The Orthogonoid is much bigger by any other metric, and correspondingly slower.

We can cut the bounding box more or less in half by moving the two halves 2^20 cells closer together, and still have a theoretically Hashlife-friendly Orthogonoid -- it's easy to do, just wait until the recipe is maximally folded over, then move the empty half. But just like the maximally folded linear propagator, it runs slower all the time, because the recipe is always folded:

I think the minimum period for this particular stream of MWSSes is something like 3,476,016. Technically an Orthogonoid can be squeezed a little smaller than that, because the component recipes actually aren't quite packed as tight as they could be.

Then someone could spend approximately a lifetime figuring out how to improve on slmake's compiled recipes. You can see here and there where the algorithm could be a little more efficient. Of course a better meteor-shower cleanup salvo would shorten things up a little more. Really there are possible improvements to be made all over the place, but even all together I don't think they'll add up to a power of two improvement any time soon.

Anyway, no more optimization for me! I'll probably try taking this recipe minus the cleanup, and see if I can write code to fold it successfully into a square Orthogonoid puffer. Have to re-do the cleanup using self-destruct circuits to get an actual square spaceship. It will have a much higher speed; no idea if that will translate into enough fewer hashtiles to make Golly happy.

EDIT: Since it looks like it won't matter much to Golly anyway, here's a copy of the Orthogonoid adjusted down to minimum period, p3476016. Not sure what the phase with the smallest bounding box or population is yet, but it's around 868,750 by 800, and 469,000 ON cells.

dvgrn wrote:In practice a different window will be needed, though -- my last pattern included the eater-tie-eater/block constellation in the right position to mark the allowable edge of the firing range.

simeks wrote:Here's a solution with 32 gliders that saves the MWSS-to-G converter...

Yeah, that looks a lot more professional than my pretty much one glider per still life solution. I'll get around to recompiling and incorporating this eventually, if no 31- or 30-glider solutions come along in the meantime.

Luckily the destruction happens after the construction is already done, so this can't be used to reduce the period of existing Orthogonoids. The minimum period will still be 3,476,016 until someone gets around to writing an optimizer that can squeeze the last one or two or three ticks out of all those component elbow operations... or until we replace all those recipes with shorter ones that allow glider triplets, quadruplets, etc. That last might actually allow the Orthogonoid's period to drop below 2^21, I suppose.

EDIT: Statistics for the statistics-minded: minimum bounding box for the p3476016 Orthogonoid is 868,856 by 707, at T=219704 from the posted pattern. Minimum population is 467,746 at T=198169. Of course each minimum happens twice per period, 1738008 ticks apart.

dvgrn wrote:Does anyone have a test system with some unreasonable number of gigs of RAM available? Golly's memory use should stabilize at some point, but I have no idea when -- my best system has only 8GB available.

I'm hopeful that it will be a much more reasonable number of gigabytes for Scorbie's new Demonoid...!

I ran the period 2^23 orthogonoid through Golly on my biggest machine at a step size of 2^12. It stabilized at about 35G of RAM and took about a minute to run through the full period.

Last edited by Hooloovoo on July 1st, 2017, 6:41 pm, edited 1 time in total.

Hooloovoo wrote:I ran the period 2^23 orthoganoid through Golly on my biggest machine at a step size of 2^12. It stabilized at about 35G of RAM and took about a minute to run through the full period.

Thanks! That gives me a good data point for designing a Geminoid variant that Golly can handle with just a gigabyte or two of RAM. Basically it should be okay as long as there aren't any of those deadly back-and-forth streams of data.

simsim314 wrote:Hey dvgrn Congrats! I was thinking to finish this project myself using calcyman script - but I see you've managed to finish it all by yourself (no surprise).

Yes, the Orthogonoid was one of the really easy projects to finish. Haven't really gotten going on the multi-folded rectangular Orthogonoid yet -- that one will run even slower in Golly than the original. I seem to be putting off the more painful design problems, like a diamond-shaped self-constructor that will actually run well in Hashlife.

If somebody wants to tackle a self-constructor with a 2D loop, it looks like it might work to launch Corderships simultaneously in two directions, and then stop them with following gliders. Corderships are so slow that (if my math is right) you can't easily use them to make a recipe loop that has just two 180-degree reflectors. A 1D loop will end up being only just big enough for the gap between the Cordership-launching trigger glider and the Cordership-stopping following glider, leaving no room for the rest of the recipe unless you add extra one-time switching tricks...!

It might make sense to post a patched version of slmake in a new thread, to save people that editing step. Not sure when the next official release might appear -- I'm hoping for one that automatically compiles two single-channel recipes, one for each color for the first output glider, written to singlechannelA.txt and singlechannelB.txt instead of just being dumped to stdout. And there are rumors of other possible improvements.

wwei23 wrote:If you got rid of the deletion tape, would you get a puffer?

Of course. You don't need to ask questions like this, you can just try it yourself. For example, delete a few MWSSes randomly from the end of the recipe stream and see what happens. Or watch the very end of the cleanup process, and figure out exactly which MWSSes you should delete to get the behavior you want.

I believe this completes the spaceship table in Glider synthesis as of the end of 2017, unless someone comes up with another synthesis in a hurry.

It's kind of funny how fast HashLife can build the first half of the Orthogonoid spaceship with this recipe, running at 2^16 or above, considering how slowly it builds the second half and how slow it runs the actual spaceship.

-- But all it will take to fix that is a HashLife algorithm with hyperspace-bypass support.

Okay, that was a little oversized, and furthermore didn't allow for easy adjustability to build different Orthogonoid periods. Here's a script that builds any p3476016+8N period Orthogonoid that you might want, by producing the appropriate glider synthesis recipe. Yes, I know I should have written it in Lua -- if anyone needs Lua practice, please post a translation:

The total cost turns out to be 37,625 gliders. That could be cut down quite a bit more if someone wanted to come up with a multidirectional synthesis for the circuitry. I changed the starting location and target but otherwise just used the same recipe that slmake came up with, with one slight difference on the east side that I'll leave for the enterprising reader to find.

35,870 of the 37,625 gliders are the recipe stream. 1749 gliders (the Hardy-Ramanujan number plus 20! I should have worked just a little harder on optimization...) sneak in in advance of the recipe and construct the initial pair of constructor arms, and the remaining six suppress the trailing cleanup recipe until actual old Orthogonoid circuits are there to be cleaned up.

For the minimal (p3476016) Orthogonoid, construction is almost all done at T=5,408,624, but there's one out-of-place block until T=7,147,114. So technically the total construction time is over 7 million ticks.

For the 2^23-tick (p8388608) Orthogonoid the construction time is 12082234 ticks, and so on.

This is the minimum recipe that has to be completed before the streams can start to cross each other: the topmost elbow block has to generate another elbow block before it does anything else. That way when the initial recipe doubles back through the topmost completed Orthogonoid constructor-arm unit, it will find an elbow waiting for it to work with.

I think this means that the narrowest possible Orthogonoid, for the moment, is about 50,000 to 60,000 cells wide -- basically, as wide as this MWSS recipe doubled over, with some room on the edges for the overlapping construction arms:

That also puts the minimum period of a square-Orthogonoid design at around 150,000 ticks. 256c/150,000 is somewhere around c/586 -- pretty speedy for a non-Caterloopillar self-constructing spaceship.

This means that the Orthogonoid will only need about fifteen rows, or maybe twenty if the recipe has to be thinned out a lot to make all the stream crossings possible -- there will be on the order of 180-380 crossing points. I'm pretty optimistic that not too much thinning will be needed. These recipes are already mostly empty space.

The main thing to realize is that only about one glider in fifteen ends up producing a NE-traveling output glider (on the west side of the square Orthogonoid -- NW-traveling on the east side). In some sense those NE travelers are the only ones we have to worry about. For those rare gliders that produce a NE traveler, we have to wait around and send the final trigger at the first tick where it will be able to slip through up to 14 perpendicular streams.

[The first fifteenth of the recipe has no crossing constraints; the next fifteenth has one stream to cross, the next fifteenth has to cross two streams, and so on.]

If we do this wait-around-and-slip-the-glider-through trick each time we encounter a NE output glider, working from the beginning of the recipe to the end, then eventually we're guaranteed to be able to complete the recipe (right? That's what I'm thinking at the moment, anyway.) Will just have to see if there isn't enough room between gliders to handle all those crossings, and we have to add an order of magnitude to the length of the recipe.

It seems to me that it might be possible to align the glider pairs somehow, at some particular frequency related to the width of the Orthogonoid, such that all the NE crossing gliders are able to slip through an appropriate space. But I'm afraid that my grasp of the relevant mathematics is shaky enough that it will be easier for me to figure it out by writing a compiler script and test-compiling a bunch of different frequencies and spaceship widths.

If someone would be interested in helping me out with the theory here, I'd be most grateful.

They won't set any records for population, bounding box, or period. But along the same lines as the most recent Hashlife-friendly Demonoid, they require much less memory to "run away" in Golly, though still more than the Demonoid does. The threshold seems to be just over 12 gigabytes.

I think they do set a speed record for self-constructing spaceships, though. The faster one is c/64, or (2^21)c/(2^27), and so the slower one is c/128.

I'm finding these to be a lot more fun to watch than previous Orthogonoids or other self-constructing stuff, both because Golly runs them much faster, and because you can get a good sense of what's happening at both ends of the ship at once, without having to zoom in.

It will be interesting to see if the speed can be improved to c/32, or even all the way down to c/16, using the new inline Cordership recipe. That improvement should also cut the populations down by a full order of magnitude and more. The great majority of gliders in the current recipe are wasted doing the long initial elbow block push.

dvgrn wrote:
It will be interesting to see if the speed can be improved to c/32, or even all the way down to c/16, using the new inline Cordership recipe. That improvement should also cut the populations down by a full order of magnitude and more. The great majority of gliders in the current recipe are wasted doing the long initial elbow block push.

The latest slmake (which includes both efficient pulls and pushes) yields a recipe that will allow a c/16 Orthogonoid with a minimum population of < 640 000 cells (so 4x faster, 4x smaller bounding box, and 20x smaller population).

I'll leave @dvgrn to actually produce the pattern -- the infile.mc he gave me didn't contain the last seed of destruction.

What do you do with ill crystallographers? Take them to the mono-clinic!

EDIT: The minimum population drops below 350 000 cells in one phase (where there's both a 2-engine and a 3-engine Cordership flying in the same direction). Annoyingly, this is somewhat larger than the Caterloopillar (the other method of producing arbitrary-speed orthogonal spaceships).

What do you do with ill crystallographers? Take them to the mono-clinic!

calcyman wrote:Actually, it was fairly routine to do this myself by copying the necessary parts of Dave's period-2^27 version...

Yup, slsparse is making it so easy to roll your own self-constructing spaceship design, that I don't know why everyone isn't doing it by now!

The Corderships will hold the speed of this edition of the Orthogonoid to something slower than c/12, so we aren't going to get another factor of two speed improvement until we switch to making new targets and elbows with loafers chased by *WSSes, instead of Corderships chased by gliders.

It's possible to change the speed either by altering the step size -- i.e., asking slsparse to build the child copy at a different offset -- or by changing the period by moving the two halves relative to each other. The second is much easier since it doesn't require recompiling the recipe. Looks like the fastest this particular Orthogonoid recipe can travel is 2^21 steps every 30450336 ticks.*

That's faster than c/15 -- about c/14.52. Not bad for a self-constructing spaceship!