Wait I'm confused. How does this turn into synthesize a pulsar? Wouldn't there be a heckton of ash at the end? I'm sorry if I'm misunderstanding the thread's contents or anything, I just have lots of questions...

she/they // Please stop using my full name. Refer to me as dani.

"I'm always on duty, even when I'm off duty." -Cody Kolodziejzyk, Ph.D.

danny wrote:Wait I'm confused. How does this turn into synthesize a pulsar? Wouldn't there be a heckton of ash at the end? I'm sorry if I'm misunderstanding the thread's contents or anything, I just have lots of questions...

Not to worry -- it's not just you, it really is getting painfully confusing! Now is probably a good time for a fresh summary of how to get to a pulsar (or any other constructible object) with these 35 ultra-clever gliders.

I'm hoping I can get close, but someone may need to supply a few corrections. First, a few bullet points to keep in mind:

Below is just the outline for constructing something simple, like a pulsar.

If you want something more complicated, like a million Geminis going in all different directions, then you have to design a 1-glider seed constellation that will build the million Geminis, and trigger it at the last minute -- an additional glider along with the meteor showers in Step 9 below.

If you want a quadratic-growth replicator, or even a record-breaking low-population knightship or SMOS, then you have to add a lot more stuff: some kind of circuitry capable of storing bits coming in from the Sakapuffer, and then using them later after the cleanup. Let's not go there for this summary.

------------------------------------------

Okay, we're building a pulsar. We have an empty quadrant off to the east that we can put it in, where it won't get in the way of anything, so we'll build it first.

Step 1: Bits start coming in from the Sakapuffer, hitting the BLSE, and doing the clever 9fd/19fd crystal dance that calcyman and chris_c have cooked up.

Step 2: This 9/19 dance eventually produces monochromatic P1 slow gliders heading NE, which first build a target T at the NW end of the BLSE ash track (and a little north of it).

Step 5: Target T should be a secondary slow elbow, plus a hand target some safe distance off to the NE. The polychromatic gliders eventually turn T into the desired pattern P, at a safe offset in the empty East Quadrant.

Interesting But Not Really Critically Important Factoid: Previous designs required pulling elbow blocks from farther and farther away down the BLSE ash track, resulting in a horrible quadratic slowdown in construction that kindasorta balances out the quadratic speedup in the bits coming in from the Sakapuffer. With this design, whenever the source of elbows gets too far away down the BLSE ash track, it's possible to do a reset, and start building the next OTT starting right near where the elbows are.

The gliders turned by the one-time turners will have progressively farther to travel northwest to hit target T, but that ultimately doesn't slow anything down. This means that there's a fixed maximum cost in bits-from-the-Sakapuffer, for each new glider in the recipe that builds pattern P -- instead of a quadratically increasing cost.

That's a nice feature... except that the 9/19 crystal dance is inefficient enough that, as chris_c says, it will take a fairly large initial pattern just to get the Sakapuffer far enough away to produce enough bits to create the first NE glider, let alone the initial target T or the first OTT aimed at it.

Step 6: Now we have our Pattern P -- a pulsar or whatever it is. We also have the metric heckton of ash that danny mentioned. There's lots more work to be done to get rid of all that ash. Luckily we still have our Target T elbow, and can throw more gliders at it. So we'll use it to build blocks or other still lifes that can catch the incoming GPSEs at the right times, without releasing any additional gliders.

Step 7: We'll also build a Relatively Simple Seed Constellation, and trigger it. The purpose of this is to synchronize a couple of gliders that head SE and stop the BLSE without releasing any additional gliders. We know that just takes a couple of gliders.

Unnecessary Side Note: I think, because of the quadratic speedup in the bits coming in, these two gliders could really be produced right away, before Pattern P is constructed. Doesn't seem to matter, though.

Step 8: Now it's time to build Painfully Complicated Seed Constellations #1 and #2. When PCSC#1 is triggered, it will produce several Corderships traveling along the various ash tracks in various directions, cleaning up some part of them, or let's just say all of them (I think that will be doable now)... and then crashing into the messy junk at the various GPSE and Sakapuffer construction locations without releasing any additional gliders -- except for one or two heading back toward PCSC#2.

EDIT: Per chris_c's note below, the trigger glider for PCSC#1 will probably come from the Sakapuffer crashing into a custom one-time turner built for the purpose of producing the PCSC #1 trigger glider.

