Pattern viewer for forum threads

[muzik]

I've put in one more pull request to add an alias for the 2-state rule "HybridViewW110", meaning that after this is accepted in, we can delete said ruletable from the wiki as well. Once this is done, only seven [EDIT: using other search engines has found some new ones, actually, so further changes might end up being made] 2-state ruletables will remain on the wiki, which can be separated into three categories:

----

These two are copies of B3/S23 but as ruletables, which I only use for debugging and benchmarking purposes as to compare the performance of the custom rule algorithm to the native algorithm.

Code: Select all

Rule:Life-RuleLoader
Rule:Life-RuleTree

These both specify "neighbourhood:Margolus", which LifeViewer does not appear to support. However, this is listed in Golly's rule table repository roadmap page. Are there any plans to implement support for custom Margolus ruletables? I know 3-state Margolus rule support was discussed a few years ago but don't think it got particularly far.

Code: Select all

Rule:BBM-Margolus
Rule:SingleRotation

These three tables specify a custom neighbourhood via a coordinate system for use with CAViewer. LifeViewer does not support this format at all to my knowledge.

Code: Select all

Rule:Hash1
Rule:Hash2
Rule:Nightingale

[rowett]

For thumbnail viewers that expand to a ratio that forbids use of the settings menu, there's no way to shrink it back down to a thumbnail size again. In the specific cases where settings would be disabled, can the button be replaced with the shrink button instead of grayed out?

Done, thanks.

[muzik]

Rule tables with titles ending in l are initially assumed to be triangular, forbidding bounded grids with odd dimensions:

Code: Select all

x = 1, y = 1, rule = bornonzero:T99
o!
@RULE bornonzero
@TABLE
n_states:2
neighborhood:hexagonal
symmetries:permute
0,0,0,0,0,0,0,1

Code: Select all

x = 1, y = 1, rule = bornonzerol:T99
o!
@RULE bornonzerol
@TABLE
n_states:2
neighborhood:hexagonal
symmetries:permute
0,0,0,0,0,0,0,1

[rowett]

Rule tables with titles ending in l are initially assumed to be triangular, forbidding bounded grids with odd dimensions:

Fixed, thanks!

[muzik]

There may be further issues with Copy As MAP. Using it on this:

Code: Select all

x = 2, y = 2, rule = pentagonhood
bo$o!
@RULE pentagonhood
Uploaded by 83bismuth#8499 on Discord
> B2/S2 in a pentagonal neighborhood

@ICONS

XPM
/* width height num_colors chars_per_pixel */
"31 31 2 1"
/* colors */
". c #000000"
"B c #FFFFFF"
/* icon for state 1 */
".....BB........................"
"....BBBBB......................"
"...BBBBBBBB...................."
"..BBBBBBBBBBB.................."
".BBBBBBBBBBBBBB................"
"BBBBBBBBBBBBBBBBB.............."
"BBBBBBBBBBBBBBBBBBB............"
".BBBBBBBBBBBBBBBBBBBB.........."
".BBBBBBBBBBBBBBBBBBBBBB........"
"..BBBBBBBBBBBBBBBBBBBBB........"
"..BBBBBBBBBBBBBBBBBBBBBB......."
"...BBBBBBBBBBBBBBBBBBBBB......."
"...BBBBBBBBBBBBBBBBBBBBBB......"
"....BBBBBBBBBBBBBBBBBBBBB......"
"....BBBBBBBBBBBBBBBBBBBBBB....."
".....BBBBBBBBBBBBBBBBBBBBB....."
".....BBBBBBBBBBBBBBBBBBBBBB...."
"......BBBBBBBBBBBBBBBBBBBBB...."
"......BBBBBBBBBBBBBBBBBBBBBB..."
".......BBBBBBBBBBBBBBBBBBBBB..."
".......BBBBBBBBBBBBBBBBBBBBBB.."
"........BBBBBBBBBBBBBBBBBBBBB.."
"........BBBBBBBBBBBBBBBBBBBBBB."
"..........BBBBBBBBBBBBBBBBBBBB."
"............BBBBBBBBBBBBBBBBBBB"
"..............BBBBBBBBBBBBBBBBB"
"................BBBBBBBBBBBBBB."
"..................BBBBBBBBBBB.."
"....................BBBBBBBB..."
"......................BBBBB...."
"........................BB....."

XPM
/* width height num_colors chars_per_pixel */
"15 15 2 1"
/* colors */
". c #000000"
"B c #FFFFFF"
/* icon for state 1 */
"...BB.........."
"..BBBBB........"
".BBBBBBBB......"
"BBBBBBBBBBB...."
"BBBBBBBBBBBB..."
".BBBBBBBBBBB..."
".BBBBBBBBBBBB.."
"..BBBBBBBBBBB.."
"..BBBBBBBBBBBB."
"...BBBBBBBBBBB."
"...BBBBBBBBBBBB"
"....BBBBBBBBBBB"
"......BBBBBBBB."
"........BBBBB.."
"..........BB..."

XPM
/* width height num_colors chars_per_pixel */
"7 7 2 1"
/* colors */
". c #000000"
"B c #FFFFFF"
/* icon for state 1 */
".BB...."
"BBBBB.."
"BBBBBB."
".BBBBB."
".BBBBBB"
"..BBBBB"
"....BB."

