Pattern viewer for forum threads

[rowett]

192-state Generations rules still don't work as expected on bounded grids.

Fixed, thanks.

[rowett]

On a catagolue page with glider synthesis, such as the blinker, identify results partly overlap with the bottom row of buttons that is shown by default. Comparing with that in a popup viewer (which the page also includes and has a larger height), I see that the identify results box is put at a fixed distance to top row of buttons. Can this be changed to avoid overlap?

I've made a change that should resolve this. You'll see it next time Catagolue updates LifeViewer (which I think it does once per day).

Unrelated old issue, why is this History pattern with PASTE commands initially drawn without state-2 cells defined by RLE?

Fixed, thanks.

[muzik]

If we open a NOGUI viewer, the "centered and with a background" notification style will persist into any other viewer that doesn't have any defined script commands:

Code: Select all

x = 10, y = 10, rule = none
10o$10o$10o$10o$10o$10o$10o$10o$10o$10o!

Code: Select all

x = 8, y = 15, rule = RotationsIII
4bo$o2bo$5bo$2bo2$2bo2$4bo7$7bo!
[[ NOGUI ]]

In [R]History, cells born into marked off cells which were there since the beginning of time (as opposed to those created via the death of states 3 and 5) do not show as alive unless they've survived for at least one generation. This does not happen for [R]Super, and the effect also goes away if you switch to the offset square grid.

Code: Select all

x = 25, y = 15, rule = B2/S2HHistory
A2$A6.D$2.2A3.2D$A2.2A2.3D$7.4D$7.5D$7.6D4.D$7.7D3.2D$7.8D2.3D$17.4D$
17.2DE2D$17.2D2E2D$17.7D$17.8D!
[[ GPS 5 ]]

Code: Select all

x = 25, y = 15, rule = B2/S2HSuper
A2$A6.D$2.2A3.2D$A2.2A2.3D$7.4D$7.5D$7.6D4.D$7.7D3.2D$7.8D2.3D$17.4D$
17.2DE2D$17.2D2E2D$17.7D$17.8D!
[[ GPS 5 ]]

Odd behaviour can be seen with this pattern. When I use it in viewer.html, the embedded viewer doesn't automatically update when I press the View button and I have to interact with the viewer itself to get it to load up. The "Show on Viewer" link also works strangely. The pattern also starts off very discentered. Using Identify will have every button in the viewer remain disabled even when it reaches its conclusion.

Code: Select all

x = 1, y = 2, rule = R1,C0,S,B2,NH:T45,1
o$o!

There's also a functional parity issue with Golly when it comes to higher-range rules and bounded grids: for a grid with dimension 0, LifeViewer throws out an error, but Golly automatically sets that dimension to 2 instead. I'm not sure if LifeViewer should follow Golly's behaviour here or not.

Code: Select all

x = 1, y = 2, rule = R1,C0,S3,B3:T45,0
o$o!

The color that stars are set to appears to persist into other viewers:

Code: Select all

x = 5, y = 5, rule = B2aen3a4e6e/S02e3c4cw6e
4bo2$2bo2$o!
[[ STARS ]]

Code: Select all

x = 5, y = 5, rule = B2aen3a4e6e/S02e3c4cw6e
4bo2$2bo2$o!
[[ COLOR STARS Red ]]

----

Since the new Identify engine is still "experimental", I'm not sure if I should be reporting issues I come across with it or not until it reaches a more stable state. Should I refrain from doing so since the engine is still midway through development and there are still known issues which will be fixed eventually, or should I report anything I come across in the event that there are important underlying issue that should be resolved sooner rather than later?

[rowett]

If we open a NOGUI viewer, the "centered and with a background" notification style will persist into any other viewer that doesn't have any defined script commands

Fixed, thanks.

In [R]History, cells born into marked off cells which were there since the beginning of time (as opposed to those created via the death of states 3 and 5) do not show as alive unless they've survived for at least one generation.

Fixed, thanks.

Odd behaviour can be seen with this pattern. When I use it in viewer.html, the embedded viewer doesn't automatically update when I press the View button and I have to interact with the viewer itself to get it to load up.

Fixed, thanks.

There's also a functional parity issue with Golly when it comes to higher-range rules and bounded grids: for a grid with dimension 0, LifeViewer throws out an error, but Golly automatically sets that dimension to 2 instead. I'm not sure if LifeViewer should follow Golly's behaviour here or not.

