oblique wrote:Exhaustive search on P2 and stable outputs ... what exactly are the starting patterns?
I would just start with something like the Top 10 of the most-found ash particles or something.
Do you have a better list?
No, the Top 10 would be fine -- blinker, block, beehive, loaf, boat, tub, pond, ship, longboat, toad. Though probably you could start with just a blinker (let's say) at the root of the tree, and let the search itself decide what the most-found ash is.
EDIT: That would add things like honeyfarms and traffic lights to the list -- maybe even blockades (LOM debris) and other familiar fours like fleets and bakeries.
It will be useful to record as many conversion paths as possible. For example, if you convert a blinker at (0,0) to a loaf at (-2,-1), then to a honeyfarm at (-6,-7), then to a block at (33,14) --
Code: Select all
x = 213, y = 229, rule = B3/S23
o$b2o$2o28$19bo$20bo$18b3o23$55bo$56bo$54b3o38$76bo$77bo$75b3o38$121bo
$122b2o$121b2o18$155bo$156bo$154b3o18$172bo$173bo$171b3o18$183bo$184bo
$182b3o16$191bo$192bo$190b3o7$203bo$204bo$202b3o4$210b3o!
-- then that also implies a honeyfarm to block(39,21) conversion, and a loaf-to-block and so on.
You can get from a block to a honeyfarm with one glider, so this also gives two block-to-block conversions, or more if you add more (-2,-1) block-pulling gliders. With the original recipe you could do (-3,-1) loaf pulls instead, or (1,-3) blinker pulls.
So... is there a way to store all this search-tree information in a way that makes it easy to string together, say, obj1-to-honeyfarm recipes with honeyfarm-to-obj2 recipes -- when what we're really looking for is just obj1-to-obj2 with a particular (x,y) offset?
I was thinking that on my first trial run I'd just append to a big text list of start objects, end objects, and offsets -- maybe just named objects, different names for different orientations, as in
this project? or maybe just assign each target an integer value or code name (by number of bits or something)?
Then later the list could be sorted into tables by input or output object, to make it more useful -- maybe make it into some kind of doubly linked list, showing all targets that could immediately precede a given target and all targets that could immediately follow it. Or enable a quick lookup: "I have such-and-such block-and-beehive constellation; where can I build a boat within 8 gliders?" or "what's the cheapest way to put a pond at (10+k,2+k)?" But even without any further processing, at least it would be possible to do a text search for "honeyfarm block 39 21" and find out if that specific recipe was known to exist.
It's an interesting detail about slow-salvo searches that they give some amount of polarity to Life objects. Some orientations of boats, for example, are much more common than others. The effect gets much more pronounced when you get to objects like eaters and shillelaghs with eight different orientations instead of just four or two or one.
oblique wrote:As for pruning: I think it would make sense to kill off all reactions that would collide with the neighbouring construction site or reach a with of ... 100? 200?
Maybe an upper limit for the total cell count in any phase of the reaction will be another way to cut down this tree.
Or gliders / (unwanted) SS in the result.
That all matches limits that Paul Chapman included for Glue searches -- there were
"population" and "semiperimeter" limits, anyway.
I'd be very interested in optionally keeping information about single output gliders or spaceships, or even multiple output gliders in the same direction, for use in optimizing self-constructing circuitry. For example, sometimes you have to bend a construction around an extra "slow elbow". For that to work, the trigger glider has to come from the same direction as the construction salvo, the output glider has to go off at 90 degrees, and some target object has to be left over to build the next 90-degree glider.
There's no comprehensive collection yet of clean one-time glider turners ("OTTs") and splitters, in all different orientations. But that's really a separate search: hit every cheap intermediate target (by some definition of "cheap") with every possible glider from all directions, and see which ones produce output gliders and nothing else (well, *WSSes also, let's say). Collect timing statistics on those targets, and suddenly it will become possible to build things like the
loafer seed at a small fraction of the current cost in gliders.
-- Anyway, yes, explosions with large amounts of ash and/or outputs in multiple directions are definitely worth throwing out immediately. Maybe the single-glider outputs could optionally be dumped to a separate file or something, since for many search purposes they won't be useful either.