Pattern viewer for forum threads

[muzik]

I've checked the Mod transformations against the list of potential kinetic symmetries, and there appear to be no more ambiguous cases. Thank you!

----

It appears the HISTORYSTATES initial population bug for higher-range rules is back:

Code: Select all

x = 5, y = 4, rule = B3/S23
2b2o$2ob2o$4o$b2o!
[[ HISTORYSTATES 62 SHOWGENSTATS ]]

Code: Select all

x = 5, y = 4, rule = R1,C2,S2-3,B3
2b2o$2ob2o$4o$b2o!
[[ HISTORYSTATES 62 SHOWGENSTATS ]]

I've also been wondering: for code boxes containing rule tables and nothing else, would it be possible for LifeViewer to display a "SHOW IN VIEWER" link, which would open an empty pattern with that rule active? This behaviour would be consistent with having the rule table defined inline after a given pattern.

Code: Select all

@RULE coverleafsim
@TABLE
n_states:2
neighborhood:moore
symmetries:none
var a={0,1}
var b=a
var c=a
0,0,a,b,c,1,0,1,0,1
1,0,a,b,c,0,0,0,1,0
0,1,a,b,c,0,0,0,1,1
1,0,a,b,c,0,0,1,0,0

Code: Select all

x = 5, y = 1, rule = coverleafsim
5o!
@RULE coverleafsim
@TABLE
n_states:2
neighborhood:moore
symmetries:none
var a={0,1}
var b=a
var c=a
0,0,a,b,c,1,0,1,0,1
1,0,a,b,c,0,0,0,1,0
0,1,a,b,c,0,0,0,1,1
1,0,a,b,c,0,0,1,0,0

[rowett]

It appears the HISTORYSTATES initial population bug for higher-range rules is back

Fixed, thanks.

[muzik]

If we select and clear some of the state-6 cells from this pattern in [R]History ([R]Super is unaffected), they will be visually gone, but their effects remain:

Code: Select all

x = 33, y = 4, rule = B2/SHistory
11.F4.A.F$10.F3.A4.F$14.A$11.F4.A.F!

Code: Select all

x = 33, y = 4, rule = B2/SSuper
11.F4.A.F$10.F3.A4.F$14.A$11.F4.A.F!

Also, for either of the above cases, using Identify from T=0 will report a different result from using Identify a second time from the generation the first Identify sets it to.

Cases like this are one of the main reasons why I proposed that state-6 cells be included within period maps, as the pattern would be a completely different class of pattern were they not present.

[rowett]

If we select and clear some of the state-6 cells from this pattern in [R]History ([R]Super is unaffected), they will be visually gone, but their effects remain

Fixed, thanks.

Also, for either of the above cases, using Identify from T=0 will report a different result from using Identify a second time from the generation the first Identify sets it to.

This is known. Identify only checks one additional period once it thinks it's detected a spaceship. In this case that detection happens before the pattern reflects.

[muzik]

Also, for either of the above cases, using Identify from T=0 will report a different result from using Identify a second time from the generation the first Identify sets it to.

This is known. Identify only checks one additional period once it thinks it's detected a spaceship. In this case that detection happens before the pattern reflects.

It might be worth pointing out in that case that the results for that spaceship are actually incorrect - the spaceship should have four cells at all times, but since state 6 blocks birth into its own space, one of those cells ends up being not born, meaning that at one point there are only 3 alive cells present, and the spaceship is incorrectly reporting as having a minimum population of 3.

Here's a pattern that, when identified, reports back with the spaceship apparently having a minimum population of 1:

Code: Select all

x = 7, y = 4, rule = B2ak/SHistory
A$2.A3.F$2.A3.F$A3.F!

We can get minimum population 0 spaceships using this method as well.

Code: Select all

x = 7, y = 5, rule = B2ak/SHistory
A3.F$2.A3.F$2.A3.F$A3.F!

For some reason, LifeViewer zooms out a lot when all cells die when using Identify on this, which is rather unhelpful. Also in both examples, all cells die out by the time the results are displayed. Shouldn't we have a "Life ended at" message instead?

----

Identify classifies this as FlipDiagorRot90, which doesn't seem right, since the Z-shaped phase doesn't become the other Z-shaped phase through diagonal reflection of either kind. I'd expect just Rot90 for this.

Code: Select all

x = 3, y = 3, rule = MAPAkUggAEAgIAAEAAAAAAACAAAoAAAAAAA4EACAAAAAAACAAAAggAAQAAAAACAAAAAAAAQAAgAAAAAgAAAgAAAAA
2o$bo$b2o!

This one is correctly assigned Rot90:

Code: Select all

x = 1, y = 3, rule = MAPAkEggAEAgIAAEAAAAAAACAAAoAAAAAAAgEACAAAAAAAAAAAAggAAQAAAAAAAAAAAAAAQAAgAAAAAgAAAgAAAAA
o$o$o!

