Pattern viewer for forum threads

[muzik]

A few questions I have about Identify:
- Is it safe to assume that Identify on objects that utilise PASTE generally isn't supported?
- For diagonally-flipping objects, why is the mod expressed as a combination of an orthogonal flipping action and a rotation (as opposed to a single diagonal flipping action)?
- Why isn't strict volatility calculated for Margolus rules and two-state ruletable rules?
- On the proposed "bounded grids may be treated a a whole unit by Identify in future" change: would this only apply to bounded grids where both axes are finite; would bounded grids with one infinite axis still be treated like an unbounded plane?

[rowett]

Is it safe to assume that Identify on objects that utilise PASTE generally isn't supported?

Yes

For diagonally-flipping objects, why is the mod expressed as a combination of an orthogonal flipping action and a rotation (as opposed to a single diagonal flipping action)?

History. The transformations were built on some basic building blocks. Diagonal flip is built from orthogonal flip and rotate so it was notated as such.

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.

On the proposed "bounded grids may be treated a a whole unit by Identify in future" change: would this only apply to bounded grids where both axes are finite; would bounded grids with one infinite axis still be treated like an unbounded plane?

Yes

[muzik]

Identify doesn't detect that this is periodic at all. Taking a completely random guess, it might be constantly assuming that it's a diagonal spaceship and confirming it's not, all the while being oblivious to its overall horizontal displacement.

True. Is it possible to reproduce this kind of movement without PASTE?

Code: Select all

x = 1, y = 1, rule = MAPCAAAIAAAAAAAAAAAAAAAAAAAAIAAAAAAgACAAAAAAACAAAAAAACAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAA:P0,2
o!

Code: Select all

x = 1, y = 1, rule = MAPCAAAIAAAAAAAAAAAAAAAAAAAAIAAAAAAgACAAAAAAACAAAAAAACAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAA:T0,4
o$o!

[muzik]

I've been testing some further exotic items in non-isotropic rules with Identify. Most are handled as expected, however there are still a few that may need looking at. For example, these diagonal domino spaceships might be better described as having a mod of 1 with a diagonal flip transform:

Code: Select all

x = 1, y = 2, rule = MAPAAAAAAAAgAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAA
o$o!

Code: Select all

x = 2, y = 1, rule = MAPAAAAAIAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
2o!

Likewise for this 3-cell L-shaped spaceship - it's period 2, but it appears diagonally flipped on odd generations, so a mod of 1 would make sense here:

Code: Select all

x = 2, y = 2, rule = MAPAAAAAIAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAACAAAAAAACAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAA
2o$bo!

For comparison, here's an orthogonally tumbling domino. While one phase is indeed the other phase rotated by 90 degrees, the mod being 2 instead of 1 makes sense in this case since 90-degree rotation or diagonal flipping isn't a valid transformation for orthogonal spaceships in 2D.

Code: Select all

x = 2, y = 1, rule = MAPAAAAgAAAAAAAAAAAAAAAAAAAgAAAAAAAgAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
2o!

Also for comparison, here's a domino oscillator, which Identify correctly identifies as having a mod of 1. This is what I think the diagonal domino ships above should be classified as. Below that are two examples of L-shaped oscillators for comparison with the L-shaped ship above; their mods are also calculated as expected.

Code: Select all

x = 2, y = 1, rule = MAPAAAggAgAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
2o!

Code: Select all

x = 2, y = 2, rule = B3a/S2a
2o$bo!

Code: Select all

x = 2, y = 2, rule = MAPEEAAIAAAAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAA
bo$2o!

----

Side note: objects like the oscillating domino above are one of a handful of reasons why I'd prefer diagonal flipping in Mod to be stated as a flip across a diagonal, rather than as an orthogonal flip and a rotation. The oscillator is classed as Rot90CWFlipX. A domino is invariant across orthogonal flips, however we can't just say the oscillator is Rot90CW since that's reserved for oscillators with periods divisible by 4. Rot90 doesn't work either, since that only applies to oscillators which are either C2_1, C2_4, D4_+1, D4_+4, D4_x1 or D4_x4 symmetric in each individual phase, which the domino fits none of. Something along the lines of "Flip\" or "Flip⟍" would get rid of this issue, since it'd be immediately clear in that case that the object just flips, as well as what direction it's flipped in. Some objects on bounded grids are similar in this respect:

Code: Select all

x = 10, y = 10, rule = LifeHistory:T10
9.A8$9.A$B7.BA!

[rowett]

Identify doesn't detect that this is periodic at all. Taking a completely random guess, it might be constantly assuming that it's a diagonal spaceship and confirming it's not, all the while being oblivious to its overall horizontal displacement.

True. Is it possible to reproduce this kind of movement without PASTE?

Code: Select all

x = 1, y = 1, rule = MAPCAAAIAAAAAAAAAAAAAAAAAAAAIAAAAAAgACAAAAAAACAAAAAAACAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAA:P0,2
o!

Code: Select all

x = 1, y = 1, rule = MAPCAAAIAAAAAAAAAAAAAAAAAAAAIAAAAAAgACAAAAAAACAAAAAAACAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAA:T0,4
o$o!

Extra credit: Is it possible to reproduce this kind of movement without Bounded Grids?

[muzik]

Extra credit: Is it possible to reproduce this kind of movement without Bounded Grids?

Code: Select all

x = 8001, y = 4, rule = MAPCAAAIAAAAAAAAAAAAAAAAAAAAIAAAAAAgACAAAAAAACAAAAAAACAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAHistory
.8000F$A2$.8000F!
[[ ZOOM 8 X -3975 ]]

Code: Select all

x = 8, y = 194, rule = W90History
3.A$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.
F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.
F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.
F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.
F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.
F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.
F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.
F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.
F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.
F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.
F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.
F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.
F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.
F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.
F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.
F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.
F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.
F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.
F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F$2.F2.F3$
F6.F$8F!

[muzik]

I've been testing some further exotic items in non-isotropic rules with Identify. Most are handled as expected, however there are still a few that may need looking at.

Interestingly, if we add dying states for these patterns, Identify gives the expected results:

Code: Select all

x = 1, y = 2, rule = MAPAAAAAAAAgAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAA/3
o$o!

Code: Select all

x = 2, y = 1, rule = MAPAAAAAIAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/3
2o!

Code: Select all

x = 2, y = 2, rule = MAPAAAAAIAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAACAAAAAAACAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAA/3
2o$bo!

And for the orthogonal spaceship, it doesn't give a Mod transform, which is also as expected:

Code: Select all

x = 2, y = 1, rule = MAPAAAAgAAAAAAAAAAAAAAAAAAAgAAAAAAAgAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/3
2o!

Slower example L-ship:

Code: Select all

x = 2, y = 2, rule = MAPAAAAAAAAIAAAAAAAAAAAAAAAgIAAAAAAAAAAAAAAAAAAAAAAgACAAAAAAAAAAAAAgACAAAAAAAAAAAAAAAAAAA
o$2o!

Code: Select all

x = 2, y = 2, rule = MAPAAAAAAAAIAAAAAAAAAAAAAAAgIAAAAAAAAAAAAAAAAAAAAAAgACAAAAAAAAAAAAAgACAAAAAAAAAAAAAAAAAAA/3
o$2o!

[rowett]

Extra credit: Is it possible to reproduce this kind of movement without Bounded Grids?

... and now in a vanilla 2-state rule?

[muzik]

Extra credit: Is it possible to reproduce this kind of movement without Bounded Grids?

... and now in a vanilla 2-state rule?

That's tricky, since two forms of B1c are required, but only one must be executed at a given time. There has to be a method of telling the cell which of the two transitions to use. For the alternating rule method, this is simply the rule applied at a given generation. For non-alternating rules, this has to be done via suppression of birth either via the use of bounded grids or state-6 cells. I am not sure of any other methods.

[muzik]

The following pattern is highly buggy when loaded:

Code: Select all

#CXRLE Pos=-192,-192
x = 1, y = 1, rule = MAPCAAAIAAAAAAAAAAAAAAAAAAAAIAAAAAAgACAAAAAAACAAAAAAACAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAA
o64$o64$o64$o!
[[ THEME Generations MAXGRIDSIZE 9 ]]

Also, why are popup viewers such as the one from the thumbnail on the following page loaded up with smaller initial dimensions than usual (also causing them to start offset from the right)?: https://catagolue.hatsya.com/object/xq4 ... 34567l0346 Residual viewer code from when the minimum width was still 480?

