Pattern viewer for forum threads

[rowett]

reposting this ruletable here so the code boxes above can pull from it even after it gets deleted on the wiki:

That won't work. It would need to be appended to each pattern above.

[rowett]

Copy as MAP doesn't appear to work for range-1 weighted rules, despite the fact that they can be represented as MAP strings:

They can't be represented as MAP strings. There's no way to define the weights in MAP format.

Where in the source code are definitions for themes stored? I can't seem to find anything when searching by name, but that could just be GitHub search being terrible.

They are defined in the Life.prototype.createColourThemes() function which is in life.js.

[unname4798]

Copy as MAP doesn't appear to work for range-1 weighted rules, despite the fact that they can be represented as MAP strings:

They can't be represented as MAP strings. There's no way to define the weights in MAP format.

Where in the source code are definitions for themes stored? I can't seem to find anything when searching by name, but that could just be GitHub search being terrible.

They are defined in the Life.prototype.createColourThemes() function which is in life.js.

R1 Weighted rules are in the range of R1 Moore rules.
You can represent them as MAP rulestrings

[rowett]

Copy as MAP doesn't appear to work for range-1 weighted rules, despite the fact that they can be represented as MAP strings:

They can't be represented as MAP strings. There's no way to define the weights in MAP format.

R1 Weighted rules are in the range of R1 Moore rules.
You can represent them as MAP rulestrings

True, you're both correct.

Copy as MAP is only supported for 2-state RuleLoader rules.

[confocaloid]

Copy as MAP doesn't appear to work for range-1 weighted rules, despite the fact that they can be represented as MAP strings:

Code: Select all

x = 6, y = 6, rule = R1,C2,S2-3,6-10,12-13,B5,NW141404140
2b2o$bo2bo$o4bo$o4bo$bo2bo$2b2o!

[...]

I think it might be more interesting to have a conversion in the other direction. Sometimes, a MAP rulestring can be replaced by an equivalent rulestring that uses a range-1 weighted neighbourhood.

Converting from R1 weighted to MAP would lose weights (the specific weighted neighbourhood that was used). To convert in the other direction (when possible), one would need to choose (more or less arbitrarily) a specific weighted neighbourhood, and that choice would determine sets of survival/birth conditions listed in the rulestring. Some choices of a weighted neighbourhood may be "better" than other choices, in the sense that the resulting rulestring would become shorter / easier to read and understand.

[rowett]

"Copy Nhood" doesn't appear to work as expected for triangular rules.

Fixed, thanks!

[Sokwe]

Here is the current list of RuleLoader repository rules that clash with aliases:

I've marked all of the 2-state ruletables that duplicate an alias for deletion.

Do you mean that these were rules such that the rule table had the exact same behavior as the alias?

I've renamed the rule tables to get rid of the non-identical clashes.

At least in the case of the rule "particles", the alias should be deleted, and the rule table should be retained. The INT alias comes from this very short thread where it was never actually used as the rule name in any RLEs. By contrast, there are several RLEs using the rule table variant. "particles" is also in the rule table repository, so anyone using that would encounter problems posting their "particles" patterns to the forums.

There may be other cases where the alias should be deleted, and the rule table should be retained.

[muzik]

Do you mean that these were rules such that the rule table had the exact same behavior as the alias?

Yes; all but four of these have now been deleted.

I've renamed the rule tables to get rid of the non-identical clashes.

At least in the case of the rule "particles", the alias should be deleted, and the rule table should be retained. The INT alias comes from this very short thread where it was never actually used as the rule name in any RLEs. By contrast, there are several RLEs using the rule table variant. "particles" is also in the rule table repository, so anyone using that would encounter problems posting their "particles" patterns to the forums.

There may be other cases where the alias should be deleted, and the rule table should be retained.

I've reverted this specific case and put a pull request on GitHub to resolve the conflict.

[muzik]

What exactly does Scale represent in Help > Info > Display, and is there any way to change it?

