Pattern viewer for forum threads

[rowett]

There is just a lot of computation required for this pattern: the evolution of 34040 active cells across 29400 generations for 71 different sub-periods, none of which have a match.

Having said this I realised that for an oscillator of period p, in order for a specific cell to be oscillating at sub-period n, it must be alive for at least p / n generations. By computing the alive count per cell over period p (which is fairly inexpensive), I could use this information to quickly discard a sub-period n search for a specific cell if its alive count was less than this threshold.

In this extreme case the performance has doubled. On my machine build 1082 took 117 seconds to Identify the pattern vs 53 seconds on build 1083. For other patterns there will likely be a smaller improvement.

[rowett]

Having said this I realised that for an oscillator of period p, in order for a specific cell to be oscillating at sub-period n, it must be alive for at least p / n generations. By computing the alive count per cell over period p (which is fairly inexpensive), I could use this information to quickly discard a sub-period n search for a specific cell if its alive count was less than this threshold.

Actually each cell must be alive for some multiple of p / n generations. Build 1084 now identifies this pattern in 9.2 seconds on my machine.

Code: Select all

x = 40, y = 22, rule = B2n3aeijy4ci5cr6n/S2aek3-acek4eiknr5ir6eik7e
38bo$38b2o$39bo5$31b2o$31b2o5$31b3o$31b3o2$28b3o$2o2bo23bo2bo$o27b2o2b
2o$2obo26bo2bo$b3o26b3o$2bo!

[muzik]

As of build 1088 (tested on the other site since it isn't yet on the forums on my end) there's still lines of cells at the very top and very left of the grid which remain freshly dead after contact, rather than fading like the rest. The pattern itself doesn't degrade into chaos though, which is good and should preferably stay that way.

Code: Select all

x = 2, y = 2, rule = R1,C2,S0,2,4,6,8,B1,3,5,7,NM
2o$2o!
[[ AUTOSTART MAXGRIDSIZE 9 DELETERANGE 1 ZOOM -1 ]]

Issue is not present in the range 1 algorithm:

Code: Select all

x = 2, y = 2, rule = B1357/S02468
2o$2o!
[[ AUTOSTART MAXGRIDSIZE 9 DELETERANGE 1 ZOOM -1 ]]

This old example still turns chaotic for the general-range algorithm in build 1088 but doesn't in the range-1 algorithm, although the chaos does appear to remain symmetric throughout:

Code: Select all

x = 4, y = 4, rule = R1,C2,S0,2,4,6,8,B1,3,5,7,NM
4o$4o$4o$4o!
[[ AUTOSTART MAXGRIDSIZE 9 DELETERANGE 1 ZOOM -1 ]]

Code: Select all

x = 4, y = 4, rule = B1357/S02468
4o$4o$4o$4o!
[[ AUTOSTART MAXGRIDSIZE 9 DELETERANGE 1 ZOOM -1 ]]

[muzik]

A selection offset bug still appears to exist when using Select All:

Code: Select all

x = 10, y = 10, rule = M0,4,8,12,4,12,12,13,8,12,12,14,12,13,14,15:T10,10
9o$9o$9o$9o$9o$9o$9o$9o$9o!

[muzik]

This pattern no longer works how it used to - it appears to explode instead of travelling down and to the left.

Code: Select all

x = 3, y = 3, rule = B03-ck4y6a/S2-n35r
o$obo$2o!
[[ PASTEMODE AND PASTEDELTA -1 1 PASTET EVERY 4 1 PASTE b! 3 0 PASTET EVERY 4 3 PASTE b! 1 -1 ]]

[haaaaaands]

This pattern no longer works how it used to - it appears to explode instead of travelling down and to the left.

Code: Select all

x = 3, y = 3, rule = B03-ck4y6a/S2-n35r
o$obo$2o!
[[ PASTEMODE AND PASTEDELTA -1 1 PASTET EVERY 4 1 PASTE b! 3 0 PASTET EVERY 4 3 PASTE b! 1 -1 ]]

because you used [[ PASTET ]]?

[rowett]

This pattern no longer works how it used to - it appears to explode instead of travelling down and to the left.

Fixed, thanks!

[muzik]

The calculated bounding box and the period map size for this pattern is larger in the general range algorithm than in the range-1 algorithm despite the pattern functioning identically.

Code: Select all

x = 36, y = 9, rule = B3/S23
27bo$26b4o$9b2o14b2obobo$bo7bo2bo11b3obo2bo2b2o$o3b2o7bo11b2obobo3b2o
$o5bo6bo12b4o$b5o7bo7bo5bo$9bo2bo9bo$9b2o9b3o!
[[ KILLGLIDERS ]]

Code: Select all

x = 36, y = 9, rule = R1,C2,S2-3,B3
27bo$26b4o$9b2o14b2obobo$bo7bo2bo11b3obo2bo2b2o$o3b2o7bo11b2obobo3b2o
$o5bo6bo12b4o$b5o7bo7bo5bo$9bo2bo9bo$9b2o9b3o!
[[ KILLGLIDERS ]]

On my end, using the autofit button versus using the fit pattern button will put this at two slightly different zoom levels, although the exact zoom levels and the difference between them varies a lot depending on window size and such:

Code: Select all

x = 1, y = 1, rule = B3/S23:T10
o!

[H. H. P. M. P. Cole]

I was experimenting with HROT weighted neighbourhoods and found this:

Code: Select all

x = 0, y = 0, rule = R2,C2,S8,B,NW0010000800180810080000100
!

Apparently LifeViewer does not seem to be parsing 8, 9, a, b, c, d, e, and f in the weighted neighbourhood properly.

May I know if this is because LifeViewer changed its weighted neighborhood system from hexadecimal to octal?

[confocaloid]

Apparently LifeViewer does not seem to be parsing 8, 9, a, b, c, d, e, and f in the weighted neighbourhood properly.

I think this is not specific to LifeViewer (Golly rejects that rulestring as well). The NW weights string has one digit per cell (length 25) with four '1' (represents weight 1) and three '8' (represents weight 0 according to Golly help). So the set of possible sums of weights is { 0, 1, 2, 3, 4 } depending on how many of cells with weight 1 are alive. S8 is not in this range; probably this is why the rulestring is rejected. It should work with S4 instead of S8:

Code: Select all

x = 1, y = 1, rule = R2,C0,S4,B,NW0010000800180810080000100
o!

Or if one of '8' is replaced with '7':

Code: Select all

x = 1, y = 1, rule = R2,C0,S8,B,NW0010000800170810080000100
o!

[muzik]

Not sure if this is a result of the new URL scripting functionality, but at least at viewer.html it doesn't appear to be possible to define a custom RLE by pasting it into the text box and clicking View.

[rowett]

Not sure if this is a result of the new URL scripting functionality, but at least at viewer.html it doesn't appear to be possible to define a custom URL by pasting it into the text box and clicking View.

Fixed, thanks!

It was related to a web server upgrade.

[HerscheltheHerschel]

I need support for Durnak-Cole notation (viewtopic.php?f=11&t=6189)

[Zodduniverse]

i think being able to add symbiosis to any rule like what you can do with life investigator would be cool

[muzik]

Is it at all possible to change the fonts used within LifeViewer? I've seen it vary across certain pages (but can't remember exactly where this was the case).