This is stated to have a mod of 64, despite the suppression at each side being slightly different. This feels like the kind of issue which is always present, though, and increasingly subtle versions will always persist for every other one which is fixed, so I'm not sure if it's worth trying to fix this at all.

Code: Select all

x = 90, y = 32, rule = LifeHistory
13$66.F2.2A2.F$69.2A$75.F4$77.F$81.F$65.F2$89.F$69.F$73.F7.A7.F$79.A.
A$80.2A2$75.F$80.2A$77.F2.2A2.F!

[rowett]

The following pattern is highly buggy when loaded

Fixed, thanks.

Also, why are popup viewers such as the one from the thumbnail on the following page loaded up with smaller initial dimensions than usual

Because the pattern is invalid so some of the setup code doesn't run. I'm not going to fix it.

This is stated to have a mod of 64, despite the suppression at each side being slightly different.

Identify doesn't care about the state 6 cells: it's identifying a 2-state pattern.

[muzik]

This is stated to have a mod of 64, despite the suppression at each side being slightly different.

Identify doesn't care about the state 6 cells: it's identifying a 2-state pattern.

The evolution of the pattern is still impacted, though; the envelope of the pattern as well as the period map aren't 180-degree rotationally symmetric like is usually the case for FlipXY patterns. The differences are minor, but they're still there.

[rowett]

The evolution of the pattern is still impacted, though; the envelope of the pattern as well as the period map aren't 180-degree rotationally symmetric like is usually the case for FlipXY patterns. The differences are minor, but they're still there.

True. It's because Identify only checks two Mod-generation pairs to validate that the symmetry is consistent. Normally that's enough but in 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.

[muzik]