@TABLE
n_states:2
neighborhood:hexagonal
symmetries:none
var a={0,1}
var b=a
var c=a
var d=a
var e=a
var f=a
var g=a
var h=a
0,1,1,0,0,0,0,1
0,1,0,1,0,0,0,1
0,1,0,0,1,0,0,1
0,1,0,0,0,1,0,1
0,0,1,1,0,0,0,1
0,0,1,0,1,0,0,1
0,0,1,0,0,1,0,1
0,0,0,1,1,0,0,1
0,0,0,1,0,1,0,1
0,0,0,0,1,1,0,1
1,1,1,0,0,0,0,1
1,1,0,1,0,0,0,1
1,1,0,0,1,0,0,1
1,1,0,0,0,1,0,1
1,0,1,1,0,0,0,1
1,0,1,0,1,0,0,1
1,0,1,0,0,1,0,1
1,0,0,1,1,0,0,1
1,0,0,1,0,1,0,1
1,0,0,0,1,1,0,1
1,a,b,c,d,e,f,0

gets us this, which clearly does not act the same:

Code: Select all

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

Observing the dynamics, things in the ruletable appear to travel up and to the left, and in the generated rule string things travel down and to the left, so this could be a simple rotation issue.

[muzik]

LifeViewer does not appear to accept this as a valid rule table, even though Golly does:

Code: Select all

x = 3, y = 3, rule = iwanttoconvertthis
2o$obo$b2o!
@RULE iwanttoconvertthis
@TABLE

n_states:2
neighborhood:Moore
symmetries:none

0100111101
0001100001
1100111000
1100001100
1100011100
1001010000
0100101011
1001000110
1101111000
1101010110
1000100000
0100111011
1110111100
0001000111
0011111101
1111110100
0111111001
0101010001
1001000100
1000001100
0100001101
1110001100
0101010001
0011110001
1011010000
0010100001
1101111100
0000011001
1011101000
0110011001
0110010001
1111010000
0111110101
0000001001
1111011000
0011110101
1100011010
1010110000
1010010000
00000000001
0011111101
0100000001
1000000000
0001001101
0011100001
0010011001
1100000000
1101010000
0000001001

Is Golly ignoring the 00000000001 line, which is one character too long, whereas LifeViewer notices this and complains?

[rowett]

There may be further issues with Copy As MAP.

Fixed, thanks!

[rowett]

LifeViewer does not appear to accept this as a valid rule table, even though Golly does

Is Golly ignoring the 00000000001 line, which is one character too long, whereas LifeViewer notices this and complains?

The rule table is invalid due to the 00000000001 line which contains 11 entries when there should be 10.

LifeViewer correctly complains because it expects exactly 10 entries on that line.
Golly's code looks for >= 10 entries on the line and then reads the first 10.

I prefer LifeViewer's approach since extra entries are likely an error.

[confocaloid]

I see; I assume there's also no way to uniquely describe the bounding shape as an intersection of two equilateral triangles? [...]

I'm unsure whether intersecting triangles or other shapes is going to simplify things in practice. It may be easier to write down the bounding hexagon including its location on the tiling. That would take 6 integer numbers (x_min, x_max, y_min, y_max, xmy_min, xmy_max).
To determine whether two such hexagons are translations of each other, one can translate each of them individually so that both x_min and y_min become 0, and then check for equality.

[muzik]

I've put in one more pull request to add an alias for the 2-state rule "HybridViewW110", meaning that after this is accepted in, we can delete said ruletable from the wiki as well.

I did some further searching which uncovered several others I had somehow missed. Most of these are duplicates of stuff already present as aliases. I've expanded this pull request to add the following eight aliases, so that the corresponding ruletables can be removed:

Code: Select all

1d110
AllShips
Bigship
Dustclouds03
movingdiagonal
pentagonhood
rules0
rules6

This should be good enough to merge right now from what I see.

[confocaloid]

In [R]Super CA, period identification seems to ignore period multiplication that comes from using different "alive" cellstates for different parts of the pattern. For example, the oscillator on the right is identified as p80 (which is visible on the cell period map), despite using three different "alive" cellstates:

Code: Select all

x = 77, y = 34, rule = B3-jknr4ity5ijk6i8/S23-a4city6c7cSuper
12.B9.B$8.2B.3B.B5.3B$7.3B.6B3.5B.2B$5.7BD5B2.9B31.2S9.3O$4.7B3D4B2.
10B30.2S9.O2.O$3.7B3D6B2.10B40.O$2.7B2DB2D17B$2.8BDB2D18B27.S13.O.O$
3.9BD20B20.2S4.2S14.2O$2.25BD5B19.S2.S18.O$.25B3D2B24.S$28B2D3B21.S2.
S$.24B6D3B24.4S$2.3B.20B2DBD3B25.S2.S$6.26B26.3S11.3O$5.28B36.2O.O.O$
3.29B37.3O.2O$2.29B38.O.O.O$.28B41.O.2O$2.26B42.3O$.3BCB2C20B.3B22.M.
2M13.O$3B6C24B20.6M$.3B2C28B20.2M$3.2B3C25B22.3M$.5BC25B24.M$.20BD9B$
2.18B2DBD8B$3.17B2DB2D7B$3.10B2.6B3D7B$4.10B2.4B3D7B$5.9B2.5BD7B$6.2B
.5B3.6B.3B$10.3B5.B.3B.2B$11.B9.B!