I prefer LifeViewer's behaviour. Setting a grid dimension to 0 means unbounded for that dimension. It's inconsistent for it to mean something else for HROT rules even if not supported.

The color that stars are set to appears to persist into other viewers

Fixed, thanks.

Since the new Identify engine is still "experimental", I'm not sure if I should be reporting issues I come across with it or not until it reaches a more stable state. Should I refrain from doing so since the engine is still midway through development and there are still known issues which will be fixed eventually, or should I report anything I come across in the event that there are important underlying issue that should be resolved sooner rather than later?

Aside from further testing and Note 1, above, there's not much more development planned. So if your issues are not related to the note feel free to post.

[muzik]

Here's another mod ambiguity:

Code: Select all

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

Identify classifies this as Rot90CWFlipX, but it could just as easily be considered Rot90CWFlipY.

As it turns out, any diagonally-flipping oscillator is technically ambiguous as well, for a slightly different reason. Here's two examples:

Code: Select all

x = 3, y = 3, rule = B2e3n/S2e3nr
2bo$obo$b2o!

Code: Select all

x = 3, y = 3, rule = B2e3n/S2e3nr
o$obo$2o!

The first is identified as Rot90CWFlipX and the second as Rot90CWFlipY, but they could just as easily be described as Rot90CCWFlipY and Rot90CCWFlipX respectively, even though I don't think these ever actually show up.

I personally think it'd be better to describe diagonally flipping oscillators via a single "Flip" instead, such as Flip/ or Flip\ depending on the direction, since this would be less ambiguous (and also be much easier to visually interpret) and also wouldn't be quite as long. The bipole could be described as either Flip/ or Flip\ by this definition.

[muzik]

Aside from further testing and Note 1, above, there's not much more development planned. So if your issues are not related to the note feel free to post.

Do oscillators with periods above 65536 fall under Note 1? They appear to be subject to the same issues.

Code: Select all

x = 290, y = 268, rule = B3/S23
281bo$280bobo$281bo2$279b5o$257b2o20bo4bo$258bo23bo2bo$258bobo21b2obo
2bo$259b2o18bo5bobobo$278bobo4bo2bo$278bo2bo2b2o$279b2o$248b2o$249bo$
249bobo$250b2o11b2o$262bobo$262bo$262bobo$263b2o11$259bo$258bobo$258bo
bo$259bo52$187bo$187bobo$187b2o10$184bo$184b2o$183bobo69$104bobo$104b
2o$105bo10$101b2o$100bobo$102bo52$30bo$29bobo$29bobo$30bo6$67b2o$66bob
o$60bo5bo$59bobo3b2o$60bo3bo$25b2o36b6o$25bobo35bo4bo$27bo36bo2bo$25bo
bo36bo3b3o$25b2o11b2o30bo$38bobo19b2o$40bo20bo$40b2o16b3o$9b2o30bo16bo
$4b2o2bo2bo29bobo12bobo$bo2bo4bobo30b2o12b2o$obobo5bo18b2o29bo$bo2bob
2o21bobo13b10o5bo$4bo2bo23bo28bo$5bo4bo20b2o9b2o12b2o$6b5o30bobo12bobo
$41bo16bo$8bo31b2o16b2o$7bobo$8bo!

Code: Select all

x = 104, y = 92, rule = B3/S23
93b2obo$93bob2o2$94b5o$72b2o20bo4bo$73bo23bo2bo$73bobo21b2obo$74b2o18b
o5bob2o$93bobo4bobo$93bo2bo2b2o2bo$94b2o6b2o$63b2o$64bo$64bobo$65b2o
12bo$78b2o$77bo$78b2o$79bo11$74bo$73bobo$73bobo$74bo17$29bo$28bobo$28b
obo$29bo11$24bo$24b2o$26bo$24b2o$24bo12b2o$37bobo$39bo$39b2o$2o6b2o$o
2b2o2bo2bo$bobo4bobo$2obo5bo18b2o24bo$3bob2o21bobo23bo$3bo2bo23bo22bob
o$4bo4bo20b2o22bo$5b5o21bo22bo$31bobo9b2o9bo$7b2obo21bobo8bo10bo$7bob
2o30bobo9bobo$41b2o11bo$35b2o17bo$35b2ob2o$38b2o$32b2o$31bobo$31bo8bob
o$30b2o9bobo$43bo$43b2o!