Why are certain patterns given as "FlipXY", rather than "Rot180"? The term "Rot180" has been used in the changelog (build 862), and I think it'd be a better description of such patterns: it fits better with Catagolue's symmetry notation of C2, it ties in well with the recently renamed Rot90, and if we change FlipXY to Rot180 then "Flip" would only appear in Mod transforms that result in the pattern flipping (i.e. they can't be returned to their original orientation through rotation alone). This has the added benefit that "Flip" wouldn't appear in Identify results for chiral rules such as PCA_4, where reflection does not guarantee identical evolution.

Identify gives different results for bounding box for this spaceship despite them acting identically otherwise:

Code: Select all

x = 68, y = 9, rule = 23/34/128
4.sW.sT3.sK.sH3.rW.rT3.rK.rH3.qW.qT3.qK.qH3.pW.pT3.pK.pH3.W.T3.K.H$3.
sXtAsUsTsU.sLsMsIsHsI.rXsArUrTrU.rLrMrIrHrI.qXrAqUqTqU.qLqMqIqHqI.pXqA
pUpTpU.pLpMpIpHpI.XpAUTU.LMIHI.3A$2.tBtD2tA2sVsNsP2sM2sJsBsD2sA2rVrNrP
2rM2rJrBrD2rA2qVqNqP2qM2qJqBqD2qA2pVpNpP2pM2pJpBpD2pA2VNP2M2JBD2A$2.tC
.2tDsUsXsOsT2sPsIsLsCsH2sDrUrXrOrT2rPrIrLrCrH2rDqUqXqOqT2qPqIqLqCqH2qD
pUpXpOpT2pPpIpLpCpH2pDUXOT2PILCH2D2A$4.tFtDtBsXsVsTsRsPsNsLsJsHsFsDsB
rXrVrTrRrPrNrLrJrHrFrDrBqXqVqTqRqPqNqLqJqHqFqDqBpXpVpTpRpPpNpLpJpHpFpD
pBXVTRPNLJHFDBA$3.tCtFsUtB2sVsOsRsIsN2sJsCsFrUsB2rVrOrRrIrN2rJrCrFqUrB
2qVqOqRqIqN2qJqCqFpUqB2pVpOpRpIpN2pJpCpFUpB2VORIN2JCFABA$.2tG2tDsTsV
2sS2sPsHsJ2sG2sDrTrV2rS2rPrHrJ2rG2rDqTqV2qS2qPqHqJ2qG2qDpTpV2pS2pPpHpJ
2pG2pDTV2S2PHJ2G2D2A$tFtGtCtBtC.sRsSsOsNsO.sFsGsCsBsC.rRrSrOrNrO.rFrG
rCrBrC.qRqSqOqNqO.qFqGqCqBqC.pRpSpOpNpO.pFpGpCpBpC.RSONO.FGCBC$.tE.tB
3.sQ.sN3.sE.sB3.rQ.rN3.rE.rB3.qQ.qN3.qE.qB3.pQ.pN3.pE.pB3.Q.N3.E.B!
[[ THEME Blues ]]

Code: Select all

x = 68, y = 9, rule = R1,C128,S2-3,B3-4
4.sW.sT3.sK.sH3.rW.rT3.rK.rH3.qW.qT3.qK.qH3.pW.pT3.pK.pH3.W.T3.K.H$3.
sXtAsUsTsU.sLsMsIsHsI.rXsArUrTrU.rLrMrIrHrI.qXrAqUqTqU.qLqMqIqHqI.pXqA
pUpTpU.pLpMpIpHpI.XpAUTU.LMIHI.3A$2.tBtD2tA2sVsNsP2sM2sJsBsD2sA2rVrNrP
2rM2rJrBrD2rA2qVqNqP2qM2qJqBqD2qA2pVpNpP2pM2pJpBpD2pA2VNP2M2JBD2A$2.tC
.2tDsUsXsOsT2sPsIsLsCsH2sDrUrXrOrT2rPrIrLrCrH2rDqUqXqOqT2qPqIqLqCqH2qD
pUpXpOpT2pPpIpLpCpH2pDUXOT2PILCH2D2A$4.tFtDtBsXsVsTsRsPsNsLsJsHsFsDsB
rXrVrTrRrPrNrLrJrHrFrDrBqXqVqTqRqPqNqLqJqHqFqDqBpXpVpTpRpPpNpLpJpHpFpD
pBXVTRPNLJHFDBA$3.tCtFsUtB2sVsOsRsIsN2sJsCsFrUsB2rVrOrRrIrN2rJrCrFqUrB
2qVqOqRqIqN2qJqCqFpUqB2pVpOpRpIpN2pJpCpFUpB2VORIN2JCFABA$.2tG2tDsTsV
2sS2sPsHsJ2sG2sDrTrV2rS2rPrHrJ2rG2rDqTqV2qS2qPqHqJ2qG2qDpTpV2pS2pPpHpJ
2pG2pDTV2S2PHJ2G2D2A$tFtGtCtBtC.sRsSsOsNsO.sFsGsCsBsC.rRrSrOrNrO.rFrG
rCrBrC.qRqSqOqNqO.qFqGqCqBqC.pRpSpOpNpO.pFpGpCpBpC.RSONO.FGCBC$.tE.tB
3.sQ.sN3.sE.sB3.rQ.rN3.rE.rB3.qQ.qN3.qE.qB3.pQ.pN3.pE.pB3.Q.N3.E.B!
[[ THEME Blues ]]

Also, another exotic non-isotropic Identify case: Identify can detect flipping orthogonal spaceships, however it doesn't verify if the flipping direction is valid for that direction. Here's one which flips perpendicularly to its direction of travel (FlipX while moving vertically), which is valid and Identify detects it as such:

Code: Select all

x = 2, y = 2, rule = MAPAABEgDAgAAAAAACAIAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAwIAAAAAAAACAAAAAAAAAAA
bo$2o!

However, here's one that flips vertically while also moving vertically, which is impossible for isotropic spaceships. I don't think FlipY should be valid if the spaceship moves vertically (and FlipX shouldn't be if it moves horizontally). So this one should have a mod of 2, not 1.

Code: Select all

x = 2, y = 2, rule = MAPAAAAIAAAAAAAAAAAAAAAAAAAAIAAAAAAgACAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAA
o$2o!

Here's a related spaceship, which has a Rot90CWFlipX transform while moving orthogonally, which should be impossible as that transform is only valid for diagonal spaceships. This, too, should have a mod of 2.

Code: Select all

x = 2, y = 2, rule = MAPAAAAQAAAAAAAAAAAAAAAAAAAAIAAAAAAAIAAAAAAAAAAAAAAAACAAAAAAAAAAAAAgACAAAAAAAAAAAAAAAAAAA
2o$bo!

Again, if we add a Generations state to each of them, Identify gives the correct mod results:

Code: Select all

x = 2, y = 2, rule = MAPAABEgDAgAAAAAACAIAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAwIAAAAAAAACAAAAAAAAAAA/3
bo$2o!

Code: Select all

x = 2, y = 2, rule = MAPAAAAIAAAAAAAAAAAAAAAAAAAAIAAAAAAgACAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAA/3
o$2o!

Code: Select all

x = 2, y = 2, rule = MAPAAAAQAAAAAAAAAAAAAAAAAAAAIAAAAAAAIAAAAAAAAAAAAAAAACAAAAAAAAAAAAAgACAAAAAAAAAAAAAAAAAAA/3
2o$bo!

[rowett]

I've been testing some further exotic items in non-isotropic rules with Identify. Most are handled as expected, however there are still a few that may need looking at.

Fixed, thanks.

Something along the lines of "Flip\" or "Flip⟍" would get rid of this issue, since it'd be immediately clear in that case that the object just flips, as well as what direction it's flipped in.

Done, thanks.

[rowett]

This is stated to have a mod of 64, despite the suppression at each side being slightly different.

Fixed, thanks.

[rowett]

Why are certain patterns given as "FlipXY", rather than "Rot180"?

Done, thanks.

Also, another exotic non-isotropic Identify case: Identify can detect flipping orthogonal spaceships, however it doesn't verify if the flipping direction is valid for that direction.

Fixed, thanks.

[muzik]

KILLGLIDERS appears to work strangely when near the boundary of the grid. If the glider is heading in the general direction of the boundary, it isn't killed.

This is intentional. KILLGLIDERS ignores gliders that are close to, and heading for, the boundary.

The behaviour appears to have changed recently: the glider going away from the boundary is still killed pretty much instantly, however the one going towards it is killed at generation 5 instead of not being killed at all. Is this an intentional change?

----

Unrelated: File:Hotkeys.png might need an update, since Fast Identify no longer exists.

Also, here's the srrangest non-isotropic thing by far: the second pattern here has the same shape in all four phases, but the dead cell moves in a figure eight motion. It could be either FlipX (as it's recognised here) or Rot180. I don't think patterns of this kind show up in normal isotropic rules, however they do show up in Margolus rules. I don't know how, or if, its mod should be handled (perhaps mod 1, transform type "Other"?)

Code: Select all

x = 2, y = 2, rule = MAPABAQIAIAKAAAAACAAAAAAAAAAIAAAIAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAACAAIAAAAAAAAAAAAAAAA
o$2o!

Code: Select all

x = 2, y = 2, rule = MAPABASIAIAIAAAAACAAAAAAAAAAAAAAAAAAICAAAAAAAAAAAAAAACAAAAAAAAAAAAAAACAAIAAAAAAAAAAAAAAAA
o$2o!

[rowett]

The behaviour appears to have changed recently: the glider going away from the boundary is still killed pretty much instantly, however the one going towards it is killed at generation 5 instead of not being killed at all. Is this an intentional change?

Yes

Unrelated: File:Hotkeys.png might need an update, since Fast Identify no longer exists.

Done, thanks.

[muzik]

I can still encounter the blurry period map issue in the latest build for bounding box sizes which are just before it switches to the non-grid display. The dynamic changing between the two forms definitely mitigates the issue when scrolling, however the blur persists for the select few values just before it changes to the non-grid version. Are you able to reproduce it? Remember, you'll need a non-integer "Scale" value in Help > Info > Display for it to happen.

----

On the topic of renaming Mods: would it be possible to change "FlipXorY" to "FlipOrth"? I have a few reasons:
- FlipOrth would fit better with Rot90, since the orthogonal direction is intentionally ambiguous as both of them are valid.
- For patterns which either flip orthogonally or rotate 90 degrees, these would be notated as "FlipOrthorRot90" (as opposed to the current "FlipXorYorRot90"). This would mean that the only "or" used here would be for distinguishing between "orthogonal flipping" and "90-degree rotation", rather than there beating two of them distinguishing between the three options of "horizontal flipping", "vertical flipping" and "90-degree rotation".
- There are also patterns which can be seen as flipping diagonally across either diagonal, such as the bipole. While these could be called "Flip/or\" or "Flip\or/", I don't like the way those look, and "FlipDiag" would make just as much sense in those cases while being consistent with FlipOrth.

Here's a pattern that would be classified as FlipOrth (currently FlipXorY):

Code: Select all

x = 2, y = 3, rule = B3a/S3j
o$2o$bo!

Here's a pattern that would be classified as FlipOrthorRot90 (currently FlipXorYorRot90):

Code: Select all

x = 4, y = 4, rule = R2,C0,S1,B3,NB
bo$o$3bo$2bo!

Here's a pattern that would be classified as FlipDiag (instead of Flip/or\ or Flip\or/; currently it's just given as Flip\, which is ambiguous and doesn't tell the full story)

Code: Select all

x = 5, y = 5, rule = B3/S23
3b2o$2bobo2$obo$2o!

These would continue to be classified as just Flip/ and Flip\:

Code: Select all

x = 2, y = 3, rule = B2c/S2ae3n
2o$bo$o!

Code: Select all

x = 2, y = 3, rule = B2c/S2ae3n
2o$o$bo!

----

A bit lower priority, but could the slashes in Flip\ and Flip/ be replaced with the Unicode symbols ⟍ and ⟋ so they look a bit clearer? Slashes appear a bit steep for my liking (they're much clearer than the older diagonal flip descriptions for sure), but I'm not sure if LifeViewer is allowed to contain Unicode characters in case it causes compatibility issues.

[rowett]

On the topic of renaming Mods: would it be possible to change "FlipXorY" to "FlipOrth"?

Yes, done.

There are also patterns which can be seen as flipping diagonally across either diagonal, such as the bipole. While these could be called "Flip/or\" or "Flip\or/", I don't like the way those look, and "FlipDiag" would make just as much sense in those cases while being consistent with FlipOrth.

Done.

A bit lower priority, but could the slashes in Flip\ and Flip/ be replaced with the Unicode symbols ⟍ and ⟋ so they look a bit clearer?

Yes, done.

[muzik]

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.

----

in 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!

----

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?

[muzik]

Just caught another ambiguous case: oscillators like these (instantaneously C4_1 or C4_4 and becomes its mirror image halfway through) are classified as "FlipOrth", but "FlipDiag" would work just as well, so these can be called "FlipOrthorDiag".

Code: Select all

x = 5, y = 5, rule = B2k3jn4cer5c8/S012a3acn4cy6a7c
3bo$o$2bo$4bo$bo!

Also, after checking the domino shops a second time, they're described as "FlipDiag", but only one flip axis should be valid at a time for spaceships - in this case, Flip⟍. The Generations versions of these have transforms displayed as expected.

Code: Select all

x = 1, y = 2, rule = MAPAAAAAAAAgAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAA
o$o!

Code: Select all

x = 2, y = 1, rule = MAPAAAAAIAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
2o!

Code: Select all

x = 1, y = 2, rule = MAPAAAAAAAAgAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAAA/3
o$o!

Code: Select all

x = 2, y = 1, rule = MAPAAAAAIAAAAAAAAAAAAAAAIAAAAAAAAAAAAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/3
2o!

[rowett]

Fantastic! I'm not sure if there's an "or" missing here, though: this is given as "FlipOrthRot90" rather than "FlipOrthorRot90".

Fixed, thanks.

On that topic, there are also oscillators which could be described as "FlipDiagorRot90".

Done.

Analysed as FlipX, but could also be Rot180; would be called "FlipXorRot180"

Done.

Analysed as FlipY, but could also be Rot180; would be called "FlipYorRot180"

Done.

Analysed as Rot180, but could also be Flip⟋; would be called "Flip⟋orRot180"

Done.

Analysed as Rot180, but could also be Flip⟍; would be called "Flip⟍orRot180"

Done.

[rowett]

Just caught another ambiguous case: oscillators like these (instantaneously C4_1 or C4_4 and becomes its mirror image halfway through) are classified as "FlipOrth", but "FlipDiag" would work just as well, so these can be called "FlipOrthorDiag".

Done.

Also, after checking the domino shops a second time, they're described as "FlipDiag", but only one flip axis should be valid at a time for spaceships - in this case, Flip⟍.

Fixed, thanks.