dvgrn wrote:I might as well recompile to get a loop with an 8N period -- would rather have that anyway for the zooships, because adjustability to HashLife-friendly periods is nice. Will do the rework as a walkthrough, so that it's easier to follow along and see how easily slsparse handles this kind of thing.
All the pieces are saved, so I'll edit in a walkthrough here. For now, 3,506,916 appears to be the minimum period for a strict volatility-1 oscillator that can be adjusted to any higher period, at least using this loop design.
It's not all that difficult to reduce that number slightly, by recompiling with slightly cleverer destruction recipes for example. Ultimately I'm guessing a custom single-channel compiler can get the number down under two million.
The p3506916 oscillator can be reduced to one eighth of the current loop size -- one recipe is enough, though the period has to go up slightly to p3506920+8N:
But the p3506917 can only be reduced by going back to the previous slightly cheaper but non-universal recipe.
Here's a file that can be adjusted to make an infile.mc for both the initial destruction stage, and the following construction stage:
Code: Select all
x = 16091, y = 16074, rule = LifeHistory
In fact, if the distance is increased between the construction target and the destruction gliders, to anything above 1000 cells or so, the construction and destruction recipes can be compiled simultaneously, and the destruction recipe becomes available for slsparse to optimize the order of the destruction gliders to reduce the total single-channel cost.
That is, when gliders can be sent in many possible orders, slsparse tries to find orders that minimize the cost of moving the elbow block to reach the right locations for the glider output recipes. The space between construction target and destruction gliders has to be above 1000 because otherwise the whole resulting recipe is treated as the same cluster, and then you have the problem that slsparse might well sort the gliders into an order where the destruction process starts before the construction process is finished... which isn't so useful.
In this case, if you compile the recipe all at once, you'll have to pick it apart and reverse the two halves anyway. Slsparse always adds gliders on to the end of its construction recipe, which gives us construction-then-destruction. But to make a strictly volatile oscillator, we need to do destruction-then-construction, followed by a long period where the circuitry is being used to reflect and split signals.
So let's do each compilation step separately.
Stage One: Destruction
In the above pattern, remove the three constellations in the southeast, save the remaining gliders and block-on-mango as "infile.mc" in the same folder as slsparse, and run slsparse. The block-on-mango tells slsparse where the elbow block should start, and which side of the block will be struck by the single-channel stream.
I initially sent this to slsparse with the elbow block in a more or less random location, then ran the resulting output.mc and watched until the initial move of the elbow block was done, just before the glider recipes started... then went back to infile.mc and moved the elbow block to that position. That tends to save a little length in the final recipe. At the end of a construction, slsparse automatically moves the elbow block back to where it found it. In this case, that's exactly where we're going to need it for the next stage.
... Then I had to go back and do everything all over again with the elbow block shifted (1,0) to start on the other color. My first attempt with all Scorbie Splitters instead of Snarks had turned out significantly more expensive. But then I totally forgot that when I replaced the lossless-elbow Scorbie Splitters with Snarks, that that changed the glider color so I would have to move the elbow slightly as well. So the first recipe that came out of slsparse worked perfectly, but its single-channel gliders were coming in on the wrong color lane so it was impossible to use
Stage Two: Construction
Go back to the above pattern, restore the three constellations, and delete all of the gliders but retain the same exact block-on-mango.
Notice there are three slightly different requests to slsparse in the three metaclusters.
1) In the far southeast, there's a red block near the Snark. The destruction salvo leaves behind a block in this location, so to get a Snark constructed again, we have to start from this block.
2) In the middle constellation, there's a white block. This is a part of the Scorbie Splitter; the destruction salvo is designed so it never shoots that block down. The process of using that block as an initial hand target for the construction arm temporarily destroys the block, so we still end up with a strict volatility-1 oscillator.
3) In the northwest, there's a white block that's not part of the Scorbie Splitter -- it's nearby, but out of the way of the active reaction when the Scorbie Splitter is in use. In this case, the destruction salvo removes the entire Scorbie Splitter, which then has to be rebuilt starting from this block. The block is white (state 3 LifeHistory, a marked ON cell) instead of red (state 4 LifeHistory, a marked OFF cell) because we also need to rebuild this block on every cycle. Otherwise after the next destruction cycle there will be nothing to rebuild from. If an initial hand block target location partly overlaps an object that needs to be constructed, then a mix of marked ON and OFF cells can be used.
If the starting block locations do not come near overlapping any of the structure to be constructed, then a two-state RLE file can be used instead, with a PS4B still life to mark the target block location -- that's Pond Siamese Four Beehives:
x = 8, y = 8, rule = B3/S23
#C [[ THUMBNAIL THUMBSIZE 3 ]]
Making sure you've saved the previous contents of outfile.mc, save the revised infile.mc (with three target constellations and no construction gliders) to the same location as before, and run slsparse again.
This time the compilation process will take a little longer, but eventually you'll end up with a new outfile.mc containing a single-channel recipe that produces correctly aligned circuitry, starting from just three initial blocks.
Putting It All Together
In the single-channel recipe from Stage One above, add a glider 90 ticks behind the final glider -- that's 22.5 cells diagonally. Run the recipe to make sure that a 90-tick following distance is safe. Yup, you get a nice clean pi-debris pattern, no ugly explosion or other weirdness. That means you can safely copy in the entire single-channel construction recipe, overlapping that one trailing glider.
Try running the combined recipe. The circuit structure should get whittled down with gliders to a three-block minimum, then magically restore itself. If you change all the circuit cells to state 5 (yellow) in LifeHistory, you should find that they're all white by the end of the cycle, showing that they've all turned off at some point, then back on again.
Activating the Loop
Paste the single-channel recipe into the current infile.mc, except instead of overlapping with the block in the block-on-mango, overlap it with the initial block in the middle Scorbie Splitter constellation.
Move the block-on-mango northwest, a distance of about half the length of the full recipe. Move the Snark southeast by the same exact distance that you just moved the block-on-mango. Remove the mango from the block-on-mango.
Move the other Scorbie Splitter southeast, by the full length of the recipe (for now).
Copy the whole current pattern to the clipboard.
Run the pattern by some appropriate multiple of 8 ticks, until the single-channel recipe has been reflected twice and is heading out into empty space.
Paste the pattern in the clipboard, rotating it to match the single-channel recipe's current orientation. Overlap the old and new recipes (which of course will match). Use shift.py to do this if necessary, dropping the pattern in an arbitrary location and then moving it by (X, Y) to line up the recipes exactly.
That's all there is to it -- the pattern in Golly should now be a working oscillator. The loop can be reduced in size considerably by moving all the pieces -- or it can be increased in size to be able to fit eight copies of the recipe in it, to allow for adjustability to any sufficiently large period. Luckily Scorbie Splitters have a transparent output lane in the right place to make it easy to feed in a long straight recipe into a minimized diamond loop.
If anybody actually tries this walkthrough and finds any painfully confusing or Just Plain Wrong bits, please feel free to let me know.
Really It's All About Getting To The Zoo
The interesting part will be recompiling this along with the previous circuitry, to produce a menagerie of small-step zooships. Only fairly minor changes are needed to the slsparse input files, as long as two separate overlapping loops are used.
With just one loop circuit, the total length of recipe would get cut almost in half, but it would be a little trickier to set up a switching system to decide which half of the loop's DNA will be expressed on each side of the loop.