Step 9: After a truly ridiculously long time, the returning glider(s) trigger PCSC#2, which produces three meteor showers of gliders.

Step 10: After another truly ridiculously long time of equal length, these meteor-shower gliders clean up all the rest of the faraway junk at the GPSE and Sakapuffer construction locations... without releasing any additional gliders, of course.

And now all that's left is the pulsar! In only ten steps, too... This all seems like an unnecessarily complicated way to build a pulsar with 35 gliders, but theoretically the same setup (plus one more glider in Step 9) can build a million Geminis.

danny wrote:Wait I'm confused. How does this turn into synthesize a pulsar? Wouldn't there be a heckton of ash at the end? I'm sorry if I'm misunderstanding the thread's contents or anything, I just have lots of questions...

I was working on my own explanation to this but instead I will go carefully through dvgrn's explanation and see if I can add anything to it.

dvgrn wrote:Not to worry -- it's not just you, it really is getting painfully confusing! Now is probably a good time for a fresh summary of how to get to a pulsar (or any other constructible object) with these 35 ultra-clever gliders.

I'm hoping I can get close, but someone may need to supply a few corrections.

I'm glad you did this. I tried for a while but then saw you had already done a better job.

dvgrn wrote:Step 8: Now it's time to build Painfully Complicated Seed Constellations #1 and #2. When PCSC#1 is triggered, it will produce several Corderships traveling along the various ash tracks in various directions, cleaning up some part of them, or let's just say all of them (I think that will be doable now)... and then crashing into the messy junk at the various GPSE and Sakapuffer construction locations without releasing any additional gliders -- except for one or two heading back toward PCSC#2.

The triggering of PCSC#1 is something I have a comment on. We would rather not trigger it with a glider from the crystal because it would leave behind a mass of half-honeyfarms that would be difficult to clean. Instead of this it would be better to always leave the crystal in a fully destroyed state. After the last glider has been sent to clear up the last piece of the crystal we could crash the Sakapuffer into a block like this and use the NE glider as the trigger for PCSC#1:

EDIT: A crude script that takes patterns like the glider syntheses I have been posting and lengthens or shortens the pattern by some number of "steps". e.g. entering +/-1 will cause the first operation to be different, entering +/-2 will preserve the first operation and swap the second etc.

