Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]

[dvgrn]

Note that "xk" by itself refers to one of 16 single-generation symmetry types, while "xkxk" refers to one of 43 oscillator symmetry types. The sets of labels are completely disjoint. This helpful property makes it easy to tell whether a descriptor refers to a single-generation symmetry type or an oscillator symmetry type.

Thanks! I know you've explained all this perfectly clearly before, too, but not all of those details made it into my first attempt at reworking the kinetic symmetry article. Here's a second iteration, which is hopefully also an incremental improvement.

Have I created any new problems with what I've done so far?

I.e., I think it'd be good to link to the static symmetry page, and to mention both symmetry formats clearly in the category summary -- Hickerson format and Catagolue format. Any other suggestions?

I'm currently planning to go through and do those minor adjustments to the links and descriptions in the various static-symmetry category pages, sometime over the weekend.

[confocaloid]

The recent changes to Template:Stilllife break the markup, due to extra unwanted indentation/newlines (see e.g. Block).
edit: possibly fixed in the next edit as far as visible appearance goes.

IIRC there should be no additional whitespace anywhere, and the switch statement should be placed in a separate helper template, so that one can do a single-line invocation with minimal changes to the existing template code.

broken-markup.png (18.87 KiB) Viewed 9007 times

[dvgrn]

IIRC there should be no additional whitespace anywhere, and the switch statement should be placed in a separate helper template...

Yup, I tried a couple more variants immediately after the initial edit. Whitespace seems to be fine in many places (e.g., in the switch statement) but leading whitespace is definitely a problem -- for obvious reasons when I thought about it, since MediaWiki interprets leading whitespace as a request for a quoted-text block.

Is there a way to preview the effects of a template-page edit, without making those effects visible to everyone? I figured as long as I didn't stop editing for more than a few minutes, and as long as I said things like "try" in the edit summaries, it would be clear that I intended to quickly fix any obvious problems like this, so nobody would worry.

If no one else gets to it first, I'll figure out the "separate helper template" as soon as there's more than one place where this substitution needs to be made. Right now the substitution is only happening in the "Stilllife" template.

I've gone through the sixteen category pages and included links to more relevant information in each one:

Code: Select all

https://conwaylife.com/w/index.php?title=Category:Strict_still_lifes_with_n_symmetry&action=edit
https://conwaylife.com/w/index.php?title=Category:Strict_still_lifes_with_-c_symmetry&action=edit
https://conwaylife.com/w/index.php?title=Category:Strict_still_lifes_with_-e_symmetry&action=edit
https://conwaylife.com/w/index.php?title=Category:Strict_still_lifes_with_/_symmetry&action=edit
https://conwaylife.com/w/index.php?title=Category:Strict_still_lifes_with_.c_symmetry&action=edit
https://conwaylife.com/w/index.php?title=Category:Strict_still_lifes_with_.e_symmetry&action=edit
https://conwaylife.com/w/index.php?title=Category:Strict_still_lifes_with_.k_symmetry&action=edit
https://conwaylife.com/w/index.php?title=Category:Strict_still_lifes_with_%2Bc_symmetry&action=edit
https://conwaylife.com/w/index.php?title=Category:Strict_still_lifes_with_%2Be_symmetry&action=edit
https://conwaylife.com/w/index.php?title=Category:Strict_still_lifes_with_%2Bk_symmetry&action=edit
https://conwaylife.com/w/index.php?title=Category:Strict_still_lifes_with_xc_symmetry&action=edit
https://conwaylife.com/w/index.php?title=Category:Strict_still_lifes_with_xk_symmetry&action=edit
https://conwaylife.com/w/index.php?title=Category:Strict_still_lifes_with_rc_symmetry&action=edit
https://conwaylife.com/w/index.php?title=Category:Strict_still_lifes_with_rk_symmetry&action=edit
https://conwaylife.com/w/index.php?title=Category:Strict_still_lifes_with_*c_symmetry&action=edit
https://conwaylife.com/w/index.php?title=Category:Strict_still_lifes_with_*k_symmetry&action=edit

I didn't touch the wider "pattern" category pages, so each of the above categories is still listed as part of a "Patterns in {Catagolue-syntax symmetry} symmetry" category -- e.g., "[[Category:Patterns with C1 symmetry]]".