Also, the L-ships from earlier are now classed as "Flip⟍orRot180" in two-state rules rather than just "Flip⟍". 180-degree rotation isn't valid for two-dimensional spaceships.

Code: Select all

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

Code: Select all

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

Code: Select all

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

Code: Select all

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

----

Are the Randomize buttons meant to produce outer-totalistic rules when used on isotropic non-totalistic patterns or non-isotropic patterns?

[PHPBB12345]

The website lazyslug.com is down

[rowett]

The website lazyslug.com is down

Should be back now.

[rowett]

It might be worth pointing out in that case that the results for that spaceship are actually incorrect

The results will always be incorrect if spaceships are identified before being destroyed by state 6 cells.

the L-ships from earlier are now classed as "Flip⟍orRot180" in two-state rules rather than just "Flip⟍".

Fixed, thanks.

[muzik]

Alongside the "FlipDiagorRot90" oscillator that should be just "Rot90" which I mentioned above, I've found one more probably incorrect object mod: this spaceship is called Flip⟋ by Identify, but ⟋ is perpendicular to the direction of travel, which is normally impossible, so I don't think this classification is valid either.

Code: Select all

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

This equivalent orthogonal spaceship is not given a Flip transform, which is the likely correct behaviour.

Code: Select all

x = 3, y = 2, rule = MAPAAAAAAAgAAAAAIAAAAAAAACAAACAAAAAAAAAAAAAAAAAAIAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
bo$obo!

Generations once more lets the truth slip out:

Code: Select all

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

Code: Select all

x = 3, y = 2, rule = MAPAAAAAAAgAAAAAIAAAAAAAACAAACAAAAAAAAAAAAAAAAAAIAAAAAAAIAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA/3
bo$obo!

----

Would it be possible for Identify to detect and output whether a Rot90 oscillator rotates around a vertex of the grid or around the middle of a cell, or would this be out of scope?

Code: Select all

#C Rot90CW, goes around a cell
x = 3, y = 4, rule = B2n3aeijr4ejkz5cek6cin7e8/S23-acky4einrtyz5ekn6-ak78
3o$2bo$2bo$bo!

Code: Select all

#C Rot90CCW goes around a vertex
x = 2, y = 3, rule = B2-a3ejq4nrt5aeq6ei7/S01e2ikn3jkn4ijt5ajnr6cek7c8
2o2$bo!

[rowett]

Alongside the "FlipDiagorRot90" oscillator that should be just "Rot90" which I mentioned above, I've found one more probably incorrect object mod: this spaceship is called Flip⟋ by Identify, but ⟋ is perpendicular to the direction of travel, which is normally impossible, so I don't think this classification is valid either.

Fixed, thanks.

Would it be possible for Identify to detect and output whether a Rot90 oscillator rotates around a vertex of the grid or around the middle of a cell, or would this be out of scope?

You can tell from whether the bounding box size is odd or even.

[muzik]

Would it be possible for Identify to detect and output whether a Rot90 oscillator rotates around a vertex of the grid or around the middle of a cell, or would this be out of scope?

You can tell from whether the bounding box size is odd or even.

I'm surprised I never noticed that given how many rotating oscillators I've had to analyse.

The only case I can think of where going off of bounding boxes wouldn't work well is for time symmetric oscillators that are D2_+1-symmetric and reflect along a line that sits on grid edges versus a D2_+2 symmetric oscillator that reflects across a line going through the middle of cells:

Code: Select all

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

Code: Select all

x = 2, y = 4, rule = B3aij/S1c2ak
o2bo$b2o!

[muzik]

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.

To what extent should this affect mod detection? I have two patterns here: one 2-state oscillator and a blinker in [R]History surrounded by four state 6 cells. The first is identified as pure Rot90, but the second is identified as FlipDiagOrRot90, which is valid for normal blinkers in 2-state rules but FlipDiag wouldn't preserve the positions of the state-6 cells.

Code: Select all

x = 5, y = 5, rule = B4n/S01c2i
3bo$o$b3o$4bo$bo!

Code: Select all

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

They definitely appear to still have some effect, since this ends up being classified as FlipDiag instead of FlipDiagOrRot90 (if we count all cell states, the overall configuration is wholly asymmetric):

Code: Select all

x = 9, y = 5, rule = LifeHistory
7.2F$6.3F$.3A2.2F!

[Sokwe]

When viewer tags are used starting with a new line like so

Code: Select all

[viewer]
x = 3, y = 3, rule = B3/S23
3o$obo$obo!
[/viewer]

then using "select all" on the code box and copying the pattern adds a superfluous space at the beginning of the RLE, which prevents Golly from reading it properly. This doesn't happen with ordinary code boxes. Rendered example:

Code: Select all

x = 3, y = 3, rule = B3/S23
3o$obo$obo!
[[ HEIGHT 240 ]]

The final newline is also replaced with a space, but that doesn't cause any issues as far as I'm aware.

[muzik]

Diagonal spaceship mods once again aren't being calculated as expected when the spaceship is going in certain directions:

Code: Select all

x = 3, y = 4, rule = R2,C3,M0,S4..4,B4..4,NM
2B$3A$B2A$B!

Code: Select all

x = 3, y = 4, rule = R2,C3,M0,S4..4,B4..4,NM
.2B$3A$2AB$2.B!

[rowett]

Diagonal spaceship mods once again aren't being calculated as expected when the spaceship is going in certain directions

Fixed, thanks.

[rowett]

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.

To what extent should this affect mod detection?

Identify now considers state 6 cells (from [R]History and [R]Super) as an integral part of the pattern. This means for Oscillators symmetry also depends on the state 6 cell placement. It also means that patterns with state 6 cells will not be recognized as Spaceships (since the state6 cells do not move).

[rowett]

When viewer tags are used starting with a new line like so

Code: Select all

[viewer]
x = 3, y = 3, rule = B3/S23
3o$obo$obo!
[/viewer]

then using "select all" on the code box and copying the pattern adds a superfluous space at the beginning of the RLE, which prevents Golly from reading it properly. This doesn't happen with ordinary code boxes.

It looks similar to this issue reported 12 years ago. Are you using FireFox?

[Sokwe]

It looks similar to this issue reported 12 years ago. Are you using FireFox?

Yes, I am using Firefox. I don't have any other browsers to test with, and my hard drive is essentially full right now so I'm not sure I can install any others without shuffling around files on thumb drives.

[rowett]

It looks similar to this issue reported 12 years ago. Are you using FireFox?

Yes, I am using Firefox. I don't have any other browsers to test with, and my hard drive is essentially full right now so I'm not sure I can install any others without shuffling around files on thumb drives.

I tested this on Windows. When copying after Select All from the code box Firefox has an extra space at the beginning and end of the copied text which causes Golly to reject the pattern. Chrome and Edge do not have an extra space.

LifeViewer doens't care about the extra space because it strips them while parsing the RLE.

So I guess the options are:

• Have LifeViewer remove the leading space while it processes the code block generated by the viewer tag
• Adjust Golly's parser so it ignores leading whitespace for a recognized header line in an RLE

There was another question recently about Golly and leading spaces but I can't find the reference at the moment.

Thoughts?

[Sokwe]

So I guess the options are:

• Have LifeViewer remove the leading space while it processes the code block generated by the viewer tag
• Adjust Golly's parser so it ignores leading whitespace for a recognized header line in an RLE

There was another question recently about Golly and leading spaces but I can't find the reference at the moment.

Thoughts?

I think it's a low priority since viewer tags are rarely used, and it can be solved by the user by not starting the viewer block with a new line. I certainly have no idea what the server-side fix to this might be. Looking at the page source, the contents of pure code boxes (which don't have this problem) are enclosed by <pre> tags and do not contain <br> tags, while the code attached to the viewer is surrounded by <div> tags and uses <br> tags (although there is no <br> tag for the leading new line). I don't know if this has anything to do with the problem or whether it's easy to change.

It would probably be good in general if Golly stripped leading white space when parsing a pattern.

[muzik]

Identify now considers state 6 cells (from [R]History and [R]Super) as an integral part of the pattern. This means for Oscillators symmetry also depends on the state 6 cell placement. It also means that patterns with state 6 cells will not be recognized as Spaceships (since the state6 cells do not move).

Great! This is actually the behaviour I've wanted for a while now.

Since they're now counted as part of the bounding box, it means that gaps can now appear around cells in period maps if state-6 cells exist at the very edges of the pattern where living cells never appear:

Code: Select all

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

I know I've already suggested this basically twice over the past two days, but since state-6 cells are now officially considered fundamental constituent cells of the pattern, this is probably the best possible time to ask for it: could they be displayed visually in the period map instead of being given the same color as the background? This would solve the above "gap" issue, and even for patterns like the following where all such cells are inside of the oscillator's bounding box they're still important enough to be displayed.

Code: Select all

x = 7, y = 7, rule = LifeHistory
$2.2A$.3A3$F2.A2.F$2.2A!

[muzik]

Since error messages can tell us the maximum allowable size of a pattern if the RLE provides a pattern which is too large, can the same be done for bounded grids?

Code: Select all

x = 101, y = 1, rule = R125,C2,S0-250,B
273o!
[[ MAXGRIDSIZE 10 ]]

Code: Select all

x = 101, y = 1, rule = R125,C2,S0-250,B
274o!
[[ MAXGRIDSIZE 10 ]]