[rowett]

The latest build (897) of LifeViewer contains an experimental new Identify engine. It's typically faster than the original and has more robust checks to ensure oscillator mods are calculated correctly and that spaceships are really spaceships.

Note 1: It's not yet complete and for multi-state patterns does not calculate Active Cells, Temperature or Volatility.

Build 901 now completes the functionality in Note 1.

[muzik]

A minor issue with Mod: identifying something that becomes an oscillator, but isn't instantly one itself, won't return the expected value.

Code: Select all

x = 21, y = 12, rule = B3/S23
18bobo$18b2o$19bo3$12bobo$12b2o$13bo2$o$b2o$2o!

Code: Select all

x = 7, y = 6, rule = B2/S
bo$o3$3bo2bo$4b2o!
[[ MAXGRIDSIZE 9 ]]

[rowett]

A minor issue with Mod: identifying something that becomes an oscillator, but isn't instantly one itself, won't return the expected value.

Fixed, thanks.

[muzik]

For spatially-symmetric spaceships with mod = period, Mod displays an extra symmetry transform output even though it shouldn't.

Code: Select all

x = 2, y = 4, rule = B2/S
o$bo$bo$o!

Code: Select all

x = 2, y = 2, rule = /2a/3
BA$BA!

Code: Select all

x = 1, y = 1, rule = 2PCA4,0,4,8,3,1,10,6,7,2,9,5,11,12,13,14,15
A!

Code: Select all

x = 3, y = 3, rule = B2-an3-cenq4ekr5ac/S1e2ckn3kry4tw
2o$2bo$2bo!

For non-isotropic rules, we can get very unusual results because of this:

Code: Select all

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

[rowett]

For spatially-symmetric spaceships with mod = period, Mod displays an extra symmetry transform output even though it shouldn't.

Fixed, thanks.

[muzik]

I'd expect that both of these would have a mod of 1 and recognise a Flip transform, but that does not seem to happen:

Code: Select all

x = 3, y = 4, rule = LifeHistory
.2A$.A$.2F!

Code: Select all

x = 3, y = 4, rule = B1/S1VHistory
.F$F.F$FAF$.F!

There's also some oscillators in PCA rules that still return invalid results for the three Note 1 statistics.

Code: Select all

x = 2, y = 2, rule = 2PCA4,0,2,4,12,8,5,9,7,1,6,10,11,3,13,14,15
.B$H!

Code: Select all

x = 2, y = 2, rule = 2PCA4,0,4,8,3,1,10,6,7,2,9,5,11,12,13,14,15
.C$L!

Would it be possible to rename "FlipXY" to "Rot180"? With this change, "Flip" would only appear in Mod results if the pattern ends up becoming its own mirror image. For square grids, 180-degree rotation is equivalent to flipping on two orthogonal axes, which (for cell-centered and vertex-centered cases) is also equivalent to flipping on both diagonals. The same cannot be said of hexagonal grids, since there's an odd number of orthogonal axes and an odd number of diagonal axes, and to get the same effect you'd have to flip on one orthogonal axis and another diagonal axis, which would be a bit confusing. Using Rot180 instead of FlipXY would probably be comparatively more future-proof.

[rowett]

I'd expect that both of these would have a mod of 1 and recognise a Flip transform, but that does not seem to happen

Fixed, thanks.

There's also some oscillators in PCA rules that still return invalid results for the three Note 1 statistics.

Fixed, thanks.

[muzik]

Are Mod outputs currently undergoing refactoring? Objects that previously displayed FlipXorY, Rot90 and the combination of those two are now only displaying one of the possible transformations.

[rowett]

Objects that previously displayed FlipXorY, Rot90 and the combination of those two are now only displaying one of the possible transformations.

Fixed, thanks.

[muzik]

Mods aren't always correctly detected in [R]Super for spaceships.

Code: Select all

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

Code: Select all

x = 3, y = 3, rule = B3/S23History
o$obo$2o!

Code: Select all

x = 3, y = 3, rule = B3/S23Super
o$obo$2o!

Identify also gives different bounding boxes for the following two functionally identical patterns.

Code: Select all

#CXRLE Pos=-2,-2
x = 0, y = 0, rule = B1z/SL:T6
$bo!