Is this by design? Which cellstates are considered distinct and which aren't?

[rowett]

In [R]Super CA, period identification seems to ignore period multiplication that comes from using different "alive" cellstates for different parts of the pattern.

Is this by design? Which cellstates are considered distinct and which aren't?

Identify treats all alive states as the same. This is by design.

[confocaloid]

[...] A pull request has also been sent in to get rid of some internal clashes with aliases in LifeViewer (alongside some other related changes). [...]

The commit https://github.com/rowett/lifeviewer/co ... 4d9d44c09d removed several aliases.
I don't understand the reason for the removal.

To give a single example, the linked commit removed the following line:

Code: Select all

a.push(["Conway++", "R1,C2,S2-3,6-7,10-11,15,20,B3,7,11,15,NW515101515"]);

Now that that alias is removed, the first pattern below doesn't show the name of the CA when the user clicks on the "T button" in the lower-left corner, but second pattern below still shows the name of the CA when the user clicks on the "T button":

Code: Select all

x = 57, y = 44, rule = R1,C0,S2-3,6-7,10-11,15,20,B3,7,11,15,NW515101515
56bo3$40b2o6b2o$40b2obo2bob2o$33b2o4bo4b2o4bo4b2o$25bo7b2o5b4o2b4o5b2o
$23b3o15b2o4b2o$22bo$22b2o3$20bo$19b3o19b2o4b2o$18bo2b2o10b2o5b4o2b4o
5b2o$18b3o12b2o4bo4b2o4bo4b2o$2o38b2obo2bob2o$bo38b2o6b2o$bobo$2b2o4bo
9b2o$7b2o9b2o$6b2obo$7bobo3b2o25bo$8b2o3b2o26bo$21b2o3b2o11b3o$21b2o3b
obo$26bob2o$16b2o9b2o$2b2o12b2o9bo$bobo$bo$2o$15b3o$13b2o2bo$14b3o$15b
o3$56bo$54bobo$55b2o3$o!

Code: Select all

x = 57, y = 44, rule = B3/S234c
56bo3$40b2o6b2o$40b2obo2bob2o$33b2o4bo4b2o4bo4b2o$25bo7b2o5b4o2b4o5b2o
$23b3o15b2o4b2o$22bo$22b2o3$20bo$19b3o19b2o4b2o$18bo2b2o10b2o5b4o2b4o
5b2o$18b3o12b2o4bo4b2o4bo4b2o$2o38b2obo2bob2o$bo38b2o6b2o$bobo$2b2o4bo
9b2o$7b2o9b2o$6b2obo$7bobo3b2o25bo$8b2o3b2o26bo$21b2o3b2o11b3o$21b2o3b
obo$26bob2o$16b2o9b2o$2b2o12b2o9bo$bobo$bo$2o$15b3o$13b2o2bo$14b3o$15b
o3$56bo$54bobo$55b2o3$o!

Even though the same cellular automaton can be defined using several different rulestrings, it's still very helpful to detect alternative rulestrings and show the alias to the user in the LifeViewer user interface. I would prefer if all such "duplicate" aliases were readded back, to provide that kind of information to the user who might get a rulestring from another source without knowing much about the CA.

[muzik]

[...] A pull request has also been sent in to get rid of some internal clashes with aliases in LifeViewer (alongside some other related changes). [...]

The commit https://github.com/rowett/lifeviewer/co ... 4d9d44c09d removed several aliases.
I don't understand the reason for the removal.

The reason was clearly stated in the commit:

Removed some duplicate weighted aliases that had already been converted to equivalent rulestrings in other rulespaces: Ben's rule, Bricks, Conway--, Conway++, Conway+-1, Conway+-2 (all isotropic non-totalistic), HexParity (outer-totalistic hexagonal), Parity (outer-totalistic von Neumann). Using the range-1 algorithm is preferable for range-1 rules.

For range-1 isotropic rules, using isotropic non-totalistic notation is preferred in 100% of known cases to using weighted notation. The isotropic aliases were added before the weighted aliases, resulting in conflicts that were resolved by removing these.

Even though the same cellular automaton can be defined using several different rulestrings, it's still very helpful to detect alternative rulestrings and show the alias to the user in the LifeViewer user interface. I would prefer if all such "duplicate" aliases were readded back, to provide that kind of information to the user who might get a rulestring from another source without knowing much about the CA.

This seems like a particularly unlikely occurrence, since someone would have to:
a) convert such a rulestring from MCell's format (for example) to the standard Golly/LifeViewer format
b) actually click on the bottom-left button to bring up the line that shows the current rule, which isn't used often

Using the general-range algorithm to run a range-1 rule, especially for isotropic cases, isn't recommended since performance is worse in the general-range algorithm (a bounding box based algorithm is used rather than a tile-based algorithm), it doesn't support [R]History/Super/Investigator, the rainbow effect, and so on.

Perhaps if there was some way for LifeViewer to detect that a weighted rule can also be represented as an isotropic non-totalistic rule, it could look through the alias table for any matches, but that seems like excessive work for minimal payoff, and readding duplicate aliases would do nothing other than reintroduce pointless bloat to the already extremely long alias list.

[confocaloid]

[...] For range-1 isotropic rules, using isotropic non-totalistic notation is preferred in 100% of known cases to using weighted notation. [...]

