Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]

[confocaloid]

Large-scale changes definitely need observable consensus.

If someone is planning to edit "a few dozen [...] pages" at once, then it is no longer "experimental edits".

[...] experimental edits [...]
[...] a few dozen still-life pages -- [...]

[dvgrn]

Large-scale changes definitely need observable consensus.

If someone is planning to edit "a few dozen [...] pages" at once, then it is no longer "experimental edits".

[...] experimental edits [...]
[...] a few dozen still-life pages -- [...]

One or two dozen edits is big enough to get the attention of anyone who might want to weigh in on whether the edits should be done. I think it's also a fairly small fraction of the total number of edits that would be needed to make this proposed adjustment for still lifes. It's also an extremely easy number of edits to undo, if it eventually turns out that there's a consensus in the other direction -- especially if they're all made in a fairly short time by the same person.

So, @confocaloid, I acknowledge that you have now stated an opinion that "experimental edits" isn't the right phrase to use for this situation -- but nonetheless, speaking as a moderator, my recommendation is that a dozen or two dozen experimental edits can safely be done, followed by another pause of a week or two to see if anyone wants to continue this discussion.

[confocaloid]

I would definitely prefer to wait for more discussion, and wait for more observable evidence of people agreeing on what exactly needs to be done, before doing any further batches of edits on these issues.

Regarding two recent edits:

https://conwaylife.com/w/index.php?titl ... did=155577

I think re-adding "C2_4" fails to be an improvement. The topic of the article is unique father problem, which is not just a single specific pattern. The topic of this article doesn't have any specific symmetry (either static or kinetic).