Code: Select all

#CXRLE Pos=-2,-2
x = 0, y = 0, rule = R1,C2,S,B1,12,NL:T6
$bo!

Also, a strange non-isotropic edge case: I think that this spaceship should be considered p4 mod 4, as opposed to the p4 mod 2 it's currently assigned. When Identify was redone in build 897, it was classified as having a mod of 4, but now it's regressed back to being 2 again. FlipXorYorRot90 is not a valid mod type for spaceships in 2D.

Code: Select all

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

[rowett]

Mods aren't always correctly detected in [R]Super for spaceships.

Fixed, thanks.

Identify also gives different bounding boxes for the following two functionally identical patterns.

It's not an Identify issue: it's a known issue with bounding boxes with bounded grids. It's on the backlog.

Also, a strange non-isotropic edge case: I think that this spaceship should be considered p4 mod 4, as opposed to the p4 mod 2 it's currently assigned.

Fixed, thanks.

[muzik]

Are Rot90CCW and Rot90CW the wrong way round?

Code: Select all

#C Identify says Rot90CCW, expected Rot90CW
x = 3, y = 3, rule = B2i3aijnq4city5ackqy6cik7c8/S23-a4city5aiknq
3o$o$2o!
[[ ZOOM 10 ]]

Code: Select all

#C Identify says Rot90CW, expected Rot90CCW
x = 3, y = 3, rule = B2i3aijnq4city5ackqy6cik7c8/S23-a4city5aiknq
3o$2bo$b2o!
[[ ZOOM 10 ]]

[rowett]

Are Rot90CCW and Rot90CW the wrong way round?

Depends on which way you think time goes.

[muzik]

Some glide reflective spaceships don't have mods identified anymore:

Code: Select all

x = 3, y = 9, rule = B2acn3cery4acenqr5einq7e8/S12eik3jnry4cik5ijky6ek7
bo$2o2$b2o$3o$bo$2bo2$2bo!

Despite behaving identically, these two patterns return different values for Bounding Box, Heat and Temperature (the bottom has the expected values):

Code: Select all

x = 4, y = 4, rule = B12/SVHistory
4F$FA.F$F.AF$4F!

Code: Select all

x = 4, y = 4, rule = B2/SVHistory
4F$FA.F$F.AF$4F!

Using Identify on this causes the viewer to zoom out a lot for some reason:

Code: Select all

x = 5, y = 5, rule = B2/S2H
o$2o$bo2$obobo!
[[ GRID ZOOM 16 SQUARECELLS X -128 Y -256 STARTFROM 370 MAXGRIDSIZE 9 ]]

Also, Identify used on this diagonal spaceship appears to cause the viewer to freeze once it goes to just under a thousand or so generations. I'm not sure if it's taking a very long time to calculate info (I left it for four minutes, and nothing) or it gets stuck in an infinite loop or outright crashes. On iOS, scrolling in a way that resizes the popup makes it render completely transparent when the viewer is in this busy/looping/crashed state.

Code: Select all

x = 47, y = 73, rule = R2,C6,M0,S6..7,B5..8,NM
5.2A$4.3AB$2.2A2BAC$.2A2BCA2C17.4A$.A3BC4D15.3ABA$2A2BCD2EDE15.D2AB2A
$2AC.2D2ED15.2EA2CAB$A2B2DE19.D.D2CAB$.B3C21.E.E3CB$2.CD2E21.2ED2CBA$
4.E22.2E3CB$29.2DCB$29.E48$39.2A$38.5A$38.B2AB2A$37.3CA2B2A$36.C4D2CB
2A$35.CDE4D2CB2A$35.C3D2.D2C3A$36.C.D3.EBDB$38.E3.2ECD$42.3EC$43.2ED$
43.D.D$45.D!

[rowett]

Some glide reflective spaceships don't have mods identified anymore

Fixed, thanks.

Despite behaving identically, these two patterns return different values for Bounding Box, Heat and Temperature (the bottom has the expected values)

Fixed, thanks.

Using Identify on this causes the viewer to zoom out a lot for some reason

Looks like the pattern dies on the final generation.

Also, Identify used on this diagonal spaceship appears to cause the viewer to freeze once it goes to just under a thousand or so generations

Fixed, thanks.

[muzik]