There are three related items:

• Pixel Ratio is the ratio of the resolution in physical pixels to the resolution in CSS pixels on the current device. See here for more information. It is typically 1 for normal screens and 2 for high DPI screens. However, if you scale the browser window this will change.
• Scale is the scaling factor that LifeViewer applies to the PopUp Viewer window. It will be the same as Pixel Ratio unless that makes the Popup Viewer too big to fit in the browser window, it which case it will be reduced to compensate, but never less than 1.
• Window Zoom is typically 1, but will be less than 1 if the Pixel Ratio is so high that a Scale of 1 is not enough to fit the Popup Viewer in the browser, in which case it will be less than 1.

I can reproduce the "hexagonal period map breaks when changing zoom" on desktop by doing these things (my monitor is 1920x1080 so you may want to change some values on your end if yours isn't):

- Enter the browser advanced settings page (this is about:config on Firefox and derivatives)
- Change the value of layout.css.devPixelsPerPx - in my case, setting it to 1.2 worked. You'll want "Scale" in Help > Info > Display to be a different value when the browser window is maximised versus minimised.
- Identify an oscillator in a 2-state hexagonal rule
- Minimse and maximise the window repeatedly

Code: Select all

x = 10, y = 10, rule = B2o/S2m34H
2b2ob$b3ob$3bob$4ob$2ob!

Code: Select all

x = 5, y = 2, rule = B2/S2-mH
3o$3b2o!

The initial map, and results after two cycles:

MapInitial.png (103.79 KiB) Viewed 321 times

MutilatedMap.png (133.36 KiB) Viewed 321 times

Also, another bug: click inside of the bounded grid, and drag that click outside of it, up and to the left or right, and we'll get one escapee cell.

Code: Select all

x = 2, y = 2, rule = B1357/S02468:T64,64
2o$2o!
[[ MAXGRIDSIZE 9 ZOOM 1 DELETERANGE 1 ]]

There appears to be a bug which may be exclusive to Waterfox which I can't reproduce consistently, but sometimes it's impossible to get the viewer into focus, and clicking just repeats the "Click to control" message. I'll post here if I can figure out reproduction steps.

Also, any idea when the pull requests I've had queued will be merged into LifeViewer so that the Particles conflict (among other issues) can be resolved?

[rowett]

I can reproduce the "hexagonal period map breaks when changing zoom" on desktop by doing these things...

Thanks I'll take a look.

Also, another bug: click inside of the bounded grid, and drag that click outside of it, up and to the left or right, and we'll get one escapee cell.

Fixed, thanks!

Also, any idea when the pull requests I've had queued will be merged into LifeViewer so that the Particles conflict (among other issues) can be resolved?

I've merged the alias update one. I haven't had a chance to look at the other yet.

[rowett]

I can reproduce the "hexagonal period map breaks when changing zoom" on desktop by doing these things...

Fixed, thanks!

[muzik]

Something I've wanted to request for a while: could we have some way of customising rulestrings visually, for isotropic non-totalistic rules on the square grid and hexagonal grid? A lot of newer members in the community might not remember the full table, so some way to visually see what transitions are selected and what isn't would help a lot with that. In addition, I find being forced to open a text box and change characters in the rulestring just to toggle one transition quite frustrating, so a change like this would streamline manual rulegolfing considerably.

Life32 had a system like this:

image.png (25.51 KiB) Viewed 218 times

Each transition icon can be toggled on or off to add the transition to the current rule, or take it away.

Along with the standard Moore and hexagonal neighbourhoods, this could end up being a useful asset if other isotropic non-totalistic rulespaces end up being implemented (such as the ones CAViewer and lifelib support), since those will obviously be very new to most people in comparison.

Is this something others here would like to see?

[confocaloid]

[...] Is this something others here would like to see?

Something I would like to see is meaningful self-explanatory consistent terminology, which is painfully needed. Unfortunately this need is not taken seriously by currently active people.

[...] so a change like this would streamline manual rulegolfing considerably.

Life32 had a system like this:
image.png
[...]

I don't think a visual UI would streamline rulegolfing. That is going to result in too many UI actions (mouse clicks, key presses, etc.)
It's much faster and easier to edit the rulestring (or the @RULE file) directly, than to go back and forth between the pattern and the visual CA definition editor dialog.

Especially when you're mentioning "other isotropic non-totalistic rulespaces". A visual UI is going to be unfeasible (and not merely inconvenient to use) for larger rulespaces.

What could help is having the rulestring edit box in the same window as the pattern. Instead of going to a separate dialog to edit the rulestring, you could then simply edit the rulestring.

Within LifeViewer, there may not be enough screen space to implement any of the above.
Within Golly user interface, an additional UI panel with a rulestring editor could be possible, without eating too much screen space.

[muzik]

[...] Is this something others here would like to see?

Something I would like to see is meaningful self-explanatory consistent terminology, which is painfully needed. Unfortunately this need is not taken seriously by currently active people.

??????????

I don't think a visual UI would streamline rulegolfing. That is going to result in too many UI actions (mouse clicks, key presses, etc.)
It's much faster and easier to edit the rulestring (or the @RULE file) directly, than to go back and forth between the pattern and the visual CA definition editor dialog.

To be clear, this would be an optional alternative to the current system; editing the rulestrings manually would remain as an option.

Within LifeViewer, there may not be enough screen space to implement any of the above.

This could depend on how big the embed or popup actually is (like how settings is disabled for small windows) but I think this is entirely doable. A visual example will come hopefully soon.

[confocaloid]

[...]

I don't think a visual UI would streamline rulegolfing. That is going to result in too many UI actions (mouse clicks, key presses, etc.)
It's much faster and easier to edit the rulestring (or the @RULE file) directly, than to go back and forth between the pattern and the visual CA definition editor dialog.

To be clear, this would be an optional alternative to the current system; editing the rulestrings manually would remain as an option. [...]

My point remains.
Too many UI actions (switch to the editor, click, type, click, type, click, type, switch back to the pattern, play, undo, switch, click, type, switch, etc.)
Significant complexity to be added, with potential of causing various kinds of interesting bugs and user experience issues, and without clear benefit over what is already available.

[muzik]

Hexagonal grid period maps have extra black space on the top left and bottom right which correspond to area without any activity:

Code: Select all

x = 3, y = 2, rule = B2o3m56/S2-p4oH
o$3o!
[[ THEME Day AUTOIDENTIFY ]]

Would it be possible to either make this region transparent, or fill it in with the grid pattern as well?

[muzik]

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?

Code: Select all

x = 7, y = 3, rule = B3/S23
o3b3o$3o2bo$bo!
[[ THUMBNAIL HEIGHT 400 WIDTH 1000 ]]

[rowett]

Would it be possible to either make this region transparent, or fill it in with the grid pattern as well?

Yes, done.

[R2INT]

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?

Code: Select all

x = 7, y = 3, rule = B3/S23
o3b3o$3o2bo$bo!
[[ THUMBNAIL HEIGHT 400 WIDTH 1000 ]]

Pressing N should work.

Also, how do I modify the 10, 11 and 12 conditions in the triangular grid?

Code: Select all

x = 2, y = 2, rule = B123456789/S0123456789L
$bo!

[muzik]

Also, how do I modify the 10, 11 and 12 conditions in the triangular grid?

Code: Select all

x = 2, y = 2, rule = B123456789/S0123456789L
$bo!

Those are represented by X, Y and Z.

[muzik]

Would it be possible to either make this region transparent, or fill it in with the grid pattern as well?

Yes, done.

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

Code: Select all

x = 1, y = 1, rule = B135/S0246H
o!
[[ MAXGRIDSIZE 9 DELETERANGE 1 ZOOM -1 AUTOIDENTIFY ]]

Some kinds of oscillators have a tendency to be displayed quite off-center in maps. Is this at all fixable, or would we need to establish some better definition for bounding shapes of hexagonal patterns first?

Code: Select all

x = 4, y = 4, rule = B2o45/S2o45H
2o$3o$4o$b3o!
[[ AUTOIDENTIFY ]]

Code: Select all

x = 25, y = 25, rule = B2o46/S2o46H
b3o$o4bo$7o$obo2bobo$bob3obo2$5bo6$7b3o$8b2o$8b3o$7b6o$8b5o$2o7bo2bo7b
2o$o21bo$4obo12bob4o$2bobo15bobo$bobobo14bobobo$2bob2o15b2obo$3bobobo
12bobobo$5b3o13b3o!
[[ AUTOIDENTIFY ]]

Code: Select all

x = 13, y = 13, rule = B2o3o4o/S2o3-m46H
b2o5b2o$2o8b2o$b2o7b2o$bo10bo$2bo3b3o3bo$7b2o$8bo4$8bobobo$9b4o$11bo!
[[ AUTOIDENTIFY ]]

[confocaloid]

[...] we don't yet have an agreed upon definition of what a bounding shape on these grids should be. Compare the following three patterns - they showcase the same three life in three orientations, but the values the bounded grid reports back with differ - [...]

[...] bounding shapes of hexagonal patterns [...]

On the hexagonal tiling, one simple possibility is to find the intersection of six "half-planes" each of which contains the finite pattern in such a way that at least one nonzero cell is adjacent to the boundary:

Code: Select all

x = 33, y = 25, rule = B2/SHHistory
3.D13.D10.D$3.D14.D9.D$32D$3.D15.BD7.D$3.D15.2AD6.D$3.D16.B.D5.D$3.D
19.D4.D$3.D6.AB12.D3.D$3.D6.2BA12.D2.D$3.D7.3B12.D.D$3.D8.BA13.2D$3.D
24.D$3.D20.BA2.2D$3.D20.AB2.D.D$D2.D16.BA6.D2.D$.D.D17.AB5.D$2.2D24.D
$3.DBA5.B4.BA7.BA.D$3.2DAB4.2A3.3B7.ABD$3.D.D6.B3.2BA9.D$3.D2.D10.AB
9.D$33D$3.D4.D19.D$3.D5.D18.D$3.D6.D17.D!
#C [[ GRID ]]

Each "half-plane" can be written as an inequality in coordinates, resulting in [a set of] six inequalities:

Code: Select all

#C x >= 0
#C y >= 0
#C x - y <= 15
#C x <= 23
#C y <= 17
#C x - y >= -14
x = 24, y = 18, rule = B2/SHHistory
16B$15B2A$18B$19B$6BA13B$8BA12B$22B$9BA13B$24B$21BA2B$20BA3B$17BA6B$
17BA6B$24B$BA11BA8BAB$.A5B2A13BAB$2.12BA9B$3.10BA10B!
#C [[ GRID ]]

Likewise, on the triangular tiling it is possible to intersect six half-planes:

canvas.png (70.47 KiB) Viewed 77 times

Code: Select all

#C [[ VIEWONLY GRID ]]
x = 69, y = 45, rule = R1,C3,S3-4,8,B4-5,NL
29.2B13.2B$28.2B15.2B$23.29B$26.2B18.A2B$25.2B18.2A.2B$24.2B19.A3.2B$
23.2B25.2B$22.2B27.2B$21.2B29.2B$20.2B31.2B$19.2B33.2B$18.2B35.2B$17.
2B37.2B$16.2B39.2B$15.2B2A.2A36.2B$14.2B.2A.2A37.2B$13.2B45.2B$12.2B
22.3A22.2B$11.2B22.A3.A22.2B$10.2B22.A4.A23.2B3.B$9.2B23.2A.2A25.2B.
2B$8.2B55.3B$7.2B56.3B$6.2B56.2B.2B$5.2B56.2B3.B$4.2B6.3A47.2B$3.2B6.
A2.A46.2B$B.2B7.3A46.2B$3B56.2B$3B55.2B$B.2B53.2B$3.2B51.2B$4.2B49.2B
$5.2B47.2B$6.2B45.2B$7.2B40.2A.2B$8.2B37.A.2A2B$9.2B.3A34.A2B$10.2B2.
2A33.2B$11.2BA12.2A.A.2A15.2B$12.2B13.5A15.2B$13.2B12.A.A.A14.2B$10.
41B$15.2B27.2B$16.2B25.2B!

[muzik]

Each "half-plane" can be written as an inequality in coordinates, resulting in [a set of] six inequalities:

Each of the irregular bounding hexagons is comprised of three sets of two parallel lines, so surely it'd make more sense to describe bounding shapes as a set of three "distances" between each pair to make this truly position-agnostic? Or would further information be needed to fully communicate the shape?

[confocaloid]

Each "half-plane" can be written as an inequality in coordinates, resulting in [a set of] six inequalities:

Each of the irregular bounding hexagons is comprised of three sets of two parallel lines, so surely it'd make more sense to describe bounding shapes as a set of three "distances" between each pair to make this truly position-agnostic? Or would further information be needed to fully communicate the shape?

No, simply writing three distances between parallel lines does not capture the "bounding shape".

The following two patterns on the hexagonal tiling have two different "bounding shapes" in the above sense (intersections of "half-planes"), but the distances are the same in both cases:

Code: Select all

x = 22, y = 22, rule = B2/SHHistory
12.D3.D$11.8D$12.DC3BCD$11.2D6B2D$12.DCBCBCBCD$12.2D6B2D$14.D2BC2BD$
15.D4BD$16.DCBCD$2.D.D11.6D$2.D2.D12.D.D$9D$2.DC2BCD$D.D5BD.D$.2D6B2D
$2.DC2BC2BCD$2.2D6B2D$2.D.D5BD.D$5.DC2BCD$4.9D$7.D2.D$8.D.D!
#C [[ GRID ]]

Code: Select all

x = 17, y = 17, rule = B2/SHHistory
10.C3BC$10.6B$10.CBCBCBC$11.6B$12.2BC2B$13.4B$14.CBC4$C2BC$5B$6B$C2BC
2BC$.6B$2.5B$3.C2BC!
#C [[ GRID ]]

You can combine the six inequalities into three double inequalities, on x, y, and x - y respectively:

Code: Select all

x_min <= x <= x_max
y_min <= y <= y_max
xmy_min <= x-y <= xmy_max

This is analogous to describing the bounding rectangle of a pattern on the square tiling using two double inequalities (x_min <= x <= x_max, y_min <= y <= y_max).

[muzik]

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

Code: Select all

x = 72, y = 130, rule = B2/SHHistory
73$15.D$15.2D$15.D.D$15.D2.D$15.D3.D$15.D4.D$15.D5.D$15.D6.D$15.D7.D$
15.D8.D$15.D9.D$15.D10.D$15.D11.D$15.D12.D$15.D13.D$15.D14.D$41D$.D13.
D15.BD7.D$2.D12.D15.2AD6.D$3.D11.D16.B.D5.D$4.D10.D19.D4.D$5.D9.D6.AB
12.D3.D$6.D8.D6.2BA12.D2.D$7.D7.D7.3B12.D.D$8.D6.D8.BA13.2D$9.D5.D24.
D$10.D4.D20.BA2.2D$11.D3.D20.AB2.D.D$12.D2.D16.BA6.D2.D$13.D.D17.AB5.
D3.D$14.2D24.D4.D$15.DBA5.B4.BA7.BA.D5.D$15.2DAB4.2A3.3B7.ABD6.D$15.D
.D6.B3.2BA9.D7.D$15.D2.D10.AB9.D8.D$15.36D$20.D19.D$21.D18.D$22.D17.D
$23.D16.D$24.D15.D$25.D14.D$26.D13.D$27.D12.D$28.D11.D$29.D10.D$30.D9.
D$31.D8.D$32.D7.D$33.D6.D$34.D5.D$35.D4.D$36.D3.D$37.D2.D$38.D.D$39.2D
$40.D!
#C [[ GRID ]]

Code: Select all

x = 28, y = 28, rule = B2/SHHistory
14.D$14.2D$14.D.D$14.D2.D$14.D3.D$11.12D$12.D.DC3BCD.D$13.2D6B2D$14.D
CBCBCBCD$14.2D6B2D$14.D.D2BC2BD.D$4.D9.D2.D4BD2.D$4.2D8.D3.DCBCD3.D$4.
D.D7.14D$4.D2.D12.D.D$13D8.2D$.D2.DC2BCD2.D9.D$2.D.D5BD.D$3.2D6B2D$4.
DC2BC2BCD$4.2D6B2D$4.D.D5BD.D$4.D2.DC2BCD2.D$4.13D$9.D2.D$10.D.D$11.2D
$12.D!
#C [[ GRID ]]

Code: Select all

#C [[ VIEWONLY GRID ZOOM 4 ]]
x = 114, y = 67, rule = R1,C3,S3-4,8,B4-5,NL
63.B$62.3B$61.2B.2B$60.2B3.2B$59.2B5.2B$58.2B7.2B$57.2B9.2B$56.2B11.2B
$55.2B13.2B$54.2B15.2B$113B$.2B49.2B18.A2B35.2B$2.2B47.2B18.2A.2B33.2B
$3.2B45.2B19.A3.2B31.2B$4.2B43.2B25.2B29.2B$5.2B41.2B27.2B27.2B$6.2B39.
2B29.2B25.2B$7.2B37.2B31.2B23.2B$8.2B35.2B33.2B21.2B$9.2B33.2B35.2B19.
2B$10.2B31.2B37.2B17.2B$11.2B29.2B39.2B15.2B$12.2B27.2B2A.2A36.2B13.2B
$13.2B25.2B.2A.2A37.2B11.2B$14.2B23.2B45.2B9.2B$15.2B21.2B22.3A22.2B7.
2B$16.2B19.2B22.A3.A22.2B5.2B$17.2B17.2B22.A4.A23.2B3.2B$18.2B15.2B23.
2A.2A25.2B.2B$19.2B13.2B55.3B$20.2B11.2B56.3B$21.2B9.2B56.2B.2B$22.2B
7.2B56.2B3.2B$23.2B5.2B6.3A47.2B5.2B$24.2B3.2B6.A2.A46.2B7.2B$25.2B.2B
7.3A46.2B9.2B$26.3B56.2B11.2B$26.3B55.2B13.2B$25.2B.2B53.2B15.2B$24.2B
3.2B51.2B17.2B$23.2B5.2B49.2B19.2B$22.2B7.2B47.2B21.2B$21.2B9.2B45.2B
23.2B$20.2B11.2B40.2A.2B25.2B$19.2B13.2B37.A.2A2B27.2B$18.2B15.2B.3A34.
A2B29.2B$17.2B17.2B2.2A33.2B31.2B$16.2B19.2BA12.2A.A.2A15.2B33.2B$15.
2B21.2B13.5A15.2B35.2B$14.2B23.2B12.A.A.A14.2B37.2B$13.101B$41.2B27.2B
$42.2B25.2B$43.2B23.2B$44.2B21.2B$45.2B19.2B$46.2B17.2B$47.2B15.2B$48.
2B13.2B$49.2B11.2B$50.2B9.2B$51.2B7.2B$52.2B5.2B$53.2B3.2B$54.2B.2B$55.
3B$56.B!

Cases where one is completely internal to the other obviously wouldn't be unique but I don't know about the rest.