I disagree. Weighted notation is preferable in cases when it provides a more intuitive definition of the cellular automaton. In many of those cases, mechanical conversion to Hensel notation loses readability, and it is hard to infer from the resulting rulestring that the CA can be defined using a weighted neighbourhood and sets of numeric birth/survival conditions.

[...]
This seems like a particularly unlikely occurrence, since someone would have to:
a) convert such a rulestring from MCell's format (for example) to the standard Golly/LifeViewer format
[...]

That those definitions are present (in a different syntax, but directly convertible to the NW... notation) in the MCell collection, is by itself an additional reason to keep those aliases. They are historically interesting, as the original definitions for those cellular automata.

[...]
Using the general-range algorithm to run a range-1 rule, especially for isotropic cases, isn't recommended [...]

This is a matter of using the best notation for a given case, rather than a matter of using the best algorithm for a given case. Which notation is used to define a CA and which algorithm is used to evolve patterns are two separate issues.

If there are concerns about using the most efficient algorithm, then a range-1 NW... definition could be internally translated into a different representation, and then processed using the same algorithms as if the CA was defined using Hensel notation or MAP rulestrings.

[muzik]

[...] For range-1 isotropic rules, using isotropic non-totalistic notation is preferred in 100% of known cases to using weighted notation. [...]

I disagree. Weighted notation is preferable in cases when it provides a more intuitive definition of the cellular automaton. In many of those cases, mechanical conversion to Hensel notation loses readability, and it is hard to infer from the resulting rulestring that the CA can be defined using a weighted neighbourhood and sets of numeric birth/survival conditions.

Would you be able to explain how weighted strings represent rules such as Conway++, Conway+-1, etc. in a more intuitive way? I could be biased due to having much more experience with Hensel notation.

[...]
This seems like a particularly unlikely occurrence, since someone would have to:
a) convert such a rulestring from MCell's format (for example) to the standard Golly/LifeViewer format
[...]

That those definitions are present (in a different syntax, but directly convertible to the NW... notation) in the MCell collection, is by itself an additional reason to keep those aliases. They are historically interesting, as the original definitions for those cellular automata.

Perhaps - but in this case conversion over to Hensel notation still seems like the better idea. I wouldn't be opposed to both types of rulestrings being displayed at the same time for isotropic rules which can also be expressed as weighted rules, though.

[muzik]

For cases where every nonzero cell is placed outside of a bounded grid, no "New pattern" message is displayed at all, even though there are no cells that are alive. Compare to a case where no living cells are specified at all - we get "New pattern" as expected.

Code: Select all

x = 1, y = 1, rule = B3/S23:T8,8
16bo!

Code: Select all

x = 1, y = 1, rule = B3/S23:T8,8
b!

For [R]Investigator states in period maps, I'm wondering if it'd be better to have all states above 2 display as the same dark gray colour as state-3 cells, and for it to be renamed from "St.3" to "Special". This rename would also apply to [R]History and [R]Super period maps. Special-casing state 3 and having the rest either render as stator cells or as period-2 cells just seems unuseful and inconsistent to me.

Code: Select all

x = 27, y = 27, rule = B3/S23Investigator
H14$14.C12$26.I!
[[ AUTOIDENTIFY ]]

The red history cells left behind by the deleted glider here are different in the general range algorithm compared to the range-1 algorithm, even though the evolution is otherwise the same. I believe range-1 is correct here.

Code: Select all

x = 22, y = 22, rule = B3/S23
bo$2bo$3o12$14bo6bo$16bo2bo$15b6o$16b4o$16b4o$15b6o$16bo2bo$14bo6bo!
[[ KILLGLIDERS THEME Red ]]

Code: Select all

x = 22, y = 22, rule = R1,C2,S2-3,B3
bo$2bo$3o12$14bo6bo$16bo2bo$15b6o$16b4o$16b4o$15b6o$16bo2bo$14bo6bo!
[[ KILLGLIDERS THEME Red ]]

KILLGLIDERS also doesn't care about state 6 near the edges of patterns, and kills gliders as if said cells were never there, even if they're integral to the evolution of a pattern.

Code: Select all

x = 8, y = 8, rule = B3/S023History
3.F3$4.A2.F$F2.A$3.3A2$4.F!

Code: Select all

x = 8, y = 8, rule = B3/S023History
3.F3$4.A2.F$F2.A$3.3A2$4.F!
[[ KILLGLIDERS ]]

For bounded grids, could some sort of toggle be implemented that causes stator cells and never-alive cells to be treated the same? This would be particularly useful for rules which are their own black-white reversal.

Code: Select all

