Hacking apgsearch
Posted: October 15th, 2014, 3:09 am
This thread is to discuss variations of apgsearch which go beyond incremental improvements and minor changes to the program.
First off, a few ideas:
With all of these ideas for variations, it would also be nice to have the core stabilisation, object identification, and rule generation code in a separate library which each of these ideas could draw on, rather than having it incorporated into each individual variation.
First off, a few ideas:
In the next post I will present apgsearch-blonksoup.pywildmyron wrote:Yes, I have. I've been meaning to describe what I'm doing and I'd like to get some feedback. At this stage I haven't posted the code to do it because I'm still making changes to the soup function, and that causes the results for a given soupid to change.dvgrn wrote:Are you generating ash object positions with a script, and classifying them with apgsearch? I've been thinking about trying something like this, but other things keep getting in the way.wildmyron wrote:I also have been searching for glider reactions with a collection of common ash objects. There are a lot of reactions like this (not just switch engines)...
dvgrn wrote:I'm interested in a couple of possible variants of this idea for modifying apgsearch. One is an exhaustive search for switch engines in the glider+2 blonks search space, for some reasonable MxN (to be gradually increased). Another is a search for switch engines and other interesting things, starting from guaranteed glider-constructible pieces (a few well-spaced small still lifes plus some number of incoming gliders and/or *WSSes, to get an active reaction going.) That kind of thing might go in a new thread called something like "Hacking apgsearch", if you want to go that route.
dvgrn wrote:A third search project, which might be most interesting for Sparse Life early-universe analysis, is a recursive enumeration of single glider collisions into blonks. Let G+blonk settle into quiescence, then hit each possible ash pattern with every possible new G from every direction... collect all those settled ash patterns, and repeat until switch engines appear. Seems as if this should only take about four or five gliders...!
NickGotts posted testquiescence which could help reduce the higher incidence of error correction in apgsearch-blonksoup. This occurs because an escaping glider from a stabilised reaction can collide with a blonk placed elsewhere in the original pattern.NickGotts wrote:I've uploaded to "Golly scripts" in the Scripts forum, code to test whether the current position is "quiescent", i.e. consists solely of still lifes, oscillators, gliders and *WSSs, with the gliders and *WSSs being so placed that they will never interact with each other, or with any of the still lifes or oscillators. It's much less ambitious than the stabilisation test in apgsearch, but serves my purposes (mainly, looking for switch-engines in the output of multiple patterns) well.
I have an in-progress implementation of apgsearch for a non-totalisitic rule - auxillary rules generated by hand. APG_ClassifyObjects only needs adaptation if different common objects need to be handled with it. APG_CoalesceObjects turned out to be harder than I thought because the "bridge inductor" rules are more complicated than simply testing number of alive neighbours.wildmyron wrote:My impression is that it would work really well after some adaptation. There are several places where semi-totalistic rules and rule notation are assumed. In particular, the auxillary rules and various tests that check which rule is being used. Some work would be required to generate the auxillary rules and also account for assumptions about the rule string (such as the test for glider existence). You could either create custom rules for APG_CoalesceObjects, APG_ClassifyObjects, and APG_ContagiousLife; or modify the rule generator to be able to handle rules which are not semi-totalistic. My impression is that APG_ClassifyObjects would require the most work to adapt, but I haven't thought through the details. I have been thinking about similar adaptations for multi-state rules, but I suspect that's even more complicated.Extrementhusiast wrote:How well would the apgsearch method work on a rule like sansdomino_s13?
With all of these ideas for variations, it would also be nice to have the core stabilisation, object identification, and rule generation code in a separate library which each of these ideas could draw on, rather than having it incorporated into each individual variation.