Also, on this page, each viewer thumbnail appears to be preceded by a thin text box, which I don't think was the case before: https://lazyslug.com/lifeview/plugin/bosco.html

Not sure if it'd make sense to update hotkey.png to clarify mac-specific keys given recent changes.

[rowett]

For anyone who uses or wishes to use LifeViewer as a plugin on their own webiste:

The latest build 1096 will work with a strict Content Security Policy.

[rowett]

Is it at all possible to change the fonts used within LifeViewer? I've seen it vary across certain pages (but can't remember exactly where this was the case).

No, the fonts are not configurable.

[confocaloid]

Names of themes are not case-sensitive, but script commands are case-sensitive. Is this by design?

Test cases:

Both the command "THEME" and the theme name "Book" are written "correctly" (that is, in the same way as they are in the internal help, Help/Scripts/Colours, Help/Themes):

Code: Select all

#C this works
x = 3, y = 3, rule = B3/S23
bo$2bo$3o!
#C [[ THEME Book ]]

The command is written correctly, but the theme name is not:

Code: Select all

#C this works
x = 3, y = 3, rule = B3/S23
bo$2bo$3o!
#C [[ THEME BOOK ]]

The theme name is written correctly, but the command is not:

Code: Select all

#C this does not work
x = 3, y = 3, rule = B3/S23
bo$2bo$3o!
#C [[ Theme Book ]]

Neither the command nor theme name is written correctly:

Code: Select all

#C this does not work
x = 3, y = 3, rule = B3/S23
bo$2bo$3o!
#C [[ theme book ]]

[rowett]

Names of themes are not case-sensitive, but script commands are case-sensitive. Is this by design?

Yes. Thank you for the detailed report.

[muzik]

When ALIVEFIT is implemented, will STATE1FIT be kept or will it be deprecated in favor of it?

[wirehead]

Not sure if this is a result of the new URL scripting functionality, but at least at viewer.html it doesn't appear to be possible to define a custom URL by pasting it into the text box and clicking View.