If we manage to produce a proof (following Elkies' outline) that every still-life is glider-constructible, then we're left with a finite amount of work to show that every still-life can be constructed in <= 1 glider per cell.

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

calcyman wrote:If we manage to produce a proof (following Elkies' outline) that every still-life is glider-constructible, then we're left with a finite amount of work to show that every still-life can be constructed in <= 1 glider per cell.

calcyman wrote:If we manage to produce a proof (following Elkies' outline) that every still-life is glider-constructible, then we're left with a finite amount of work to show that every still-life can be constructed in <= 1 glider per cell.

Could you give a link to Elkies' outline?

Yes, although apparently it was Mark Niemiec rather than Noam Elkies:

On 10th August 1994, Mark Niemiec wrote:Mainly to Harold:

Thanks for the papers on de Bruijn diagrams. Now, a lot of stuff(at least the basic ideas) are starting to make a little bit of sense.

I am currently working on a related task, attempting to prove thatevery still-life (finite or infinite) may be cut along an arbitaryhorizontal boundary and everything below the line replaced by a smallfinite stabilizer. If this can be proven rigorously (and I believe that itcan), we can prove that all infinite still-lifes can be made finite.

This is done by dividing up the universe into regions ... aaaaa aaaaa aaaaa bbbbb ccccc ddddd eeeee eeeee eeeee ...where 'a' is the interior of the still-life, is already stable, and has noeffect on the exterior.'b' is just below the surface, is already stable, and influences row 'c','c' is at the surface, and may require stabilization from external row 'd','d' consists of cells 'outside' the still-life which we need to add tostabilize row 'c',and 'e' consists of anything else we need to stabilize 'd'.

By definition, for every still-life which is cut in this way, for everysequence'b' and 'c' in that still-life, there must exist at least one sequence 'd'(i.e.the row which occurs just below 'c' if the still-life is not cut).

The idea is to prove that for every possible sequence of 'b' and 'c', somearbitrary 'd' can be chosen which stabilizes 'c', and is also itselfstabilizable by some arbitary 'e'.

The proof is somewhat similar to examining every edge in a de Bruijndiagram of a (4,2) automata (the states 0,1,2,3 correspond to no cells,'b' cell, 'c' cell, and 'b+c' cells being on in any specific column.) toensure that such edges preserve the 'c' cell. Wherever this is notpossible, any path leading through that edge must be re-routed througha parallel edge connecting altered versions of the initial states.We may replace states 0-3 by new states 4-7 as required (like 0-3but with an additional 'd' cell.). Since 'd' cells may not always beplaced with impunity, finding optimal alternate paths requires sometrial and error.

So far, I have expanded a fair bit of the tree, and it seems like aquite possible (although fairly tedious task.) I'lll mail the resultswhen (if?) I get finished.

A slightly more ambitius task which requires the above as a pre-requisite isto define all such states at the exterior of a partially-constructedstill-life,and find all mappings between such states and the corresponding statesin which one more cell is added to the interior: ... ... aaaaa aaaaa aaaaa aaaaa abbbb aabbb bbccc -> bbbcc cccdd ccccd ddddE ddddD eeeee eeeee eeeee eeeee ... ...If cell E is the same as cell D, no translation is needed;if they differ, a glider construction is required which flipsthe state of the single bit (and possibly alters other bitsin 'e'); this will, of course, have no effect on the already-constructed parts of the still-life 'a', 'b', and 'c'; only'd' needs to be taken care of by taking care how 'e' is altered.

In the majority of cases in which 'e' is empty, this is notlikely to be a problem. However, if the local area of 'e'contains a convoluted stabilizer, mucking with an inner cellcould be quite a problem. (On the other hand, such convolutedstabilizers are usually forced by one obnoxious cell; ifthat cell is the one which needs to be flipped, most ofthe stabilizer could be removed as well.)

If every such state-transition can be provided with a glidersynthesis, we will have a proof that every still-life can beconstructed from gliders, one bit at a time.

(But don't hold your breath; this could involve thousands ofcases, and even though Dave Buckingham is the best person togenerate the syntheses, I am sure he is not enough of amasochist to try to find them all!) Perhaps some kind ofautomated search will be required here.

Has anyone else researched this area? (or determined that it iseither too trivial or intractible to bother?)

-- MDN

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

chris_c wrote:Excellent. Thanks for finding that and for clarifying those other issues. The 35 glider synthesis was pretty easy to obtain from the 43 glider version. Just 6 GPSE's now and the minimum population is 143 after 5000 generations:

I've just realised that this implies the existence of a 143-cell sawtooth. The smallest explicitly-constructed sawtooth has 177 cells, by comparison.

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

calcyman wrote:I've just realised that this implies the existence of a 143-cell sawtooth. The smallest explicitly-constructed sawtooth has 177 cells, by comparison.

Seems like it would be a fairly complicated implication, though. Just the fact that a 143-cell pattern eventually constructs, let's say, a 177-cell sawtooth pattern, doesn't mean that the 143-cell pattern actually exhibits sawtooth-ish behavior starting from T=0. It will start acting like a sawtooth after umpteen bajillion ticks, but I'm not sure that counts.

Don't we have predecessors of sawtooth 177 that have fewer than 177 cells, for example (e.g., put a block instead of a boat in the boat-bit positions, and then take a cell out of all the blocks)?

To be a proper sawtooth, doesn't it have to return to 143 cells at ever-increasing intervals? How would that work in an RCT context, exactly?

calcyman wrote:I've just realised that this implies the existence of a 143-cell sawtooth. The smallest explicitly-constructed sawtooth has 177 cells, by comparison.

Seems like it would be a fairly complicated implication, though. Just the fact that a 143-cell pattern eventually constructs, let's say, a 177-cell sawtooth pattern, doesn't mean that the 143-cell pattern actually exhibits sawtooth-ish behavior starting from T=0. It will start acting like a sawtooth after umpteen bajillion ticks, but I'm not sure that counts.

Don't we have predecessors of sawtooth 177 that have fewer than 177 cells, for example (e.g., put a block instead of a boat in the boat-bit positions, and then take a cell out of all the blocks)?

To be a proper sawtooth, doesn't it have to return to 143 cells at ever-increasing intervals? How would that work in an RCT context, exactly?

It synthesises those 35 gliders, except with greater separation, such that there's a new NOP on the end of the tape each time.

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

dvgrn wrote:To be a proper sawtooth, doesn't it have to return to 143 cells at ever-increasing intervals? How would that work in an RCT context, exactly?

It synthesises those 35 gliders, except with greater separation, such that there's a new NOP on the end of the tape each time.

-- Yeah, that works. Only with a "complex RCT" BABC design, though -- you can't get away with just building a glider synthesis for a sawtooth (which could be a "simple RCT" design), you have to store all the ABC bits from the tape, then have a little subroutine that adds the right additional NOP bits to the B stage.

-- Ouch, this stuff still hurts to think about... maybe mostly because I really like to be able to build working examples of things, and even the simplest "simple RCT" design is just hopeless.

dvgrn wrote:-- Ouch, this stuff still hurts to think about... maybe mostly because I really like to be able to build working examples of things, and even the simplest "simple RCT" design is just hopeless.

I might start work on converting chris_c's 35-glider synthesis into an equivalent single-glider seed, in a quincunx* shape with seeds in the NW, NE, SW and SE and a single 4-way splitter in the middle. Then, the four 'arms' can be uniformly lengthened to change the value stored in the recipe. This is trivial (compared with anything else we've been discussing) but a good starting point because it's easier to manipulate a p1 seed than 35 live gliders.

The lifecycle of any RCT design will then proceed along the following lines:

(1 glider + quincunx seed) --> (35 gliders) --> (143 cells) --> ...

and in the "complex RCT" cases, will loop back around to ... --> (1 glider + quincunx seed).

* it's so useful this word exists for the 5-spot configuration on the face of a die or domino.

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

calcyman wrote:quincunx*...* it's so useful this word exists for the 5-spot configuration on the face of a die or domino.

Yup, it's almost as handy as "boustrophedonic", which also hails from the early 17th century. One gets the sense that the English were coming up with all kinds of random abstract ideas around that time, and discovering that they hadn't taken enough French words from the Normans to account for them all... so went on a mostly Latin and Greek borrowing spree to fill in the various gaps.

I don't believe anyone finished off the proof that we can convert monochromatic monophase gliders into arbitrary slow-salvos. Fortunately, we can. Firstly, use the following technique to move a block as far away as necessary:

calcyman wrote:I don't believe anyone finished off the proof that we can convert monochromatic monophase gliders into arbitrary slow-salvos. Fortunately, we can. Firstly, use the following technique to move a block as far away as necessary... and then coax it into a honeyfarm of the correct parity* to use Chris Cain's 4-glider recipes from the HBK project...

This seems good as a proof, but not so good for making estimates of how many bits will have to be stored in the Sakapuffer position, to complete a construction-with-cleanup along the lines of the 35-glider knightship.

Are there any out-of-date pieces in the summary write-up? I just went back and put in a note about a good source for the cleanup trigger glider.

A recent estimate was that we might be able to actually simulate an RCT-based construction in HashLife, up to something like 65,000 bits encoded in the Sakapuffer position, with current technology.

It seems to me that 65,000 is several orders of magnitude too small to accomplish all the necessary cleanup described in the summary. The construction method as described takes

several bits to make a single perpendicular glider,

several perpendicular gliders to make a single reverse-parallel glider aimed at Target T (which we also have to spend a lot of gliders to get into place in the first place)

several reverse-parallel gliders to make a single slow^2 perpendicular glider aimed at the "hand" part of Target T which we also have to have constructed somehow, early on

... and then several slow^2 perpendicular gliders, to say the least, to actually construct anything interesting.

Seems like a pulsar might be about as far as we're going to get in practice, even without trying to design and construct the Painfully Complicated Seed Constellations that would be required to make a clean RCT recipe for something like a 35-glider knightship.

(?)

I think I do agree with something calcyman sent in an email a few weeks ago, that maybe hasn't quite been stated on this thread (though it's implied by this post, I think). It's at least somewhat reassuring that a 35-glider knightship wouldn't need a BABC design. The ends of the diagonal arms will already be in roughly the right locations to place seeds for the gliders that make the GPSEs:

In an email, calcyman wrote:... we don't need a BABC design or sliding-block memory or similar in order to get a record-breaking knightship: we just make the cleanup salvos leave a block at the back of each of the four diagonal arms, and then slow-salvo-manipulate these into the four (fixed!) tips of the quincunx seed.