x = 64, y = 64, rule = B1357/S02468:T64,64
obo2bo2bo6bo2bo2bob2obobo3b3obobo2bob2ob2ob6ob2ob2obo$b3obob3ob2ob3ob
ob3o2b3o4b4o3b2o3bobo3bo2bo3bobo3bo$4o2bobob4obobo2b9o3b3o9b2obobo4bo
bob2o$b5ob3o4b3ob5o2b3obobobobo3b2o5bo3b4o3bo5bo$3b3o2bo2bo2bo2bobobo
b2obob3obo3bobo2bobobob2ob2ob2ob2o3b3o$2ob8obob2o4bo6b5o5b6ob4o2bobo8b
o$2bo2b6o2bob2o11b3obo3b11o2bob2o6b2ob2o$bobob8ob3o3bo6bobobobobob6ob
3o3bo8bobobo$11o3bobob3o6bobobobobob6o3bobob3o$bobob6ob3o3bo9b3obo3b9o
b3o3bo6bobobo$2bo2b10o2bob2o6b5o5b6o2bob2o10b2ob2o$b2obo2bo2b2obo3bo3b
ob2obob3obo3bobo2bob3ob3obo2b2ob2obo2bo$b2o2bobob2obo2bobo3bobo3b2o3b
3o2b3obob3obob2obo2bobob2o2bo$2bo3bo2b3ob2obo5b2o4bob2o2bob4o2b5obo2b
o3b2ob3ob2o$bob3ob4o2b2o4b3o5bobo2b2obob5o3b4o2b2o4bo3bobo$4ob3o4bo2b
o2bo4b3o2bobobobob2o3b4ob2ob2ob4o3bo$bobo2b3o4bo2bo2bo4b3ob4o4bo3b4ob
2ob2ob4o3b2obobo$2bobo5b3o4b2o2b4ob3obobobo3bo4b2o2b4o3b5obob2o$2obo4b
2o5bob2ob3o2bo3bo2b2ob3ob2o3bo2bob5o2b4obo$3b2o3bobo3bobo2bob2obobo2b
2obo2b2obobo2bob2obob3obob3o2b3o$b3obob2obo3bo3bob2o2bo2bob2obo2bob2o
b2o2bob3ob3obo2bobo3bo$5o6b2obo2b10o2bo2b2ob2o10b2obo2b6o$b3o9bo3b3ob
6obobobobobo6bo3b3ob9o3bo$obobo6b3obobo3b11o11b3obobo3b6obobo$obobo6b
o3b3ob8obobobobobo8bo3b3ob6obobo$b3o11b2obo2b6o2bo2b2ob2o6b2obo2b11o3b
o$5o6bo4b2obob8ob2o2bo8bobo2b4ob6o$b3obob2obobobo2bo2bo2bo2b3o3b3o3b2o
b2ob2ob2obobobo2bobo3bo$obob3o2b5ob3o4b3ob5obo5bo3b4o3bo5b2o3bobo$3b9o
2bobob4obobo2b4o4b2obobo4bobob2o9b3o$4b3o2b3obob3ob2ob3obob3obo3bobo3b
o2bo3bobo3b2o3b4o$3bobob2obo2bo2bo6bo2bo2bobobob2ob2ob6ob2ob2obo2bobo
b3o$3obobo2bob2ob2ob6ob2ob2obobobo2bo2bo6bo2bo2bob2obobo$4o3b2o3bobo3b
o2bo3bobo3bob3obob3ob2ob3obob3o2b3o$3o9b2obobo4bobob2o4b4o2bobob4obob
o2b9o$bobo3b2o5bo3b4o3bo5bob5ob3o4b3ob5o2b3obobo$o3bobo2bobobob2ob2ob
2ob2o3b3o3b3o2bo2bo2bo2bobobob2obob3o$5b6ob4o2bobo8bo2b2ob8obob2o4bo6b
5o$o3b11o2bob2o6b2ob2o2bo2b6o2bob2o11b3o$bobob6ob3o3bo8bobobobobob8ob
3o3bo6bobobo$bobob6o3bobob3o11b11o3bobob3o6bobobo$o3b9ob3o3bo6bobobob
obob6ob3o3bo9b3o$5b6o2bob2o10b2ob2o2bo2b10o2bob2o6b5o$o3bobo2bob3ob3o
bo2b2ob2obo2bob2obo2bo2b2obo3bo3bob2obob3o$3o2b3obob3obob2obo2bobob2o
2bob2o2bobob2obo2bobo3bobo3b2o$2bob4o2b5obo2bo3b2ob3ob2o2bo3bo2b3ob2o
bo5b2o4bob2o$2obob5o3b4o2b2o4bo3bobobob3ob4o2b2o4b3o5bobo$obob2o3b4ob
2ob2ob4o3bo4b4ob3o4bo2bo2bo4b3o2bobo$4bo3b4ob2ob2ob4o3b2obobobobo2b3o
4bo2bo2bo4b3ob4o$obo3bo4b2o2b4o3b5obob2o2bobo5b3o4b2o2b4ob3obo$2ob3ob
2o3bo2bob5o2b4obo2b2obo4b2o5bob2ob3o2bo3bo$o2b2obobo2bob2obob3obob3o2b
3o3b2o3bobo3bobo2bob2obobo2b2o$o2bob2ob2o2bob3ob3obo2bobo3bob3obob2ob
o3bo3bob2o2bo2bob2o$2ob2o10b2obo2b6o5b5o6b2obo2b10o2bo$obobo6bo3b3ob9o
3bob3o9bo3b3ob6obobo$11b3obobo3b6obobobobobo6b3obobo3b11o$obobo8bo3b3o
b6obobobobobo6bo3b3ob8obobo$2ob2o6b2obo2b11o3bob3o11b2obo2b6o2bo$2bo8b
obo2b4ob6o5b5o6bo4b2obob8ob2o$3o3b2ob2ob2ob2obobobo2bobo3bob3obob2obo
bobo2bo2bo2bo2b3o$o5bo3b4o3bo5b2o3bobobobob3o2b5ob3o4b3ob5o$4b2obobo4b
obob2o9b3o3b9o2bobob4obobo2b4o$o3bobo3bo2bo3bobo3b2o3b4o4b3o2b3obob3o
b2ob3obob3o$bob2ob2ob6ob2ob2obo2bobob3o3bobob2obo2bo2bo6bo2bo2bobo!