URL scripting, where is that documented? Couldn't find it in the lifewiki pages or the release notes.

[confocaloid]

Not sure if this is a result of the new URL scripting functionality, but at least at viewer.html it doesn't appear to be possible to define a custom URL by pasting it into the text box and clicking View.

URL scripting, where is that documented? Couldn't find it in the lifewiki pages or the release notes.

I think it was recently discussed in the Proposed home page refresh thread, and related to the clickable patterns in omniperiodicity paper (arXiv).

[rowett]

URL scripting, where is that documented? Couldn't find it in the lifewiki pages or the release notes.

The documentation is here. Note it's not a change to LifeViewer which is why is wasn't in the release notes. It's server side implementation on the web site.

[muzik]

Some further performance tests, this time using Identify on the following duelling donuts oscillator through viewer.html three times:

Code: Select all

x = 35, y = 35, rule = R10,C2,S24-29,B72-133,NB
9bobo$6bobobobo$5bobobobobobo$4bobobobobobobo$3bobobobobobobobo$2bobobobobobobobobo$bobobobobobobobobo$2bobobobobobobobobo$bobobobobobobo2b4o$obobobobo3bob3obobo$bobobobo5bobobobo$obobobobo3bobobobobo$bobobobobobobobobobo$2bobobobobobobobobo4bobo$3bobobobobobobobobo2bobobo$2bobobo2b2obobobob2obobob3o$3bobob3obobobob2obobobobobo$4bobobobobobob2obobobo3bobo$5bob3obobob2obobobobobobobo$8bobobob2obobobobo3bobobo$9bobo4bobobobo2b2obobobo$15bobobobo3bobobobobo$14bobobobo7bobobobo$13bobobobo7bobobobo$14bobobo9bobobobo$13bobo4b2o5bobobobo$14b3obobo5bobobobobo$15bobobobobobobobobobo$16bobobobobobobobobo$17bobobobobobobobo$18bobobobobobobo$19bobobobobobo$20bobobobobo$21bobobobo$22bobobo!

2013 desktop PC running Windows 10 Home 19045.3803:
Brave: 16.8s/22.9s, 16.8s/23.0s, 22.4s/28.2s
Chrome: 18.1s/24.4s, 24.1s/29.9s, 15.2s/21.0s
Edge: 15.8s/21.6s, 15.0s/20.7s, 14.7s/20.5s
Internet Explorer: not sure how to open this without Edge taking over

Same PC running Ubuntu 23.10 via a flash drive:
Firefox: 15.5s/21.4s, 15.6s/21.6s, 15.7s/21.6s

HP 250 G7 Notebook PC running Windows 10 Home 19045.3570:
Firefox: 44.4s/53.4s, 48.3s/59.1s, 63.7s/73.1s
Chrome: 39.9s/50.3s, 33.3s/40.2s, 34.5s/42.3s
Edge: 33.6s/39.6s, 32.3s/39.6s, 30.5s/35.9s
Internet Explorer: again, can't seem to open this anymore

HP 250 G7 Notebook PC running Ubuntu 23.10 from the same flash drive as earlier:
Firefox: 15.4s/21.0s, 14.2s/19.4s, 14.1s/19.3s

iPad:
Safari: 10.5s/14.1s, 10.5s/14.2s, 10.4s/14.0s

Samsung Galaxy A20e:
Samsung Internet: 64.7s/82.0s, 63.6s/80.7s, 64.1s/81.4s

Is there any way to do Identify in a way that doesn't update the renderer so we can more accurately isolate it for performance testing?


I've been thinking about potential optimizations for Identify, but can't be sure how many of the ones I've come up with are already implemented, or are feasible to implement. For example, does the period mapping interact with mod calculations at all? If we know that an oscillator flips or rotates at halfway through or a quarter of the way through its evolution, we may be able to conclude several useful details which could be used to speed up calculation of the period map. For example, an oscillator that flips halfway through its evolution diagonally will always have a gutter of cells which are at most period p/2 for a period-p oscillator. The same is true for oscillators that flip orthogonally across a line that passes through the centers of cells (i.el it has an odd bounding box width on that axis). For stuff that rotates 180 degrees around the center of a cell, said cell can be at most period-(p/2), and for stuff that rotates 90 degrees around the center of a cell, it can be at most period-(p/4). Examples can be provided for clarification's sake.

[rowett]

Is there any way to do Identify in a way that doesn't update the renderer so we can more accurately isolate it for performance testing?

No. However the impact is minimal. Rendering is only done during the period detection phase. Using the provided pattern on my desktop machine the period detection phase took 7.6 seconds and evaluated about 21000 generations. LifeViewer renders every 1/60th of a second (if it can) and so it in this case it rendered every 46 generations.