The idea to show some pattern in the infobox is by itself problematic in this case (and in other similar cases where the topic of an article isn't a specific pattern). Adding properties that are not relevant to the topic itself only makes things worse.

I think the symmetry should be removed from this infobox.

If there's a perceived problem about "the infobox saying that the symmetry is 'unspecified'" (as stated in the linked edit summary), then that problem needs to be solved by changing the infobox template code to hide the line when the topic of the article doesn't have any specific symmetry.

https://conwaylife.com/w/index.php?titl ... did=155578

Problematic for the same reasons. (The topic of the article is grandfather problem, which is not just a single specific pattern. The topic of this article doesn't have any specific symmetry.) I think the symmetry should be removed from this infobox.

[Haycat2009]

After discussion with dvgrn, I have decided to do 20 edits about this spread throughout next week. Stay tuned, and don’t be afraid to stop me.

[hotdogPi]

don’t be afraid to stop me.

Confocaloid is currently unable to edit the wiki. He physically cannot stop you.

[Haycat2009]

don’t be afraid to stop me.

Confocaloid is currently unable to edit the wiki. He physically cannot stop you.

I am not referring only to confocaloid. I am referring to dvgrn, any admin, Musik (Who has stopped me before) and anyone who disagrees. Controversial decisions need baby steps.

[confocaloid]

[...] Controversial decisions need baby steps.

Controversial issues need discussion regarding what exactly needs to be done, until there is some observable agreement on what exactly can and should be done.

The edits that were already made are already problematic (see preceding posts). Making more of such edits would just create more issues, while also failing to solve existing issues.

[dvgrn]

https://conwaylife.com/w/index.php?titl ... did=155578

Problematic for the same reasons. (The topic of the article is grandfather problem, which is not just a single specific pattern. The topic of this article doesn't have any specific symmetry.) I think the symmetry should be removed from this infobox.

I assume you also object to muzik's immediate undo of Haycat2009's other edit with that "Why does a problem have a symmetry???" edit summary, then?

It seems to me that when there's a pattern being displayed in an infobox, it's not a big problem to mention what the symmetry of that displayed pattern is. Seems like muzik was thinking along similar lines.

Muzik's and my edit summaries give our reasons for those undo operations. Those reasons still seem adequate to me. If someone wants to fiddle around with the infobox template code to suppress the displayed symmetry line for articles about problems, that's probably fine too -- but it seems unnecessary.

It might be more consistent to change those articles so that they don't have infoboxes at all, and therefore nobody is tempted to say what the symmetry is of the pattern displayed in the infobox. When I originally created the Coolout Conjecture article in 2016, it didn't have an infobox or categories -- I didn't see how those were relevant. The article mentioned the counterexample pattern, but it wasn't about the counterexample pattern.

However, getting rid of the infoboxes at this point also seems unnecessary! Somebody wanted to put them in, and it's not like they're giving false information: the displayed pattern really does have the symmetry that the infobox says it has. I don't see much likely cause of confusion in those articles' presentation of information.

Also, the articles are now back to being self-consistent: they all listed a symmetry category at the bottom of the page that matched what was in the infobox. Haycat2009's edits didn't remove those categories, which made things a bit confusing. The simplest thing to do was to undo those edits and get back to the previous self-consistent state.

So I'm not interested in making any further edits at this point, myself. Someone else can certainly feel free to do something more ambitious if they want to.

I don't support the idea to specify "kinetic symmetry" for still lives. The idea behind the word 'kinetic' in "kinetic symmetry" is incompatible with the idea of a still life.

I don't have an issue with switching between static and kinetic symmetry in infoboxes depending on whether the pattern is a still life or an oscillator. I believe this distinction is intuitively clear, useful and should be preserved, in infoboxes and elsewhere.

Clarification needed here, I think:

As I understand it, the changes Haycat2009 is proposing to make will involve switching between static and kinetic symmetry in infoboxes, in just the way that you describe in the above quote. Have you now changed your mind about whether that's a good idea?

There have been several strong objections (including yours) to the idea of reporting kinetic symmetry for still lifes -- that seemed incompatible with the idea of a still life, as you said.

It doesn't seem like there have been any strong objections to the idea of switching over to reporting static symmetry for still lifes instead.

So it's not clear to me yet that this is a controversial question at all any more. There seems to be some observable agreement here. Why wouldn't the "be bold" option be the right line of approach in this case?

It's not like it would be difficult to roll back these upcoming changes, if someone shows up with good reasons for doing that. Conversely, if there are valid objections to Haycat2009's experimental edits, then actually making those edits will improve the odds that someone will bring up those objections in this discussion.

[confocaloid]

Yes Coolout Conjecture is also affected by the same issue under discussion.

In all these cases, infoboxes are confusing and misleading.
("Pattern type: Problem" -- what that is supposed to mean? If anything, the pattern is (part of) a solution to a certain problem, but not the problem itself.
"Symmetry" -- again, the symmetry of a specific solution doesn't mean that the problem itself requires or "has" the symmetry.)

[...] The article mentioned the counterexample pattern, but it wasn't about the counterexample pattern.

However, getting rid of the infoboxes at this point also seems unnecessary! Somebody wanted to put them in, and it's not like they're giving false information: the displayed pattern really does have the symmetry that the infobox says it has. I don't see much likely cause of confusion in those articles' presentation of information. [...]

Those infoboxes are confusing, precisely because those infoboxes misrepresent an article about some topic (a problem) as if it was an article about a different topic (a specific pattern related to the problem, that isn't the problem itself).

[...]
It doesn't seem like there have been any strong objections to the idea of switching over to reporting static symmetry for still lifes instead.

So it's not clear to me yet that this is a controversial question at all any more. There seems to be some observable agreement here. Why wouldn't the "be bold" option be the right line of approach in this case?

It's not like it would be difficult to roll back these upcoming changes, if someone shows up with good reasons for doing that. Conversely, if there are valid objections to Haycat2009's experimental edits, then actually making those edits will improve the odds that someone will bring up those objections in this discussion.

"Be bold" doesn't really apply to changes that involve editing multiple pages in quick succession. That's just yet another undiscussed editing campaign, and not any kind of "experimental edits".

One of reasons why this issue is problematic (and same for a number of other issues), is because there was almost no discussion of what exactly can be done, and what exactly should be done with the affected pages.
What are the existing possibilities?
What can be done?
What would be consequences in each case?

What are the proposed changes, exactly?
What about those undiscussed changes that were already made, without seeking consensus first?

"People running overlapping/conflicting wiki editing campaigns and talking past each other" fails to solve any existing issues, and creates more and more issues to be solved by future generations of wiki editors.

I am going ahead with the plan now.

No consensus has been reached. You shouldn't be going ahead with major changes based on an ongoing conversation with no clear outcome.

I should point out that no consensus has been reached yet for adding any kind of symmetry information to infoboxes of still life patterns in the first place. Nevertheless, certain large-scale changes were already performed, before reaching any such consensus.
[...]

[dvgrn]

"Be bold" doesn't really apply to changes that involve editing multiple pages in quick succession. That's just yet another undiscussed editing campaign, and not any kind of "experimental edits".

I'm sorry, confocaloid, but this all sounds like complete nonsense to me.

"Be bold" can perfectly well apply to a pre-advertised group of specific changes. These proposed experimental edits are not in any way "undiscussed". They're perfectly in line with the discussion that has happened so far (such as it is).

Recap
muzik suggested that it was appropriate to list kinetic symmetry for still lifes. Several people (you, me, and Haycat2009) spoke up to say that "kinetic" was incompatible with the idea of a still life. So now Haycat2009 is going to make very simple experimental changes to some still-life pages, to list static symmetry instead.

Now, muzik did raise a temporary objection on August 24th -- well over a month ago -- saying that Haycat2009 should hold off because there was an ongoing discussion.

The discussion actually stopped happening right about then, with no new voices chiming in until we picked up the topic again today.

Haycat2009 has been very patient since then, but it seems pretty clear that the discussion hasn't been "ongoing" for a long time now. So muzik's objection is clearly no longer any kind of valid reason to hold off. Nobody gets to press the pause button on new ideas indefinitely, just because someone might say something new on the topic, months or years in the future.

These kinds of discussions usually follow this pattern
What happened here is a very common pattern for these kinds of discussions. Usually pretty much everybody who has anything at all to say will say it, fairly early on.

Appeals for more people to give their opinions on issues like this seem very often to go unheeded. Long story short, most people get bored fairly quickly by discussions once everyone has said what they have to say once -- and then they simply refuse to participate in any way once the discussion turns into an endless stonewalling effort.

Back to this specific case
In this case, there's been five weeks' worth of silence on the part of Everybody Else. I'm taking a guess that probably that means that nobody else is interested in saying anything. There's no need to wait around for any more months or years, while people continue to not give their opinion on this particular issue.

If my guess is wrong, then someone will likely speak up and say so -- no harm done at all, nobody has to get mad about anybody having Guessed Wrong, or Edited Things Wrong -- and in that case we would actually get to hear what somebody else thinks.

Again: in my opinion as a moderator, the "be bold" rule does apply quite nicely in this specific case of Haycat2009's very simple set of proposed edits.

[confocaloid]

[...] Long story short, most people get bored fairly quickly by discussions once everyone has said what they have to say once -- and then they simply refuse to participate in any way once the discussion turns into an endless stonewalling effort. [...]

Unfortunately, your posts here fail to address my questions and concerns, while at the same time trying to blame some unspecified subset of participants for so-called "stonewalling effort".

In particular, what are the exact proposed changes this time? This is still unanswered.

Again, "be bold" doesn't apply to large sets of unspecified and undiscussed changes.

[...] Controversial decisions need baby steps.

Controversial issues need discussion regarding what exactly needs to be done, until there is some observable agreement on what exactly can and should be done.

The edits that were already made are already problematic (see preceding posts). Making more of such edits would just create more issues, while also failing to solve existing issues.

[...]
"Be bold" doesn't really apply to changes that involve editing multiple pages in quick succession. That's just yet another undiscussed editing campaign, and not any kind of "experimental edits".
[...]
"People running overlapping/conflicting wiki editing campaigns and talking past each other" fails to solve any existing issues, and creates more and more issues to be solved by future generations of wiki editors.
[...]

[Nathaniel]

I'll throw my two cents in for a few aspects of this thread, for what it's worth.

I think re-adding "C2_4" fails to be an improvement. The topic of the article is unique father problem, which is not just a single specific pattern. The topic of this article doesn't have any specific symmetry (either static or kinetic).

I agree with this, and think that this should be fixed at the template level. Listing a specific symmetry in cases like this is (in my opinion, of course) more confusing than having "Symmetry: unspecified" appear, which is more confusing than having no symmetry information appear in the infobox at all.

In particular, what are the exact proposed changes this time? This is still unanswered.

Again, "be bold" doesn't apply to large sets of unspecified and undiscussed changes.

I don't quite agree with this, however (I know it doesn't make sense to disagree with a question, but bear with me...)

"Be bold", in my mind, means exactly that someone should feel free (and encouraged) to make both small- and large-scale changes to the wiki, as long as they are acting in good faith and are receptive to feedback when it arrives. If someone wants to make a new template, or add a new parameter to an existing template, or anything else along those lines, they should do so if they believe that will improve the wiki, even if those changes will affect a huge number of pages.

The price of this freedom to be bold is that wiki editors also need to be receptive to feedback. If people object to your large-scale changes then pause and see if a middle ground can be reached, or if edge cases (like the one involving Problem pages like the unique father problem, discussed above) can be worked around.

One downside of this approach to wiki editing is that, for example, sometimes newcomers get overly excited and start making wide-scale edits that don't really fit with the rest of LifeWiki. But that's a small price to pay for the freedom to just do. I expect that people will have a difficult time answering the "what are the exact proposed changes?" question because they just might not know. They would like symmetry information in infoboxes because, well, why not? That information can be useful to have, and having it on the wiki in a standardized way seems like a step forward. The exact implementation and details of how and that information is entered on pages, how it is displayed, exactly which templates it will be a part of, and so on -- those are good questions to ask and think about (and if someone does have an answer, of course please provide it). But in my mind those can be iterated upon and figured out alongside the "being bold".

[confocaloid]

[...] I expect that people will have a difficult time answering the "what are the exact proposed changes?" question because they just might not know. They would like symmetry information in infoboxes because, well, why not? That information can be useful to have, and having it on the wiki in a standardized way seems like a step forward. The exact implementation and details of how and that information is entered on pages, how it is displayed, exactly which templates it will be a part of, and so on -- those are good questions to ask and think about (and if someone does have an answer, of course please provide it). But in my mind those can be iterated upon and figured out alongside the "being bold".

I would prefer to use "n" rather than "C1" (and likewise for other types of symmetry that a pattern can have in a single generation), both for oscillator patterns and for still life patterns.
I think one should distinguish between "Static symmetry" and "Kinetic symmetry" in the infobox, but that doesn't imply using two different notations.
In this case, I think using the same notation is better than using two different notations.

About the recent edits by Haycat2009: https://conwaylife.com/w/index.php?targ ... tributions

• I think the single change in template:Still life (diff) may be considered an improvement, in that it does replace the displayed text with "Static symmetry" when the topic of the article is a still life.
  However, that change fails to resolve other issues directly related to this discussion (e.g. hiding the entire line when the topic of the article doesn't have any symmetry at all).
• I think the remaining linked changes by User:Haycat2009 are problematic. For example, replacing "n" by "C1" (and other similar edits) fails to reflect any kind of consensus on which of two notations should be used in this case. (Because there was no discussion of this in the first place.)
• Further, the edit summaries are insufficient to explain to current and future editors what is going on.
  (Quoting an edit summary: "Dvgrn has approved. Time to do this."
  -- does that explain anything to someone reading the edit summary? Where is a link to the relevant discussion? Indeed, was there even a discussion about this in the first place?)
  For large-scale changes such as these, I think all edit summaries need to include a link to the related discussion that explains why these edits are made.

I think these new edits by Haycat2009 should stop, until there is some common understanding of the issues and observable agreement on what to do. As it is right now, the new edits only create more problems, without actually resolving any existing issues; because there is no consensus on what can be done, what needs to be done, and what would actually resolve some existing issues.

[dvgrn]

I would prefer to use "n" rather than "C1" (and likewise for other types of symmetry that a pattern can have in a single generation), both for oscillator patterns and for still life patterns.
I think one should distinguish between "Static symmetry" and "Kinetic symmetry" in the infobox, but that doesn't imply using two different notations.
In this case, I think using the same notation is better than using two different notations.

Please explain a little more. Why do you think that?

Looking things over some more, I can see a clear reason why Haycat2009 has chosen to switch to static symmetries like "C1" for cases where "static symmetry" is displayed in the infobox. But I can't yet come up with a good justification for leaving those infoboxes linking to "n" symmetry (or the other possible kinetic symmetries). See below for details.

I think the remaining linked changes by User:Haycat2009 are problematic. For example, replacing "n" by "C1" (and other similar edits) fails to reflect any kind of consensus on which of two notations should be used in this case. (Because there was no discussion of this in the first place.)

Right, let's have that discussion. Everyone interested can please have a careful look at the changes Haycat2009 is making.

Before the recent edits, the infoboxes said things like "Kinetic symmetry n".

After the recent edits, the infoboxes say things like "Static symmetry C1".

Notice especially that if only the template improvement had been done -- so that the infoboxes say "Static symmetry" but keep the "n" or other kinetic symmetry notation -- then when someone clicks on the link, they'll end up on a category page that talks about kinetic symmetries and links to the kinetic symmetry page.

More than one person has mentioned that kinetic symmetry seems incompatible with the idea of a still life. Nobody seems to have come to the defense of applying kinetic symmetries to still lifes, since muzik's statements about the original implementation; muzik hasn't said anything here since five weeks ago.

Long story short, here has definitely been more support in recent discussions for static symmetry being associated with still lifes, than for kinetic symmetry being associated with them. Haycat2009's experimental edits are right in line with this, and they seem to me like nice clear samples of the changes Haycat2009 is proposing. Haycat2009 is now politely waiting for discussion to happen, before making any more edits. So... please discuss!

The edit war that I'm stepping in to work on here
Back on August 24, muzik undid Haycat2009's initial attempts to make these same changes -- and also added a pile of speedy-deletion tags that replaced the summary text in Haycat2009's static-symmetry category pages. I'm not sure what happened there, because the speedy-deletion edits don't seem right at all. If a speedy deletion tag is going to get added, people need to be able to see the intended page content to make a judgment about deleting it -- not a newly broken version of the page.

I'm kind of thinking those pages weren't speedy-deletable anyway, but it doesn't really matter at this point -- I've gone ahead and removed the tags and standardized the summary text.

[confocaloid]

After discussion with dvgrn, I have decided to do 20 edits about this spread throughout next week. Stay tuned, and don’t be afraid to stop me.

Haycat2009, please stop your edits for now. You have already made well over "20 edits", and there is already discussion regarding whether or not those edits are improvements.

[...]
I would prefer to use "n" rather than "C1" (and likewise for other types of symmetry that a pattern can have in a single generation), both for oscillator patterns and for still life patterns.
I think one should distinguish between "Static symmetry" and "Kinetic symmetry" in the infobox, but that doesn't imply using two different notations.
In this case, I think using the same notation is better than using two different notations.

About the recent edits by Haycat2009: https://conwaylife.com/w/index.php?targ ... tributions
[...]

[hotdogPi]

I think static objects should have static symmetries, not kinetic symmetries.

Terms like "C2" are used in this community all the time even in casual conversation, while I don't even know myself what the kinetic symmetry letters stand for.

[confocaloid]

I would prefer to use "n" rather than "C1" (and likewise for other types of symmetry that a pattern can have in a single generation), both for oscillator patterns and for still life patterns.
I think one should distinguish between "Static symmetry" and "Kinetic symmetry" in the infobox, but that doesn't imply using two different notations.
In this case, I think using the same notation is better than using two different notations.

Please explain a little more. Why do you think that?

I think it is better to use a single notation across the wiki, as opposed to using two different notations.
I think it is a more consistent and helpful choice to refer to the same source of the notation, both for single-generation symmetry types and for oscillator symmetry types.

Here is the explanation of the notation (note that it covers the 16 single-generation symmetry types separately from the 43 oscillator symmetry types):

Code: Select all

#C The 'period' of an oscillator (or spaceship) is the smallest positive
#C integer P for which generation P of the object is congruent to and in
#C the same orientation as generation 0.  The 'mod' of an oscillator (or
#C spaceship) is the smallest positive integer M for which generation M
#C of the object is congruent to generation 0, but not necessarily in the
#C same orientation.  The quotient q=P/M is always either 1, 2, or 4.  To
#C specify both P and M, we often write "period P.M" or "period P/q".
#C
#C There are 43 types of symmetry that an oscillator can have, taking into
#C account both the symmetry of a single generation and the change of
#C orientation (if any) M generations later.  There are 16 types of
#C symmetry that a pattern can have in a single generation.  Each of these
#C is given a one or two character name, as follows:
#C
#C    n   no symmetry
#C
#C    -c  mirror symmetry across a horizontal axis through cell centers
#C    -e  mirror symmetry across a horizontal axis through cell edges
#C
#C    /   mirror symmetry across one diagonal
#C
#C    .c  180 degree rotational symmetry about a cell center
#C    .e  180 degree rotational symmetry about a cell edge
#C    .k  180 degree rotational symmetry about a cell corner
#C
#C    +c  mirror symmetry across horizontal and vertical axes meeting
#C        at a cell center
#C    +e  mirror symmetry across horizontal and vertical axes meeting
#C        at a cell edge
#C    +k  mirror symmetry across horizontal and vertical axes meeting
#C        at a cell corner
#C
#C    xc  mirror symmetry across 2 diagonals meeting at a cell center
#C    xk  mirror symmetry across 2 diagonals meeting at a cell corner
#C
#C    rc  90 degree rotational symmetry about a cell center
#C    rk  90 degree rotational symmetry about a cell corner
#C
#C    *c  8-fold symmetry about a cell center
#C    *k  8-fold symmetry about a cell corner
#C
#C For a period P/1 object, specifying the symmetry of generation 0 tells
#C us all there is to know about the oscillator's symmetry.  For a period
#C P/2 or P/4 object, we also need to know how gen M is related to gen 0.
#C For the P/2 case, gen M can be either a mirror image of gen 0, a 180
#C degree rotation of it, or a 90 degree rotation of it if the pattern
#C has 180 degree rotational symmetry.  For the P/4 case gen M must be a
#C 90 degree rotation of gen 0.  In any case, if we merge all gens which
#C are multiples of M, the resulting pattern will have more symmetry than
#C the original oscillator.  We describe the complete symmetry class of
#C the oscillator by appending the one or two character description of
#C the union's symmetry to that of gen 0's symmetry.  For example, if
#C gen 0 has 180 degree rotational symmetry about a cell center, and
#C gen M is obtained by reflecting gen 0 across a diagonal, then the
#C union of gens 0 and M is symmetric across both diagonals, so its
#C symmetry class is denoted ".cxc".
#C
#C The 43 possible symmetry types are:
#C
#C    period/mod = 1:  nn    -c-c  -e-e  //    .c.c  .e.e  .k.k  +c+c
#C                     +e+e  +k+k  xcxc  xkxk  rcrc  rkrk  *c*c  *k*k
#C
#C    period/mod = 2:  n-c   n-e   n/    n.c   n.e   n.k
#C                     -c+c  -c+e  -e+e  -e+k
#C                     /xc   /xk
#C                     .c+c  .cxc  .crc  .e+e  .k+k  .kxk  .krk
#C                     +c*c  +k*k  xc*c  xk*k  rc*c  rk*k
#C
#C    period/mod = 4:  nrc   nrk

[...]

I think the remaining linked changes by User:Haycat2009 are problematic. For example, replacing "n" by "C1" (and other similar edits) fails to reflect any kind of consensus on which of two notations should be used in this case. (Because there was no discussion of this in the first place.)

[...]
Notice especially that if only the template improvement had been done -- so that the infoboxes say "Static symmetry" but keep the "n" or other kinetic symmetry notation -- then when someone clicks on the link, they'll end up on a category page that talks about kinetic symmetries and links to the kinetic symmetry page.
[...]

• By itself, the notation "n" refers to one of 16 types of symmetry that a pattern can have in a single generation. (Namely, "no symmetry". See above for the explanation of the notation.)
• For an oscillator with period P and mod M, there are 43 types of symmetry, when also taking into account the change of orientation (if any) M generations later. Those 43 types of symmetry have different names, using the same notation. (In particular, neither of those 43 types of symmetry is named "n".)
• I think the infobox in the linked change should say "Static symmetry: n", and link to Category:Strict still lifes with n symmetry.
  However, the description in that category page should be edited, to avoid incorrectly implying that "n" denotes a kinetic symmetry (see preceding points).

[Haycat2009]

Sorry for the drama - I wanted to complete the task until the ‘b’ index (as a reference point)

[dvgrn]

[*] I think the infobox in the linked change should say "Static symmetry: n", and link to Category:Strict still lifes with n symmetry.
However, the description in that category page should be edited, to avoid incorrectly implying that "n" denotes a kinetic symmetry...

Would it work to add a separate "Dean Hickerson static symmetry naming system" section to the static symmetry article? And then the various category pages -- the ones that are linked to from these infoboxes -- could point to that new section?

We do still need the current contents of the static symmetry article; Catagolue symmetry notation isn't going to go away any time soon, so it needs to be documented on the LifeWiki just as much as Dean Hickerson's static symmetries do. Seems like it might be good to have a table of equivalences -- 'n' = 'C1' and so on -- in some really obvious location.

[confocaloid]

Note that the scope of this discussion is currently wider than it was at the beginning of the discussion.

Whenever an infobox in some article is going to specify the single-generation symmetry type (of a pattern that's the topic of the article), for example in pages about still-life patterns, I think the infobox could tell directly

• both the symmetry type in Hickerson's notation,
• and the Catagolue census corresponding to that symmetry type.

For example, 'n' denotes one of 16 single-generation symmetry types (on the square grid), while 'C1' denotes one of official Catagolue censuses.

I think the part of the displayed infobox that tells the single-generation symmetry type (specified in Hickerson's notation) could be linked either to the respective wiki category collecting other pages with the same specified value, or alternatively linked directly to the page Static symmetry.

I think the part of the displayed infobox that tells the Catagolue census name corresponding to the single-generation symmetry type could be linked either to the page Catagolue, or alternatively linked directly to the Catagolue census (e.g. let 'C1' link to https://catagolue.hatsya.com/census/b3s23/C1).

The page Static symmetry#On_a_square_grid should be expanded (and probably rewritten) to emphasize and to use Hickerson's notation as the primary way of telling symmetry types across the wiki.

Wiki categories should continue to use Hickerson's notation, both for single-generation symmetry types and for oscillator symmetry types.

To save vertical space in the infobox, one could put both values in the same row, similarly to the idea quoted below:

[...] It may also be useful to merge "Volatility" and "Strict volatility" into the same row, separated horizontally as in LifeViewer, and possibly likewise for Period and Mod.

[Haycat2009]

I think that there should only be static symmetry in SL infoboxes and both static and kinetic symmetry in Oscillator/gun/spaceship/puffer/rake. The kinetic symmetry and static symmetry are the same in a still life, but not in others.

[confocaloid]

I think that there should only be static symmetry in SL infoboxes and both static and kinetic symmetry in Oscillator/gun/spaceship/puffer/rake. The kinetic symmetry and static symmetry are the same in a still life, but not in others.

• Regarding oscillator patterns, if one of 43 oscillator symmetry types is specified using Hickerson's notation, then it's redundant (unnecessary) to specify one of 16 single-generation symmetry types explicitly, because it is just a prefix of the oscillator symmetry type.
  For example "n" is just a prefix of "nn", so it suffices to say "nn" when that's the symmetry type of an oscillator.
  Likewise, ".c" is just a prefix of ".crc", so it suffices to say only ".crc" when that's the symmetry type of an oscillator.
• For still life patterns, it suffices to tell only the single-generation symmetry type. (For example "n" or ".c")
• For moving objects (spaceships, puffers, rakes), it is not even immediately clear what should be the notation, and also unclear what are all the possible values of symmetry type. I don't think there was discussion of that. (Hickerson's notation for oscillators isn't really applicable to moving patterns as defined.)

[Haycat2009]

Should I continue with adding static symmetry to SL pages?

[confocaloid]

Obviously "no". See the preceding discussion for why. Please continue to wait, until there is some actual discussion of issues at hand, and until there is some observable consensus re: what exactly can and should be done next.

In particular, Hickerson's notation should be preserved in the infoboxes (both for specifying single-generation symmetry type, and for specifying oscillator symmetry type).
Note that the notation conveniently distinguishes between the 16 single-generation symmetry types and the 43 oscillator symmetry types.

Also, it is still unclear what exactly to do with objects that are neither a still life nor an oscillator. In particular for moving objects, there is no single well-defined notation that would be understood and agreed.

Should I continue with adding static symmetry to SL pages?

The edits you already made fail to be improvements, and there was never consensus for those your edits to begin with.
It would be clearly counterproductive to continue to do more such edits.

https://conwaylife.com/w/index.php?targ ... tributions

[dvgrn]

Should I continue with adding static symmetry to SL pages?

@Haycat2009, I sent you a private message about this. Could you maybe go back and read it again?

It wouldn't make sense to just keep on doing more of what you were doing. You haven't yet said anything about what you're planning to do instead. That's going to be an important part of the continued discussion.

You added a "like" to confocaloid's explanation above, about how Dean Hickerson's system supports both static symmetry and kinetic symmetry, with different notation for each.

I added a like to that post also; confocaloid's suggestion seems like a good one --

... in pages about still-life patterns, I think the infobox could tell directly

• both the symmetry type in Hickerson's notation,
• and the Catagolue census corresponding to that symmetry type.

So ... to get this editing work back on track, the next step would be for you to say exactly what you want to do next, and how it's different from what you did with the "A" and "B" still lifes.

You were removing Hickerson-notation static symmetries like *k and putting in Catagolue-style static symmetries like D8_4, with edit summaries like "info box change to static symmetry".

But *k is already a static symmetry -- it's just in a different notation from D8_4. So it seems like it might be a good idea to keep *k in the infobox, and add D8_4 on the same line of the infobox, as confocaloid suggested. This also implies doing different things with categories from what you were doing before.

What do you think of these suggestions? Can you work on implementing them?

If so, then how about a new experimental round of adjusting the "A" still lifes according to the new plan, so everybody can see what it would look like? As Nathaniel says, there's no need to just wait around indefinitely until every detail is completely settled in advance. The LifeWiki is a wiki, not a museum -- kinetic, not static, you might say.