If we wanted to be really consistent about prioritizing Hickerson notation for symmetry wherever possible, then it seems like it would be a larger project to rename all of those categories and adjust the hundreds of pages that reference those categories -- right? I don't see how to do a clever template shortcut to deal with that kind of large-scale rename.

It seems possible that many people will think those categories are fine the way they are anyway, though. Let's maybe not start renaming those categories until at least a few people have some time to think about it first. It seems fine to me for someone to tackle the project after maybe a week or three, if there are no strong objections in the meantime.

Similarly, the static symmetry page doesn't show Hickerson-notation equivalents of Catagolue-format symmetries, anywhere except in the diagram at the top. I'm not tackling a rework of that page at the moment -- figured I'd let these changes sit a while and see what people thought should be done next (if anything).

Opinions?

EDIT:

Currently -c (mirror symmetry across a horizontal axis through cell centers) doesn't appear to be processed correctly (see for example hat, professor, omnibus which just display "-c" instead of "-c (D2_+1)").

Good catch, thanks! I wonder what's going wrong there?

... Aha. At first I thought it was just another reminder to never trust anything that a large language model generates, without reading it over three times. I only scanned it once, then figured I'd try it and see if it worked.

It turns out that ChatGPT actually produced 100% perfect template code, except for the pretty-printing issue that added leading whitespace. The only problem was in the table that I gave it as a reference to produce the switch statement. There was a minus sign missing in front of the c.

[muzik]

3) Does it maybe make sense to rename the "Category:Patterns with D4_x4 symmetry" to slightly prioritize Hickerson notation, in the same way -- i.e., "Category:Patterns with xk (D4_x4) symmetry" ?

I'm not sure I see the point in this - the equivalent Goucher notation is already made obvious in the article infobox, and can also be explained in the content body of the category page if needed. Category titles don't need to include all possible valid names, especially if one is considered more important than the other.

[muzik]

[...] The statement "an LWSS appears flipped across an orthogonal line during (period/2)" implicitly allows the extension "an LWSS appears flipped across an orthogonal line during (period/2), and translated along the line by a distance that will be zero for an oscillator and non-zero for a spaceship".

