apgcodes for rotors

[Apple Bottom]

A problem I'm sometimes faced with when a new oscillator shows up in one of the "higher" Life symmetries on Catagolue is determining whether it's already known. Sometimes it's easy - you do learn to recognize variants of common oscillators, for instance -, but often it involves quite a bit of guesswork, checking various websites/stamp collections, and so on.

This is especially true for variants of lesser-known oscillators. For these it would be nice to be able to search for oscillators by rotor, and that in turn requires being able to encode rotors in some way.

We already have a versatile and useful tool to encode objects: apgcodes. So I'd like to propose we use these to systematically encode rotors as well.

There's various ways this could be done. In any given generation only a subset of an oscillator's rotor cells are likely to be alive; it is therefore tempting to encode all generations of the rotor and choose the canonical apgcode the same way that this is being done for the whole oscillator. However, different oscillators might share the same live rotor cells in certain generations without having the same rotor. Worse, reconstructing the other generations (and thus the whole rotor) would be impossible without access to the stator. Therefore I think it would be better to encode the entire rotor at once, i.e. treat a cell as live for the purpose of encoding the rotor if and only if it is alive in at least one generation during the oscillator's evolution and dead in at least one other. Different rotors could still end up with the same code this way, but it would be less likely to happen.

The rules for choosing the "best" orientation to generate the canonical code would apply as usual.

There's also the question of prefixes. Rotor codes could be "raw", encoding the rotor without any metainformation, or prefixed with a suitable prefix (and, ideally, the oscillator's period). For instance, the beacon's rotor might be encoded as just "12", or "xr2_12", with "xr" (or a similar prefix) indicating a rotor code. I'm strongly in favor of prefixed encoding.

Doing this would make it much easier (in principle anyway) to categorize oscillators and verify if new ones are indeed new. Tools such as Jason Summers' Oscillizer that already determine rotors could easily be adapted to determine rotor codes, and pattern databases such as the LifeWiki could be extended to include rotor codes. Codes could also be computed for the various stamp collections to facilitate easy checking, and faced with a potentially new oscillator one would then merely have to use a tool or script to determine its rotor code and look that up. Not finding it anywhere would strongly hint that the oscillator is, in fact, new.

Thoughts?

[Scorbie]

There is prior art on rotors; Dean Hickerson's drifter searcher uses its rotor notation to weed out known oscs.

It uses 0123@ABC, where 0123 are off rotor cells with 0,1,2,3 stator neighbors, and @ABC are on rotor cells with 0,1,2,3 stator neighbors.

Look at the Oscillator discoveries and the readme file of dr for more details

I am okay with other rotor representations, though!

[Apple Bottom]

There is prior art on rotors; Dean Hickerson's drifter searcher uses its rotor notation to weed out known oscs.

It uses 0123@ABC, where 0123 are off rotor cells with 0,1,2,3 stator neighbors, and @ABC are on rotor cells with 0,1,2,3 stator neighbors.

Look at the Oscillator discoveries and the readme file of dr for more details

I am okay with other rotor representations, though!

Ah, neat, I didn't know that.

(For the benefit of anyone else who's reading this, drifter can be downloaded here, and there's also a modified version by Matthias Merzenich here.)

[fluffykitty]

What about storing the rotor and one layer of stator cells around it?