Code: Select all

x = 101, y = 1, rule = R50,C2,S100,B101:T211
101o!
[[ MAXGRIDSIZE 9 ]]

Code: Select all

x = 101, y = 1, rule = R50,C2,S100,B101:T212
101o!
[[ MAXGRIDSIZE 9 ]]

According to the top two patterns, the reported maximum pattern size might be off by one, since the maximum is apparently 274x274 despite it rejecting a pattern exactly 274 cells wide.

It's also possible for the error to report a maximum allowable pattern size with negative bounding box dimensions. An error message saying to either decrease the neighbourhood range or increase MAXGRIDSIZE would make more sense here.

Code: Select all

x = 101, y = 1, rule = R500,C2,S1000,B1001
101o!
[[ MAXGRIDSIZE 11 ]]

The boundary seems to be overly eager to kill this oscillator, but defining a bounded grid around it while keeping MAXGRIDSIZE the same (which ultimately wouldn't impact its evolution at all) prevents this.

Code: Select all

x = 101, y = 1, rule = R50,C2,S100,B101
101o!
[[ MAXGRIDSIZE 9 ]]

Code: Select all

x = 101, y = 1, rule = R50,C2,S100,B101:P103
101o!
[[ MAXGRIDSIZE 9 ]]

Also, odd shifts probably aren't a good idea for Margolus rules and should probably be disabled for the same reason odd grid boundary sizes are (either that, or odd sizes should be permitted but an odd shift of some kind would be mandatory). The spaceship can cross the edge just fine when even shifts are used, but explodes when an odd shift is used:

Code: Select all

x = 4, y = 5, rule = M0,3,10,2,5,1,6,7,12,9,8,11,4,13,14,15:T40+0,20
$2bo$2bo$3o$3bo!

Code: Select all

x = 4, y = 5, rule = M0,3,10,2,5,1,6,7,12,9,8,11,4,13,14,15:T40+1,20
$2bo$2bo$3o$3bo!

Code: Select all

x = 4, y = 5, rule = M0,3,10,2,5,1,6,7,12,9,8,11,4,13,14,15:T40+2,20
$2bo$2bo$3o$3bo!

----

Under the Active Cells row, could Identify also include a row for the number of state-6 cells present in a still life or oscillator?

Code: Select all

x = 33, y = 4, rule = B2/SHistory
.F14.A14.F$F13.A17.F$14.A$.F14.A14.F!

[rowett]

since state-6 cells are now officially considered fundamental constituent cells of the pattern, this is probably the best possible time to ask for it: could they be displayed visually in the period map instead of being given the same color as the background?

Yes, done.

[rowett]

Since error messages can tell us the maximum allowable size of a pattern if the RLE provides a pattern which is too large, can the same be done for bounded grids?

I removed the size from the "Pattern too big" message.

The boundary seems to be overly eager to kill this oscillator, but defining a bounded grid around it while keeping MAXGRIDSIZE the same (which ultimately wouldn't impact its evolution at all) prevents this.

The algo needs different sizes depending on whether there is a bounded grid or not.

Also, odd shifts probably aren't a good idea for Margolus rules and should probably be disabled for the same reason odd grid boundary sizes are

Fixed, thanks.

Under the Active Cells row, could Identify also include a row for the number of state-6 cells present in a still life or oscillator?

No, it can be seen in Help->Info->Pattern.

[muzik]

since state-6 cells are now officially considered fundamental constituent cells of the pattern, this is probably the best possible time to ask for it: could they be displayed visually in the period map instead of being given the same color as the background?

Yes, done.

Brilliant!

Could bounded grid edges also be displayed on period maps somehow? I was planning on saving this suggestion for when/if the "bounded grid is an object in itself according to Identify" change gets implemented, but it could probably be added now just as easily. Having visually defined boundary cells would help to make it comparatively clearer where disconnected-looking cells like in the following example come from.

Code: Select all

x = 10, y = 10, rule = LifeHistory:T10+6
8.B3$A$AB7.B$A3$2.B$.3A!

Also, this appears to be classed as FlipXorRot180 now, which isn't desirable, as the L-shape doesn't rotate 180 degrees, only 90 degrees (not that this would be particularly valid either in this specific case), and if the configuration did rotate, the positions of the state-6 cells and stator cells wouldn't be preserved.

Code: Select all

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

State 6's color doesn't appear to be shown in Help > Info > Identify either.

----

Under the Active Cells row, could Identify also include a row for the number of state-6 cells present in a still life or oscillator?

No, it can be seen in Help->Info->Pattern.

Doesn't this only record info for the cells present in the input RLE, and therefore wouldn't count anything drawn in after the fact?

It might be possible to fit in a State 6 cell counter at the bottom of the periods count table instead, after where the stator cells would be.