It is obvious that an LWSS never "appears flipped".
(Indeed, suppose otherwise. Suppose an LWSS appears flipped n ticks later. Then the LWSS will appear in the same location and orientation (2n) ticks later. That means it's an oscillator. But obviously an LWSS is a spaceship and not an oscillator. Contradiction.)

If we're going into terminology specifics, what exactly defines the line between a spaceship and an oscillator?

The following rule is equivalent to B3/S23, where cells are instead represented as 2x2 cell blocks, and the entire universe shifts one cell (half a constituent block) each generation. A LWSS can therefore be seen, without ambiguity, to "appear flipped":

Code: Select all

x = 10, y = 8, rule = R3,C2,S5-7,B5-7,NW0000000202020000000002010200000000020202000000000
2b2o4b2o$2b2o4b2o$2o$2o$2o6b2o$2o6b2o$8o$8o!

Conversely, despite this being clearly understood as a flipper oscillator in normal Life, does it lose this attribute in the new rule?

Code: Select all

x = 18, y = 14, rule = R3,C2,S5-7,B5-7,NW0000000202020000000002010200000000020202000000000
2b4o6b4o$2b4o6b4o$6b2o2b2o4b2o$6b2o2b2o4b2o$2o10b4o$2o10b4o$2o2b8o$2o
2b8o$2b4o6b4o$2b4o6b4o$2b4o4b2o4b2o$2b4o4b2o4b2o$4b2o6b4o$4b2o6b4o!

What you're describing seems like a property that indeed applies to flipper oscillators but that falls apart if applied to spaceships under a strict interpretation; whether that interpretation needs to be as strict as it is is what I'm questioning, as there is definitely a consensus elsewhere that spaceships can be considered flippers, and that all but one of the spaceship kinetic symmetry classifications are obvious analogues of existing oscillator classifications.

Would it be of use if example patterns with clearly-described symmetry were added to the kinetic symmetries page to make each classification more clear?

[dvgrn]

I'm not sure I see the point in this - the equivalent Goucher notation is already made obvious in the article infobox, and can also be explained in the content body of the category page if needed. Category titles don't need to include all possible valid names, especially if one is considered more important than the other.

Agreed! I don't think there is any point in those changes. That was a question I was asking just before confocaloid's suggestion about adjusting the Stilllife template to display both Hickerson and Catagolue symmetry syntax.

We've done that now (the functional part anyway, just not the second stage of templatification that confocaloid suggested) -- so we don't actually have to have ugly strings like "n (C1)" in infobox symmetry parameters, we can keep just the "n" part and display "n (C1)".

If I remember right, my original not-very-good thought was to actually put strings like "n (C1)" into infobox parameters... renaming the categories only made sense in the context of that. The content body of the category pages already mentions both syntaxes at this point -- that's plenty good enough, as you say.

[muzik]

Note that Hickerson's notation for symmetry types covers both the 16 single-generation symmetry types, and the 43 oscillator symmetry types.
Note also that the sets of labels for those symmetry types are disjoint, and it is always possible to tell (just from the label) whether it refers to one of 16 single-generation symmetry types, or to one of 43 oscillator symmetry types.
viewtopic.php?p=195445#p195445

Are you referring to the p/m=1 cases such as "nn", "//", etc.? I didn't notice these initially while documenting symmetries, so thank you for bringing these to my attention.

I'm not sure if it's actually useful to be using these duplicated terms for documenting oscillator symmetries, however; calling something "/k" seems sufficient enough to me regardless of whether the oscillator in question is period, 1, 3 or 4; having two parallel Hickerson terminologies seems needlessly overcomplicated and doesn't communicate any further information that can't otherwise be derived from the listed period.

Should we leave these out, or would it be in everyone's best interests to stick with Hickerson's original system?

[confocaloid]

Are you referring to the p/m=1 cases such as "nn", "//", etc.? I didn't notice these initially while documenting symmetries, so thank you for bringing these to my attention.

I'm not sure if it's actually useful to be using these duplicated terms for documenting oscillator symmetries, however; calling something "/k" seems sufficient enough to me regardless of whether the oscillator in question is period, 1, 3 or 4; having two parallel Hickerson terminologies seems needlessly overcomplicated and doesn't communicate any further information that can't otherwise be derived from the listed period.

Should we leave these out, or would it be in everyone's best interests to stick with Hickerson's original system?

Writing "nn" It does communicate the important information that the label represents one of 43 oscillator symmetry types.
Writing "n" instead of "nn" can introduce confusion, because the reader can misinterpret that as a label for one of 16 single-generation symmetry types.
For this reason, I think the infoboxes should explicitly state "nn", "//", etc. for the oscillator symmetry type. This is helpful duplication that explicitly communicates the underlying idea and matches the original notation.

[...] The following rule is equivalent to B3/S23, where cells are instead represented as 2x2 cell blocks, and the entire universe shifts one cell (half a constituent block) each generation. A LWSS can therefore be seen, without ambiguity, to "appear flipped":

Code: Select all

x = 10, y = 8, rule = R3,C2,S5-7,B5-7,NW0000000202020000000002010200000000020202000000000
2b2o4b2o$2b2o4b2o$2o$2o$2o6b2o$2o6b2o$8o$8o!

[...]

The ruleset you specified fails to be equivalent to B3/S23.
Specifically, B3/S23 is isotropic (rotations by multiples of 90 degrees, reflections through grid lines, translations by integer displacements preserve all reactions) while the above CA isn't isotropic anymore. An isotropic CA cannot be equivalent to a non-isotropic CA.

The LWSS is a spaceship in an isotropic CA (namely Conway's Life). This is unambiguous, it isn't a stationary oscillator, it is a moving spaceship.

In non-isotropic CA, the concept of a spaceship can be questioned, and the concept of mod becomes ill-defined/ambiguous (because the geometric symmetries may not correspond to "symmetries" in how the reaction evolves).

[muzik]

Are you referring to the p/m=1 cases such as "nn", "//", etc.? I didn't notice these initially while documenting symmetries, so thank you for bringing these to my attention.

I'm not sure if it's actually useful to be using these duplicated terms for documenting oscillator symmetries, however; calling something "/k" seems sufficient enough to me regardless of whether the oscillator in question is period, 1, 3 or 4; having two parallel Hickerson terminologies seems needlessly overcomplicated and doesn't communicate any further information that can't otherwise be derived from the listed period.

Should we leave these out, or would it be in everyone's best interests to stick with Hickerson's original system?

Writing "nn" It does communicate the important information that the label represents one of 43 oscillator symmetry types.
Writing "n" instead of "nn" can introduce confusion, because the reader can misinterpret that as a label for one of 16 single-generation symmetry types.
For this reason, I think the infoboxes should explicitly state "nn", "//", etc. for the oscillator symmetry type. This is helpful duplication that explicitly communicates the underlying idea and matches the original notation.

I'm not opposed to this change but what I'd need to know is if it'd only apply to oscillators with periods 2n. It seems very alien to me to say that caterer should be described as n, but fox as nn; both of these are very obviously asymmetric in both space and time, so to give one a situational label and the other not could introduce extra confusion, which isn't what we want to be doing.

Is there any reason why we should aim to distinguish between single-generation symmetries and oscillator symmetries? To my knowledge, if we're describing single-generation symmetries, we'd use Goucher notation rather than Hickerson notation, as it's a perfectly fine standard that's worked for years, and they're hard to mix up with each other. This way we wouldn't need to duplicate characters as it's obvious that "n" is referring to the symmetry of something period, since it wouldn't be used elsewhere.

[...] The following rule is equivalent to B3/S23, where cells are instead represented as 2x2 cell blocks, and the entire universe shifts one cell (half a constituent block) each generation. A LWSS can therefore be seen, without ambiguity, to "appear flipped":

Code: Select all

x = 10, y = 8, rule = R3,C2,S5-7,B5-7,NW0000000202020000000002010200000000020202000000000
2b2o4b2o$2b2o4b2o$2o$2o$2o6b2o$2o6b2o$8o$8o!

[...]

The ruleset you specified fails to be equivalent to B3/S23.
Specifically, B3/S23 is isotropic (rotations by multiples of 90 degrees, reflections through grid lines, translations by integer displacements preserve all reactions) while the above CA isn't isotropic anymore. An isotropic CA cannot be equivalent to a non-isotropic CA.

The LWSS is a spaceship in an isotropic CA (namely Conway's Life). This is unambiguous, it isn't a stationary oscillator, it is a moving spaceship.

In non-isotropic CA, the concept of a spaceship can be questioned, and the concept of mod becomes ill-defined/ambiguous (because the geometric symmetries may not correspond to "symmetries" in how the reaction evolves).

Indeed that rule is anisotropic - but I don't see how it doesn't clearly embed the behaviour of B3/S23. Evolution happens the same way if you place your block units right:

Code: Select all

x = 6, y = 6, rule = R3,C2,S5-7,B5-7,NW0000000202020000000002010200000000020202000000000
2b2o$2b2o$4o$4o$2b4o$2b4o!

The rule also still preserves some mirror symmetries (vertical flipping centered on a block or on the edge between two blocks), so the degree of isotropy is higher than a completely non-isotropic rule. In particular, the vertical flipping of a LWSS, at least in this orientation, still happens. Since it remains stationary in this context, how should it not be considered an oscillator with this change in view?

[confocaloid]

[...] I'm not opposed to this change but what I'd need to know is if it'd only apply to oscillators with periods 2n. [...]

When the topic of the page is an oscillator, it should be described as an oscillator, and its oscillator symmetry type (one of 43) should be specified using the two-part label. (Both the caterer and the fox should be labelled in this way.)

When the topic of the page implies that it only makes sense to discuss single-generation symmetries (e.g. still life, or perhaps unstable active object), the single-generation symmetry type (one of 16) should be specified.

Using Hickerson's notation in both cases seems to be the most consistent approach to me. Hickerson's notation defines separate sets of labels, both for single-generation symmetry types and for oscillator symmetry types.

[...] Is there any reason why we should aim to distinguish between single-generation symmetries and oscillator symmetries? [...]

The reason is that they make sense in different situations. A single-generation symmetry type can be specified (explicitly) in those cases when that suffices (also explicitly communicating the choice to specify a single-generation symmetry type). An oscillator symmetry type can be specified (explicitly) when describing an oscillator (also explicitly communicating the choice to specify an oscillator symmetry type).

I think the preceding discussion in this thread already shows that the idea is to use Hickerson's notation in both cases, but explicitly distinguish between single-generation symmetry types and the oscillator symmetry types.

[...] Since it remains stationary in this context, how should it not be considered an oscillator with this change in view?

It is not a B3/S23 (Conway's Life) oscillator. The wiki is primarily focused on CGoL. Out of other CA, the wiki is primarily focused on isotropic CA.
As far as the purpose of the wiki goes, LWSS is unambiguously a moving spaceship, and isn't a stationary oscillator.

I think further discussion of these ideas may be offtopic for this thread, but might be continued somewhere else.

[confocaloid]

It looks like the "project" is abandoned in incomplete state. There are inconsistencies across pages. There are differences between the defined notation ( https://conwaylife.com/ref/DRH/stamps.html ) and the specified character strings in the infoboxes. There are some unfinished attempts to go beyond what was clearly defined in available sources, without attempting to write down comparably clear definitions for the new notation(s) and either prove completeness or link to sources where that was done.

As an example, in the wiki page fumarole, the infobox claims that "kinetic symmetry" of the oscillator is "-e"
Checking that against the defined notation ( https://conwaylife.com/ref/DRH/stamps.html ), the infobox is incorrect.
The character string "-e" is defined to denote one of 16 single-generation symmetry types. To denote the oscillator symmetry type, one would need to write "-e-e" instead. In that key-value pair, either the key should be changed to say that it is about the single-generation symmetry type of the oscillator, or the value should be changed to use the correct notation.

Further, spaceship symmetry types apparently weren't clearly defined at all, and instead were merely listed without an attempt to explain them, provide the underlying reasoning/intuition for the system, and explicitly prove that the list is complete. For example, in the wiki page glider the infobox claims that "kinetic symmetry" is "n/e" but it is unclear what that character string means in that context.

[...]
Writing "nn" It does communicate the important information that the label represents one of 43 oscillator symmetry types.
Writing "n" instead of "nn" can introduce confusion, because the reader can misinterpret that as a label for one of 16 single-generation symmetry types.
For this reason, I think the infoboxes should explicitly state "nn", "//", etc. for the oscillator symmetry type. This is helpful duplication that explicitly communicates the underlying idea and matches the original notation.
[...]

[...]
To describe symmetries of a still life, it suffices to tell the single-generation symmetry type (16 possibilities, defined in DRH/stamps.html).
To describe symmetries of an oscillator, one needs to tell more (43 possibilities, defined in DRH/stamps.html).
To describe symmetries of a spaceship, one needs to tell something, but it still remains to be explained how much and what are the possibilities.

[muzik]

The burden of definition is on whoever is proposing the new notation.

Until and unless there is a clear human-readable definition providing the complete set of "spaceship symmetry types" and explaining what each one means, all uses in infoboxes are ill-defined and unreliable. (And consequently there are no "examples of each category" to begin with, because the categories were not yet defined.)

I planned on doing this earlier, but it's done now: Kinetic symmetry#Spaceships now has tables detailing each of the eight possible spaceship symmetries in the same way oscillator symmetries are described. Is this sufficient, or are we now in "don't put terminology you made up yourself on the wiki unless there's clear community consensus it should be used" territory?

[dvgrn]

I planned on doing this earlier, but it's done now: Kinetic symmetry#Spaceships now has tables detailing each of the eight possible spaceship symmetries in the same way oscillator symmetries are described.

Thanks for doing this.

Is this sufficient, or are we now in "don't put terminology you made up yourself on the wiki unless there's clear community consensus it should be used" territory?

I'm thinking maybe we're in "pause here for a while and see if people will show up for a discussion" territory. Consensus may arrive fairly quickly, or someone may come up with specific issues that need to be addressed with this extension of Hickerson's notation to spaceships.

This is something of a tangent to the spaceship-classification topic, but what do you think of confocaloid's suggestion above, that (for example) "-e" should always be a single-phase symmetry designation, and that "-e-e" would be used for oscillators -- to make it clear, just from looking at the symmetry string, that we're talking about a kinetic symmetry?

[muzik]

This is something of a tangent to the spaceship-classification topic, but what do you think of confocaloid's suggestion above, that (for example) "-e" should always be a single-phase symmetry designation, and that "-e-e" would be used for oscillators -- to make it clear, just from looking at the symmetry string, that we're talking about a kinetic symmetry?

What I was going to address after this. There are other things I'd need to know, such as whether odd oscillator periods are subject to this, or if it also applies to spaceships and/or still lifes.