Fantastic! I'm not sure if there's an "or" missing here, though: this is given as "FlipOrthRot90" rather than "FlipOrthorRot90". It's one or the other, since applying both just gets us back to the original pattern.
Code: Select all
x = 15, y = 15, rule = B3/S23
7bo$6bobo$7bo2$5b5o$4bo3bobo$bo2bo4b2o2bo$obobo5bobobo$bo2b2o4bo2bo$4b
obo3bo$5b5o2$7bo$6bobo$7bo!
On that topic, there are also oscillators which could be described as "FlipDiagorRot90". Currently these are just described as Rot90, but flipping diagonally in either direction also gets us the transformation. Here are some small examples:
Code: Select all
x = 1, y = 3, rule = B2i3i/S05i
o$o$o!
Code: Select all
x = 2, y = 4, rule = B3i/S5i
2o$2o$2o$2o!
In practice, pure Rot90 would only apply to oscillators which are C2_1 or C2_4-symmetric, such as the following:
Code: Select all
x = 7, y = 5, rule = Goat Flock
bo$o4bo$bo3bo$bo4bo$5bo!
----
I think the only remaining Mod ambiguities are the following patterns: mirror symmetric objects which could either be flipping or rotating. Here's what I believe to be an exhaustive list of such cases:
Analysed as FlipX, but could also be Rot180; would be called "FlipXorRot180"
Code: Select all
x = 4, y = 10, rule = B2cek3jnqr/S2-n3-acij
2b2o$2obo$3bo$bo$bo$bo$bo$3bo$2obo$2b2o!
Code: Select all
x = 2, y = 3, rule = B3ai4a5aiy7e/S2-en3-ciky4i5i6i
bo$2o$bo!
Analysed as FlipY, but could also be Rot180; would be called "FlipYorRot180"
Code: Select all
x = 10, y = 4, rule = B2cek3jnqr/S2-n3-acij
bo6bo$bob4obo$o8bo$3o4b3o!
Code: Select all
x = 3, y = 2, rule = B3ai4a5aiy7e/S2-en3-ciky4i5i6i
bo$3o!
Analysed as Rot180, but could also be Flip⟋; would be called "Flip⟋orRot180"
Code: Select all
x = 4, y = 4, rule = B2-an3aiy7c/S1e2n3kr6i
b3o$obo$2o$o!
Analysed as Rot180, but could also be Flip⟍; would be called "Flip⟍orRot180"
Code: Select all
x = 4, y = 4, rule = B2-an3aiy7c/S1e2n3kr6i
3o$bobo$2b2o$3bo!
Objects such as the following would still be classed as plain FlipX, FlipY, Flip⟋ or Flip⟍, since they can't become their halfway-through-their-period forms simply via rotation.
Code: Select all
x = 4, y = 4, rule = B23acer4ejn5cejr/S03-an4ekrwy5cei
o$3bo2$3bo!
Code: Select all
x = 3, y = 3, rule = B2-k3q4iy5ijr7c/S12k3ajr4it5ciqr6ae
obo$2bo$2bo!
If all of these are resolved, I believe that there will be no more possible ambiguities with Mod. I'll check as many patterns across as many supported rulespaces as I can just to be sure, but this should be a complete set.
----
rowett wrote: February 28th, 2023, 3:44 amin state 6 cases it can not be. I think it can be solved by checking the state 6 cell symmetry at those points rather than needing to validate every generation in the period.
Tangentially related: I've been wondering for a while if it'd make sense for [R]History and [R]Super state-6 cells to also be displayed in oscillator period maps. Since they directly have an influence on pattern evolution (unlike other even-state cells) I think pointing out where they are on period maps would communicate important information, since having them just be completely invisible seems wrong to me given they're an integral part of the oscillator. I'm not sure if you'd agree on this, though.
Code: Select all
x = 9, y = 10, rule = LifeHistory
$5.F2$F.A.A$2.A2.A2.F$2.A2.A$4.A$.F$2.F$6.F!
----
rowett wrote: February 27th, 2023, 1:36 pm
muzik wrote: February 27th, 2023, 1:27 pm
Why isn't strict volatility calculated for Margolus rules and two-state ruletable rules?
Because those items haven't made it to the top of the backlog.
I was under the impression that since many aspects of Identify have been improved for 2-state alternating rules including B0, particularly Strict Volatility and the period map, that it'd be simple to switch it on for Margolus rules since they're also 2-state rules which use an alternating engine. Since it isn't enabled yet, I assume there are other considerations for Margolus that would make such a change far less trivial than I'd have expected. I'm curious to know what exactly these would be, though - what are they?