Also, specifically for bounded grids, having background cells be listed in the table of cell types would be useful.

Now that LifeViewer has a public github, would it be preferred to move bug reports and/or feature requests there via the Issues page, so that we can more clearly track what remains to be fixed? Perhaps the remaining backlog items could also be transferred to there.

[confocaloid]

[...] it doesn't support [R]History/Super/Investigator [...]

I'm not an active user of CAViewer, but from my quick experiment it seems to support the notation where the suffix 'History' is appended to a "weighted" definition. I was able to copy the following pattern out of CAViewer, and paste it into this forum post:

Code: Select all

x = 93, y = 66, rule = R1,C0,S2-3,6-7,10-11,15,20,B3,7,11,15,NW515101515History
36.A56.$35.A.A55.$34.A.A.A54.$35.A.A55.$36.A56.$93.$61.B31.$59.4B30.$59.6B28.$55.12B26.$54.14B25.$53.16B24.$52.BA15B24.$43.4B4.A17B24.$41.7B2A6BA13B23.$24.B16.6BA24B21.$23.3AB13.7BA4BABABA16B20.$15.2A6.7B9.9B4A19BA2B19.$14.AB2A4.B2A6B7.32BABA2B18.$13.BABABA4BA2B3A2B5.BA13BA18BABA3B17.$12.3B2ABA2BA9B4.BABA7B2A3BA19BA.4B16.$11.5BABABA11B4.ABA6BA2BA15B2A6B2.4B15.$11.7BA3BA9B4.BA7BA18B2A5B4.4B14.$11.7BA3BA11B.10BA3B2A15B.4B5.4B13.$10.9BA14B3A9B3A2B2A12B4.B7.4B12.$11.21B2A12B.5A13B2.B10.4B11.$12.20B2AB2A28B.2B11.4B10.$14.17BA3BA21B.3BA4B14.4B9.$14.6B.10BABA22B4.3A2B16.4B8.$15.2B5.10B2A23B2.AB2AB18.4B7.$25.32B.2A2B2A19.4B6.$25.6BA25B2.4AB20.4B5.$25.6BA24B4.3A2.B19.4B4.$6.B16.B.6BA24B30.4B3.$5.3B14.35B30.4B2.$4.5B3.B8.6B3A3B3A22B3.B26.4B.$4.6B.3B.B.47B25.3BA$4.27BA30B2A26.ABA$.21B2A7BA13B2A14BA2BAB5.2B18.2A$22BABA6BA10BA2B4A13B2A3B2.5B19.$22BA23B3A4BA13B2.2B.B20.$.42BAB2A6B2A9B29.$2.32BA8BAB2A7B2A4B33.$6.28BA25B33.$6.4B2A22BA17BA7B33.$6.3BA2BA3.36B2A5B34.$6.3BABA5.35B2A5B34.$8.2BA6.7B2A18B.13B35.$17.6B3ABA13B4.13B35.$17.8BA2B2A3B2.3BA2BAB3.B2.7B37.$17.5B4ABA4B4.3A2B3A5.5B7.B31.$17.7B2A7B3.2BA2BAB5.B.4B39.$17.3BABA6B.2B5.4B11.B9.4B27.$18.10B27.B.B2.BA3B28.$21.A4B2A18.3B4.B2.B3.BA3B28.$21.A3BABA17.6B3.B2.B3.AB30.$22.2ABA19.7B2.2B37.$23.3A19.9B39.$24.A22.7B39.$45.10B38.$44.12B37.$44.12B37.$46.9B38.$48.3A4B38.$49.3B41.$50.B!

[...] Would you be able to explain how weighted strings represent rules such as Conway++, Conway+-1, etc. in a more intuitive way? I could be biased due to having much more experience with Hensel notation. [...]

B3/S234c might not be the best example here, because its definition in Hensel notation is already fairly short, it is "almost outer-totalistic", and it is probably relatively easy to remember the meaning of '4c' ("four corners") compared to many other nontotalistic subconditions like '3j' or '4n' or '5r' or what have you.

On the other hand, compare the following two rulestrings:

Code: Select all

R1,C0,S2,4,6,B4,NW121202121
B2ei3inqy4c/S1e2-ak3einqy4-ejnry5e

Both strings define the same CA. It is easy to see which string is shorter.
The shorter rulestring is also more readable; "NW121202121" can be read and immediately understood as a symmetric weighted neighbourhood that distinguishes between orthogonal neighbours and diagonal neighbours, and the listed birth/survival conditions are essentially "B4/S246" except in a different syntax.

Hensel notation in this example leads to a longer rulestring listing many nontotalistic subconditions whose meanings are not easy to remember, some "subtracted" subconditions, and there is no hint that there is a simpler way to define the same CA.

[rowett]

For cases where every nonzero cell is placed outside of a bounded grid, no "New pattern" message is displayed at all, even though there are no cells that are alive. Compare to a case where no living cells are specified at all - we get "New pattern" as expected.

I like the current behaviour. "New pattern" means no alive cells were specified. Defining a pattern where all the alive cells are outside the bounded grid is likely an error, and "New pattern" would be confusing.