Active Cells, Temperature and Volatility are fundamentally flawed for oscillators in alternating rules, since all stator cells are considered period-2 and the volatility can therefore only be 1. Should Volatility be disabled for alternating rules, should period-2 cells be considered part of the stator, could LifeViewer be able to distinguish period-1 and "real" period-2 cells in Identify somehow, or something else entirely?

Code: Select all

x = 24, y = 24, rule = B2-ac3-i45678/S01234-a5-i678|B2-ac3-i45678/S012345-i678
4obo5bob3obo2bo2bo$7o3b13o$b6o3b14o$3b20o$3b20o$3b20o$3b20o$3b20o$3b20o
$3b20o$3b21o$3b20o$b22o$23o$b22o$23o$b22o$b22o$23o$b23o$23o$23o$23o$o
2b3obo2bob3o2bo2b4o!

Identify also seems to really struggle with this p19168. It plays out over four whole period cycles before detecting the pattern is periodic around 85k generations, and it then takes over two whole minutes (I didn't continue beyond that) to calculate data. The period can be verified with Go To Gen. I don't know if this oscillator is just one of the unlucky few that won't benefit from the Identify rewrite, or if this is due to some new issue that has cropped up.

Code: Select all

x = 10, y = 7, rule = B2in3-ck4eyz5ny678/S3-jk4aikqrtz5ceky678
bo$6bo$2b6o$ob7o$2b8o$4b5o$7bo!

[rowett]

Identify also seems to really struggle with this p19168. It plays out over four whole period cycles before detecting the pattern is periodic around 85k generations, and it then takes over two whole minutes (I didn't continue beyond that) to calculate data. The period can be verified with Go To Gen. I don't know if this oscillator is just one of the unlucky few that won't benefit from the Identify rewrite, or if this is due to some new issue that has cropped up.

Identify will certainly struggle with patterns this big. The bounding box is 3278x3278 which is 10,745,284 (10 million) cells. The period is 19168 so Identify has to check 10 million cells that many times. It's not going to be quick.

It was also causing an out of memory issue (which I've fixed and will release soon). So now Strict Volatility will only be computed if the period is less than 65535 and the expected memory usage is below a reasonable threshold. I may change this so that the 65535 period is no longer a limit and the limit is purely on memory. This will allow Strict Volatility of smaller patterns at higher periods.

With the memory fix Identify did complete analysing this pattern. On my machine it took 11.4 seconds to find the period and then 4 minutes 30 seconds for the rest of the statistics (excluding Strict Volatility).

[muzik]

I believe just about all of the issues I've had with Identify (from both before and after the refactoring) are now resolved. Thank you a lot!

Here's some other stuff:

It doesn't seem possible to customize the color of state 1 in the none rule anymore. Higher states work fine.

Code: Select all

x = 5, y = 2, rule = none
ABCDE$ABCDE!
[[ COLOR 1 White COLOR 3 White ]]

The same appears to be true of state 0 when using numbers to specify the state.

Code: Select all

x = 5, y = 2, rule = none
ABCDE$ABCDE!
[[ COLOR 0 White ]]

On the topic of state 0, would it be possible for the none rule's name for state 0 to be changed to "background", or even just "state 0"? By definition, patterns in the none rule do not evolve, so the term "dead" for this state seems out of place if dying doesn't exist. I should also point out that BACKGROUND is what the rule responds to when trying to customize state 0's color, whereas trying to change DEAD does nothing (it doesn't give an illegal element script error though, which it probably should).

Code: Select all

x = 5, y = 2, rule = none
ABCDE$ABCDE!
[[ COLOR BACKGROUND White ]]

Code: Select all

x = 5, y = 2, rule = none
ABCDE$ABCDE!
[[ COLOR DEAD White ]]

[muzik]

This is a hilariously minor thing, but the following oscillator has a period of 1048575, which can be easily checked via Go To Gen. Identify's current period limit is 1048576, just above this period, but it doesn't detect that this is an oscillator despite it technically having a low enough period. This definitely isn't worth the time or compromises to fix, but I felt like pointing it out anyway.

Code: Select all

x = 54, y = 1, rule = B3i4int5ey6k7e/S1e2k3ey4irt5i
54o!

While I have considered suggesting raising the Identify limit to 4194304 to be on par with Go To Gen, or potentially to make it variable depending on memory like the above proposal for strict volatility limit changes, neither is a high priority at all.