The apgcode detection seems to work with Generations rules. I tried identifying the period-4 Brian's Brain spaceship:
Code: Select all
x = 11, y = 5, rule = /2/3
AB2.AB$AB.AB$.AB.A4.B$2.AB4.A.B$4.AB2.B!
using the following code:
Code: Select all
apg::lifetree<uint32_t, 6> lt4(500); // construct a 4-layer lifetree with 500MB of hashing memory
apg::pattern bb(<4, "AB2.AB$AB.AB$.AB.A4.B$2.AB4.A.B$4.AB2.B!", "g3b2s"); // initialise a pattern inside lt4 with Generations rule g3b2s
std::cerr << bb.apgcode() << std::endl; // compute and print the apgcode
which gives the apgcode
xq4_3482h8a_03482lx8. (Yes, multistate apgcodes have multiple underscores, with each component giving a layer of the pattern. However, it's somewhat complicated as to how these layers map to Golly's state numbers, especially in the case of Generations rules.)
Saka wrote:Generatioms is being added too??? Calcyman, is Catagolue EVER in say, 7+ years, going to support custom rules?
It already does, inasmuch as it basically accepts anything that you choose to pass off as a rule name, symmetry type, and apgcode. If you make a search program which produces haul files for your favourite CA, then Catagolue will happily build a distributed census (as you discovered with Saka_Test).
The search program needn't even be a soup search: if you have a depth-first search program such as gfind or zfind, and you have a correspondence between positions in the search tree and alphanumeric strings (where prefixes correspond to ancestors), then you can conduct a distributed search for (say) width-20 c/6 spaceships using the existing Catagolue framework. If you incorporate all of zfind's command-line hyperparameters (period, offset, memory size, etc.) into the beginning of this string, then you can simply have a 'symmetry' called zfind whose tabulations will include things such as xq7, xq10, xq19 (potentially!), etc. And this will work without changing Catagolue in any way.
I'm surprised no-one has tried anything along these lines. The closest thing was my slow-salvo symmetry, but that was ugly in terms of implementation (indeed, I recall there was some non-deterministic element). Ideally every Catagolue-hosted search should be completely deterministic, with the 'randomness' only being present in the haul seed (as is the case for apgsearch).
As well as finding new spaceships in a systematic and distributed manner, it may help inform which combinations of hyperparameters are most effective for running zfind.
What you probably wanted to ask was:
is apgsearch EVER in say, 7+ years, going to support custom rules?
Maybe. The current progress on v4.0 has completely separated various levels of abstraction, so that you can write custom
backends (as I've done for Generations, and will be doing for LtL). Any backend you write in this manner must take a 32-by-32 square of cells and return the 16-by-16 centre square after a number of generations (usually 1 for simplicity).
Once you've written that, it is automatically compatible with either of two
containers (apg::pattern, which runs HashLife, and apg::upattern, which is based on vlife). So, provided you can write the C++ code to run a 32-by-32 square in your rule, the rest of the lifelib boilerplate code will be able to run unbounded universes efficiently in either a conventional or hashed manner. HashLife has the advantage that for regular patterns, it will eventually memoize all of the 32-by-32 tiles and never need to call your backend code again.