For [R]Investigator states in period maps, I'm wondering if it'd be better to have all states above 2 display as the same dark gray colour as state-3 cells, and for it to be renamed from "St.3" to "Special". This rename would also apply to [R]History and [R]Super period maps. Special-casing state 3 and having the rest either render as stator cells or as period-2 cells just seems unuseful and inconsistent to me.

I don't particularly mind renaming "St. 3" and "St. 6" to something more meaningful. I think you put it in one of your pull requests which I haven't processed yet. I'm not interested in changing the other cell state colours.

The red history cells left behind by the deleted glider here are different in the general range algorithm compared to the range-1 algorithm, even though the evolution is otherwise the same.

Fixed, thanks!

KILLGLIDERS also doesn't care about state 6 near the edges of patterns, and kills gliders as if said cells were never there, even if they're integral to

I might fix this if the improvements to KILLGLIDERS ever make the top of the backlog.

For bounded grids, could some sort of toggle be implemented that causes stator cells and never-alive cells to be treated the same?

Treated the same in what way?

Now that LifeViewer has a public github, would it be preferred to move bug reports and/or feature requests there via the Issues page, so that we can more clearly track what remains to be fixed? Perhaps the remaining backlog items could also be transferred to there.

At the moment I believe it's more helpful to have them here since they get seen by more people.

[rowett]

... for cases where the grid isn't visible the bounding rectangle cells might need to be adjusted to fit the rhombic shape.

Done, thanks.

[rowett]

A note on LifeViewer aliases:

Aliases are only a good thing if they are commonly understood across a relevant family of tools. If not then it can create interoperability issues as you move patterns between the tools.

At the moment I'm not aware of any standard repository for aliases so they are not trivial to share between tools.

Based on this LifeViewer will aways convert an alias to the standard rule string when you save patterns or copy patterns to the clipboard.

If there is a clash between a rule name in the Rule Repository and a LifeViewer alias then it's probably best to favour the Rule Repository, unless the Rule Repository version is not used and it's clear that the LifeViewer alias is in use.

[confocaloid]

[...] Also, will MAP strings for the triangular neighbourhood be supported? [...]

I think that earlier estimate of 1369 characters for the length of such MAP strings is too low.
To define an arbitrary (possibly but not necessarily isotropic) two-state CA with this 12-cell neighbourhood, one has to specify what happens for every configuration of each of the two possible orientations of the neighbourhood:

two possible orientations of the 12-cell neighbourhood on the triangular tiling

temp.png (4.21 KiB) Viewed 115 times

That makes 2^14 distinct configurations in total (two possible orientations of the neighbourhood times two possible states of the middle triangular cell times 2^12 possible ways to assign states of the 12 neighbours), so if I'm counting correctly then a MAP string notation for this type of CA would take 2734 characters. Which probably would be way too long a rulestring.

Limiting the scope to isotropic CA, there is only one orientation of the neighbourhood to consider, and 1504 = 752 x 2 conditions. With an approach similar to MAP strings (so non-human-readable), I think a rulestring would take around 254 characters for this type of CA.

Further limiting the scope to those CA which can be represented using a symmetric weighting of the neighbourhood, there are 224 = 2 x (4 x 7 x 4) conditions, and the NW... notation seems to cover this already (even though there could be a more concise dedicated notation for this type of CA):

an idea for symmetric weightings of the neighbourhood (same colour means same weight)

temp.png (4.63 KiB) Viewed 115 times

[muzik]

For bounded grids, could some sort of toggle be implemented that causes stator cells and never-alive cells to be treated the same?

Treated the same in what way?

Cells that never turn on would be treated as stator cells: they would appear gray in period maps, be counted as period-1 in the periods table, and would be treated as period-1 for volatility and strict volatility calculations. This would be toggleable and would only affect bounded grids.

Code: Select all

x = 64, y = 64, rule = B1357/S02468:T64,64
obo2bo2bo6b3ob2obobobobo3b3obobobobo2bo3b6ob2ob2obo$b3obob3ob2ob2obob
o3bob3o4b4o3bob3obobo2bo2bo3bobo3bo$4o2bobob4ob2ob2o4b5o3b3o5b4o2bo2b
o4bobob2o$b5ob3o4b2obo5bob3obobobobo3bob5obo2b4o3bo5bo$3b3o2bo2bo2bob
obobobobobob3obo3bobobobobobobob2ob2ob2o3b3o$2ob8obob6ob3o3b5o5b3o3bo
6bobo8bo$2bo2b6o2bobob7o4b3obo3b4o7bobob2o6b2ob2o$bobob8ob2ob3ob3o3bo
bobobobob3o3bo3bo2bo8bobobo$11o3bo2bo3b3o3bobobobobob3o3b3ob2ob3o$bob
ob6ob3ob2ob5o4b3obo3b4o5bo2bo3bo6bobobo$2bo2b10obobo2b3o3b5o5b3o3b2ob
obo10b2ob2o$b2obo2bo2b2obo2bob3obobobob3obo3bobobobo3bob2obo2b2ob2obo
2bo$b2o2bobob2obo2b2ob3obo4b2o3b3o2b4obo3bo2b2obo2bobob2o2bo$2bo3bo2b
3ob2o2b5o6bob2o2bob6o5b2o2bo3b2ob3ob2o$bob3ob4o2b2ob3o3b2o3bobo2b2obo
b3o2b3o3bo2b2o4bo3bobo$4ob3o4bo2b3ob4ob2o2bobobobob2o2bo4bo3b2ob4o3bo
$obob2o3b4ob3o2bo7bo4b4ob7ob2o3bo4b3o2bobo$2obob5o3b3ob2o2b3obo3bobob
ob3obo3b2o2bo3b3o5bobo$2bob4o2b5o2b2ob3obob3ob2o2bo3bobo3bo2b2o5b2o4b
ob2o$3o2b3obob3ob2o2bob2o2bob2o2bob2o2bob2o2bob2o2bo3bobo3b2o$o3bobo2b
ob3obo2bob2o3b2obo2bob2obo2b3o2bob2obo3bob2obob3o$5b6o2bobob7o3b2ob2o
2bo2b3o7bobob2o6b5o$o3b9ob2ob3ob3o3bobobobobob3o3bo3bo2bo9b3o$bobob6o
3bo2bo3b3o8b8o3b3ob2ob3o6bobobo$obobo6bo3bo2bo5b3obobobobobo3b5ob2ob3o
b6obobo$b3o11bobob2o3b3o2bo2b2ob2o3b3o2bobob11o3bo$5o6bo6bobo3b5ob2o2b
o5b3obob6ob6o$b3obob2obobobobob2ob2o3b3o3b3o3b3o2bo2bobobobobo2bobo3b
o$obob3o2b5obo2b4o2bob5obo5bob2o4b2obo5b2o3bobo$3b9o2bo2bo4bo2bo2b4o4b
2ob2ob4ob2ob2o9b3o$4b3o2b3obobo2bo2bo2bobob3obo3bobob2ob2ob2obobo3b2o
3b4o$3bobob2obo2bo3b6o3bo2bobobob2ob3o6b3ob2obo2bobob3o$3obobo2bob2ob
3o6b3ob2obobobo2bo3b6o3bo2bob2obobo$4o3b2o3bobob2ob2ob2obobo3bob3obob
o2bo2bo2bobob3o2b3o$3o9b2ob2ob4ob2ob2o4b4o2bo2bo4bo2bo2b9o$bobo3b2o5b
ob2o4b2obo5bob5obo2b4o2bob5o2b3obobo$o3bobo2bobobobobo2bo2b3o3b3o3b3o
3b2ob2obobobobob2obob3o$5b6ob6obob3o5bo2b2ob5o3bobo6bo6b5o$o3b11obobo
2b3o3b2ob2o2bo2b3o3b2obobo11b3o$bobob6ob3ob2ob5o3bobobobobob3o5bo2bo3b
o6bobobo$obobo6b3ob2ob3o3b8o8b3o3bo2bo3b6obobo$b3o9bo2bo3bo3b3obobobo
bobo3b3ob3ob2ob9o3bo$5o6b2obobo7b3o2bo2b2ob2o3b7obobo2b6o$b3obob2obo3b
ob2obo2b3o2bob2obo2bob2o3b2obo2bob3obo2bobo3bo$3b2o3bobo3bo2b2obo2b2o
bo2b2obo2b2obo2b2obo2b2ob3obob3o2b3o$2obo4b2o5b2o2bo3bobo3bo2b2ob3obo
b3ob2o2b5o2b4obo$2bobo5b3o3bo2b2o3bob3obobobo3bob3o2b2ob3o3b5obob2o$b
obo2b3o4bo3b2ob7ob4o4bo7bo2b3ob4o3b2obobo$4bo3b4ob2o3bo4bo2b2obobobob
o2b2ob4ob3o2bo4b3ob4o$obo3bo4b2o2bo3b3o2b3obob2o2bobo3b2o3b3ob2o2b4ob
3obo$2ob3ob2o3bo2b2o5b6obo2b2obo6b5o2b2ob3o2bo3bo$o2b2obobo2bob2o2bo3b
ob4o2b3o3b2o4bob3ob2o2bob2obobo2b2o$o2bob2ob2o2bob2obo3bobobobo3bob3o
bobobob3obo2bob2o2bo2bob2o$2ob2o10bobob2o3b3o5b5o3b3o2bobob10o2bo$obo
bo6bo3bo2bo5b4o3bob3o4b5ob2ob3ob6obobo$11b3ob2ob3o3b3obobobobobo3b3o3b
o2bo3b11o$obobo8bo2bo3bo3b3obobobobobo3b3ob3ob2ob8obobo$2ob2o6b2obobo
7b4o3bob3o4b7obobo2b6o2bo$2bo8bobo6bo3b3o5b5o3b3ob6obob8ob2o$3o3b2ob2o
b2obobobobobobobo3bob3obobobobobobobo2bo2bo2b3o$o5bo3b4o2bob5obo3bobo
bobob3obo5bob2o4b3ob5o$4b2obobo4bo2bo2b4o5b3o3b5o4b2ob2ob4obobo2b4o$o
3bobo3bo2bo2bobob3obo3b4o4b3obo3bobob2ob2ob3obob3o$bob2ob2ob6o3bo2bob
obobob3o3bobobobob2ob3o6bo2bo2bobo!

[muzik]

This is obviously minor, but it may be advisable to update this page such that the custom example is no longer inverted.

[Citation needed]

The cogwheel button in this pattern occasionally fails.