Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
Meta-discussion by confocaloid and me has been moved to a separate thread. It's an important topic, but it's meta-discussion -- it's not actually relevant to the discussion of further improvements to muzik's kinetic-symmetry project. Let's use _this_ thread to talk about those specific actual improvements.
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
Notes on category pages
@Haycat2009, notice how "block" is currently missing from *k symmetry page, due to your previous round of editing. Let's figure out how to get that fixed.
A lot of the category pages also currently have somewhat misleading links -- implying, e.g., that *k is a "kinetic symmetry". It really isn't a kinetic symmetry, it's just a Hickerson-notation static symmetry. I can see why it's currently set up this way. It's because the Hickerson-notation static symmetry information is all currently hiding in the "kinetic symmetry" article.
Where to put static-symmetry info
The table of equivalences that we need, showing the isomorphism between Catagolue and Hickerson symmetry notation, is already present in the kinetic symmetry article. There's just no reference to it yet in the static symmetry article.
The static symmetry article only uses Catagolue notation, which makes it look like that's the only notation that's supposed to be used for static symmetry. Seems like that was probably the source of the confusion that started this whole editing experiment.
The kinetic symmetry article currently says "contrast static symmetry" ... but then the kinetic symmetry article goes right ahead and talks about static symmetry in detail, farther down.
What do people think about finding a way to transclude the static-symmetry content from kinetic symmetry -- maybe make a separate sub-article about Hickerson-notation static symmetry, and include it in both the static-symmetry and kinetic-symmetry articles?
It seems to me that the part about Hickerson's notation being "the primary way" will come about naturally, assuming muzik's larger experiment here is successful. A good first step would be to get both notations on an equal footing -- both documented in the appropriate places.
This all seems reasonable to me. I'd slightly prefer linking *k to Category:Strict_still_lifes_with_*k_symmetry. It also seems like a good idea to mention the equivalent Catagolue static symmetry, right there on that *k category page (rather than have two competing sets of category pages for Hickerson notation and Catagolue notation, which is what we have at the moment). Similarly, I'd much rather link to a specific, relevant Catagolue census than to the general Catagolue wiki article.confocaloid wrote: ↑October 6th, 2024, 8:58 amI 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).
...
Wiki categories should continue to use Hickerson's notation, both for single-generation symmetry types and for oscillator symmetry types.
@Haycat2009, notice how "block" is currently missing from *k symmetry page, due to your previous round of editing. Let's figure out how to get that fixed.
A lot of the category pages also currently have somewhat misleading links -- implying, e.g., that *k is a "kinetic symmetry". It really isn't a kinetic symmetry, it's just a Hickerson-notation static symmetry. I can see why it's currently set up this way. It's because the Hickerson-notation static symmetry information is all currently hiding in the "kinetic symmetry" article.
Where to put static-symmetry info
The table of equivalences that we need, showing the isomorphism between Catagolue and Hickerson symmetry notation, is already present in the kinetic symmetry article. There's just no reference to it yet in the static symmetry article.
The static symmetry article only uses Catagolue notation, which makes it look like that's the only notation that's supposed to be used for static symmetry. Seems like that was probably the source of the confusion that started this whole editing experiment.
The kinetic symmetry article currently says "contrast static symmetry" ... but then the kinetic symmetry article goes right ahead and talks about static symmetry in detail, farther down.
What do people think about finding a way to transclude the static-symmetry content from kinetic symmetry -- maybe make a separate sub-article about Hickerson-notation static symmetry, and include it in both the static-symmetry and kinetic-symmetry articles?
I mostly agree with this -- Hickerson's notation needs to be documented on the static-symmetry page, along with Catagolue notation.confocaloid wrote: ↑October 6th, 2024, 8:58 amThe 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.
It seems to me that the part about Hickerson's notation being "the primary way" will come about naturally, assuming muzik's larger experiment here is successful. A good first step would be to get both notations on an equal footing -- both documented in the appropriate places.
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
Evidently consensus appears to be pointing to describing still lifes with static symmetries, which I'm fine with at this point, but there doesn't seem to be much agreement on whether we should use Hickerson notation or Goucher notation. Has this been decided yet, and if not, is this being discussed elsewhere?
Parity Replicator Collection v1.6 is now live - please send all relevant discoveries here.
- confocaloid
- Posts: 5479
- Joined: February 8th, 2022, 3:15 pm
- Location: learn to protect yourself against stray gliders and sparks and self-destruct mechanisms
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
This was discussed in the last two pages in this thread. Please read the preceding discussion.muzik wrote: ↑November 28th, 2024, 9:18 amEvidently consensus appears to be pointing to describing still lifes with static symmetries, which I'm fine with at this point, but there doesn't seem to be much agreement on whether we should use Hickerson notation or Goucher notation. Has this been decided yet, and if not, is this being discussed elsewhere?
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
Also note that spaceships are not covered, and there does not seem to be any existing source that would clearly and consistently define a notation applicable to spaceships. (Let alone a consensus for any such notation.)
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
-- Okay, I'm starting to pick away at the broken "B" strict still lifes, from the attempt at improving static-symmetry designations back in October. I've heard from Haycat2009 via PM that Haycat probably won't be picking this project back up, though I haven't managed to elicit any public statements to that effect yet.
Here's a sample of the change I'm currently thinking of trying:
1) I'd like to adjust the symmetry parameter in the Barge article from "D4_x4" to "xk (D4_x4)", so that we're prioritizing Hickerson notation a little bit but still putting Catagolue notation on the same line and making it almost equally prominent.
I've done that same kind of substitution with the diagram in the [[static symmetry]] article, and I've swapped the order of the Hickerson-notation and Catagolue-notation entries in the table of equivalent static symmetries.
2) I'd like to change the category page that will now be linked to by the "xk (D4_x4)" entry. It would now be called "Category:Strict still lifes with xk (D4_x4) symmetry"
4) All the "B" strict still lifes currently have "Strict still lifes with [?] symmetry" redlinks at the bottom, I think. So the "B" SL articles seem like good targets to tackle first. My plan would be to make changes equivalent to #1, #2, and maybe #3 above, for each of the "B" SL articles and their associated categories.
5) If we rename those categories and fix the "B" SL articles to match, that will create redlinks in all of the non-"B" strict still life articles. It'd probably be good to fix those remaining articles relatively quickly, once we look at the "B" articles for a day or three and make sure there aren't any other minor changes that will have to be made in the actual articles.
However, if we go with simple strings like "xk (D4_x4)" for the symmetry parameter -- rather than adding separate hickerson_symmetry and catagolue_symmetry params, for example -- then all that has to be done in the strict still life articles is to add the correct Hickerson symmetry to the symmetry param in the "B" articles, and put the equivalent Catagolue symmetry in parentheses in all of the articles. All the other adjustments are changes to the various category pages, and there aren't all that many of those.
Advice and suggestions are welcome as usual -- thanks in advance!
Here's a sample of the change I'm currently thinking of trying:
1) I'd like to adjust the symmetry parameter in the Barge article from "D4_x4" to "xk (D4_x4)", so that we're prioritizing Hickerson notation a little bit but still putting Catagolue notation on the same line and making it almost equally prominent.
I've done that same kind of substitution with the diagram in the [[static symmetry]] article, and I've swapped the order of the Hickerson-notation and Catagolue-notation entries in the table of equivalent static symmetries.
2) I'd like to change the category page that will now be linked to by the "xk (D4_x4)" entry. It would now be called "Category:Strict still lifes with xk (D4_x4) symmetry"
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" ?{{CategoryTools}}
This category contains all notable [[strict still life]]s that have [[static symmetry]] ''n'' in Hickerson's notation, equivalent to Catagolue's 'D4_x4' symmetry.
For more information see the "Still lifes" section of the [[Kinetic_symmetry#Still_lifes|kinetic symmetry]] article.
[[Category:Patterns with D4_x4 symmetry]]
4) All the "B" strict still lifes currently have "Strict still lifes with [?] symmetry" redlinks at the bottom, I think. So the "B" SL articles seem like good targets to tackle first. My plan would be to make changes equivalent to #1, #2, and maybe #3 above, for each of the "B" SL articles and their associated categories.
5) If we rename those categories and fix the "B" SL articles to match, that will create redlinks in all of the non-"B" strict still life articles. It'd probably be good to fix those remaining articles relatively quickly, once we look at the "B" articles for a day or three and make sure there aren't any other minor changes that will have to be made in the actual articles.
However, if we go with simple strings like "xk (D4_x4)" for the symmetry parameter -- rather than adding separate hickerson_symmetry and catagolue_symmetry params, for example -- then all that has to be done in the strict still life articles is to add the correct Hickerson symmetry to the symmetry param in the "B" articles, and put the equivalent Catagolue symmetry in parentheses in all of the articles. All the other adjustments are changes to the various category pages, and there aren't all that many of those.
Advice and suggestions are welcome as usual -- thanks in advance!
- confocaloid
- Posts: 5479
- Joined: February 8th, 2022, 3:15 pm
- Location: learn to protect yourself against stray gliders and sparks and self-destruct mechanisms
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
If I remember correctly, there is a way to implement a mapping between two (reasonably small) sets of character strings as a MediaWiki template.dvgrn wrote: ↑January 13th, 2025, 11:11 pm[...]
1) I'd like to adjust the symmetry parameter in the Barge article from "D4_x4" to "xk (D4_x4)", so that we're prioritizing Hickerson notation a little bit but still putting Catagolue notation on the same line and making it almost equally prominent.
[...]
One could have a helper template mapping various ways to specify a single-generation symmetry type into the correct displayed format.
For example, if the user specifies "xk" then the helper template would automatically map that to "xk (D4_x4)".
And if the user specifies "D4_x4" then the helper template would also automatically map that to "xk (D4_x4)".
And if the user specifies "xk (D4_x4)" then that is left unchanged and mapped into "xk (D4_x4)".
Then it would suffice to adjust the infobox templates to use the helper template to map the user-provided parameter value into the correct displayed format for a single-generation symmetry type.
After that, further changes (if deemed necessary) would be simplified to editing just the helper template.
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
Hmm. That would certainly make the current editing problem easier -- in the sense that we wouldn't have to change any of the current still life pages.
It does seem like it would be nice to have one primary symmetry format, though. Dean Hickerson's format currently seems like the best candidate. At least, it's more compact and more comprehensive -- applies to more object types ... oscillators, at least, and the writeup seems to apply it to spaceships. It seems like applying to spaceships does work -- e.g. "n-c" for LWSS, since it's true that an LWSS "...appears flipped across an orthogonal line during (period/2)", and the line of symmetry "... passes through cell centers and edges".
So let's have the standard be that it's the Hickerson-format symmetry that's supposed to go into the "symmetry" param -- as muzik has been doing.
I think that means I should go through and bump all of the "B" strict still lifes back to Hickerson format, just as a starting point -- get everything into the same format.
Then I might try to get a version of the template figured out that's just a bit simpler. Maybe it won't have to deal with Catagolue-symmetry inputs -- it can just take, e.g., "n" as an input and spit out "n (C1)" for display purposes.
It does seem like it would be nice to have one primary symmetry format, though. Dean Hickerson's format currently seems like the best candidate. At least, it's more compact and more comprehensive -- applies to more object types ... oscillators, at least, and the writeup seems to apply it to spaceships. It seems like applying to spaceships does work -- e.g. "n-c" for LWSS, since it's true that an LWSS "...appears flipped across an orthogonal line during (period/2)", and the line of symmetry "... passes through cell centers and edges".
So let's have the standard be that it's the Hickerson-format symmetry that's supposed to go into the "symmetry" param -- as muzik has been doing.
I think that means I should go through and bump all of the "B" strict still lifes back to Hickerson format, just as a starting point -- get everything into the same format.
Then I might try to get a version of the template figured out that's just a bit simpler. Maybe it won't have to deal with Catagolue-symmetry inputs -- it can just take, e.g., "n" as an input and spit out "n (C1)" for display purposes.
- confocaloid
- Posts: 5479
- Joined: February 8th, 2022, 3:15 pm
- Location: learn to protect yourself against stray gliders and sparks and self-destruct mechanisms
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
confocaloid wrote: ↑November 28th, 2024, 9:25 am[...]
Also note that spaceships are not covered, and there does not seem to be any existing source that would clearly and consistently define a notation applicable to spaceships. (Let alone a consensus for any such notation.)
I don't remember seeing anywhere a clear explanation that would define the notation (and the symmetry types themselves) for spaceships.
The original notation by Hickerson is only defined for oscillators and still-life patterns.
For example, look at the MWSS. The single generation is asymmetric. The envelope (the union of all generations past, current and future) has some symmetries, including horizontal translation by 2n cells, 180-degree rotation around a cell edge midpoint, reflection in a vertical mirror passing through a cell edge midpoint.
Code: Select all
x = 40, y = 7, rule = LifeHistory
2.B.B.B.B.B.B.B.A.B.B.B.B.B.B.B.B.B.B$B.12BA3BA20B$2.17BA20B$14BA4BA
20B$.14B5A20B$.37B$3.B.B.B.B.B.B.B.B.B.B.B.B.B.B.B.B.B!
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
See Kinetic_symmetry#Spaceships.confocaloid wrote: ↑January 16th, 2025, 1:08 amI don't remember seeing anywhere a clear explanation that would define the notation (and the symmetry types themselves) for spaceships.
Your quote from Hickerson's definitions mentions spaceships twice. It seems like the notation was originally intended to apply to spaceships, and it seems like it can in fact be applied to spaceships.confocaloid wrote: ↑January 16th, 2025, 1:08 amThe original notation by Hickerson is only defined for oscillators and still-life patterns.
In any case, all kinds of spaceships -- the *WSSes, spider, seal, Sir Robin, etc. -- already have Hickerson-notation symmetries listed in their LifeWiki articles. If there's something inconsistent about those existing symmetry classifications, please point out the problem.
- confocaloid
- Posts: 5479
- Joined: February 8th, 2022, 3:15 pm
- Location: learn to protect yourself against stray gliders and sparks and self-destruct mechanisms
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
As far as I can tell, that page fails to define each possible symmetry type for spaceships, and fails to explain all possible ways how a single-generation symmetry type can combine with a "spaceship symmetry type".dvgrn wrote: ↑January 16th, 2025, 1:32 amSee Kinetic_symmetry#Spaceships.confocaloid wrote: ↑January 16th, 2025, 1:08 amI don't remember seeing anywhere a clear explanation that would define the notation (and the symmetry types themselves) for spaceships.
Again, the original notation was only defined for oscillators, in the context of an oscillator stamp collection.dvgrn wrote: ↑January 16th, 2025, 1:32 am[...]
Your quote from Hickerson's definitions mentions spaceships twice. It seems like the notation was originally intended to apply to spaceships, and it seems like it can in fact be applied to spaceships.confocaloid wrote: ↑January 16th, 2025, 1:08 amThe original notation by Hickerson is only defined for oscillators and still-life patterns.
In any case, all kinds of spaceships -- the *WSSes, spider, seal, Sir Robin, etc. -- already have Hickerson-notation symmetries listed in their LifeWiki articles. If there's something inconsistent about those existing symmetry classifications, please point out the problem.
The mentions of spaceships there are accidental, and have to do with definitions of the period and the mod; both the period and the mod are indeed well-defined for spaceships.
However, the symmetry types aren't defined for spaceships. There are no "Hickerson-notation symmetries" for spaceships in existence. That's going to be a different notation (possibly an extension) and it was not defined yet.
The problem is lack of a clear unambiguous written definition for spaceships (comparable to that for oscillators) with evidence of agreement that it makes sense and can be used. Infoboxes make claims about "symmetry" of spaceships, but those claims are currently ill-defined and unreliable.
That's technically incorrect. It is false that "an LWSS appears flipped across an orthogonal line during (period/2)". The reason is that an LWSS is a spaceship, and as such it never reappears flipped; some spaceships (including LWSS) appear translated-and-flipped, though.
To my knowledge, the specific details of all the possibilities how a single-generation symmetry type might combine with a "spaceship symmetry type" (and definitions of the symmetry types themselves) were never written clearly and explicitly. That means spaceship symmetry types aren't defined (and shouldn't really be used, until there is a clear agreed written definition, comparable to that for oscillators).
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
So... how would you suggest extending the list of eight symmetry types given on that page, if it's not a complete list already?confocaloid wrote: ↑January 16th, 2025, 2:07 amAs far as I can tell, that page fails to define each possible symmetry type for spaceships, and fails to explain all possible ways how a single-generation symmetry type can combine with a "spaceship symmetry type".
Can you give an example of another possible way for a CA spaceship to have kinetic symmetry, that is not represented by one of the eight types on that list? Or what should be added to the explanation?
- confocaloid
- Posts: 5479
- Joined: February 8th, 2022, 3:15 pm
- Location: learn to protect yourself against stray gliders and sparks and self-destruct mechanisms
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
The problem is that there are no clear written definitions of what exactly those list items mean, how they are supposed to be interpreted, what are all the possible combinations. There is no clear written definition of the complete set of all the possible spaceship symmetry types (that I know of). There is also no clear written definition of a notation to refer to those symmetry types.dvgrn wrote: ↑January 16th, 2025, 2:55 amSo... how would you suggest extending the list of eight symmetry types given on that page, if it's not a complete list already?confocaloid wrote: ↑January 16th, 2025, 2:07 amAs far as I can tell, that page fails to define each possible symmetry type for spaceships, and fails to explain all possible ways how a single-generation symmetry type can combine with a "spaceship symmetry type".
[...]
It's not about pointing out flaws in something that already existed, instead, it's about impossibility of using (or having a discussion about) something that isn't even defined yet to begin with.
In particular Hickerson's notation doesn't cover spaceships. Hickerson's notation applies only to oscillators and still-life patterns.
(The notation for single-generation symmetry types can be applied to arbitrary finite patterns, but that obviously isn't specific to either oscillators or spaceships.)
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
If you want those clear written definitions to exist according to your standards, wouldn't it make sense for you to write them?confocaloid wrote: ↑January 16th, 2025, 3:01 amThe problem is that there are no clear written definitions of what exactly those list items mean, how they are supposed to be interpreted, what are all the possible combinations. There is no clear written definition of the complete set of all the possible spaceship symmetry types (that I know of). There is also no clear written definition of a notation to refer to those symmetry types.
The Kinetic_symmetry#Spaceships page makes a pretty clear statement that the symmetry types for spaceships are limited to eight. There are spaceships listed on the LifeWiki with n, -c, -e, /, n-c, n-e, n/, and n/e symmetries.
I'll add the links to those category pages to the "Spaceships" section. Having lots of good examples of each category seems like a fine place to start; it should make it fairly easy to write out text descriptions of each category.
- confocaloid
- Posts: 5479
- Joined: February 8th, 2022, 3:15 pm
- Location: learn to protect yourself against stray gliders and sparks and self-destruct mechanisms
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
The burden of definition is on whoever is proposing the new notation.dvgrn wrote: ↑January 16th, 2025, 3:27 amIf you want those clear written definitions to exist according to your standards, wouldn't it make sense for you to write them?confocaloid wrote: ↑January 16th, 2025, 3:01 amThe problem is that there are no clear written definitions of what exactly those list items mean, how they are supposed to be interpreted, what are all the possible combinations. There is no clear written definition of the complete set of all the possible spaceship symmetry types (that I know of). There is also no clear written definition of a notation to refer to those symmetry types.
[...]
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.)
(Those ill-defined claims might or might not end up staying in the infoboxes, but that's a social problem, not a mathematical one.)
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
... Sure, but the burden of clarity is likely to fall on whoever thinks the current definitions are unclear.confocaloid wrote: ↑January 16th, 2025, 3:31 amThe burden of definition is on whoever is proposing the new notation.
I haven't looked at these definitions for very long, so I can't say with absolute certaintly that they're complete or consistent. But I can see that quite a lot of thought has been put into them, and I can interpret each of the eight categories by using the same definitions used for those same symbols elsewhere in Hickerson's notation.
That makes them fairly clear already, to me. I'm sure the clarity can be improved further, but it's really hard for me to guess what exactly you're going to think is acceptable.
I think the only claim that you've made so far that anything is incorrect is this:
You seem to be saying that "translated-and-flipped" is not a proper subset of "flipped" -- which I guess is why you put the dashes in "translated-and-flipped". Otherwise, "translated and flipped" definitely is a proper subset of "flipped", just by basic logic -- and I'm not clear why you want to add the dashes. Seems like that makes everything a lot more complicated than it needs to be.confocaloid wrote: ↑January 16th, 2025, 2:07 amThat's technically incorrect. It is false that "an LWSS appears flipped across an orthogonal line during (period/2)". The reason is that an LWSS is a spaceship, and as such it never reappears flipped; some spaceships (including LWSS) appear translated-and-flipped, though.
Why not just allow for a slightly more flexible interpretation, in the context of spaceships? 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".
- confocaloid
- Posts: 5479
- Joined: February 8th, 2022, 3:15 pm
- Location: learn to protect yourself against stray gliders and sparks and self-destruct mechanisms
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
It is obvious that an LWSS never "appears flipped".dvgrn wrote: ↑January 16th, 2025, 4:01 am[...] 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".
(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.)
Again, the issue with "spaceship symmetry types" is that, as far as I can tell, they were never ever defined anywhere, as a complete set such that exactly one element of the set applies to every possible spaceship on the square tiling.
Since the "spaceship symmetry types" were never defined, obviously any notation for them was never defined either.
That means that spaceship infoboxes are currently misleading. Either someone who is interested in pushing forward this idea should write down a definition of "spaceship symmetry types", or the "symmetry" line should be removed from all spaceship infoboxes because it is ill-defined and misleading.
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
I think you're trying to limit the definition of "appears flipped" in a way that doesn't match the way people commonly understand the phrase. Speaking for myself -- your proof by contradiction doesn't work for me at all, because I don't accept one of your premises.confocaloid wrote: ↑January 16th, 2025, 4:15 amIt 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.)
The underlying issue is addressed in the kinetic symmetry article, with this sentence:
"Flipper" is not a newly invented use of the term by any means. It is the first definition in Nathaniel's 2009 original article on types of spaceships. As far back as the early 1990s "flipper" was commonly used to refer to spaceships that flip while translating. There's just no way that all of those people would have routinely called spaceships "flippers", if they thought that it was obvious that spaceships can never "appear flipped".The term "flipper" is also sometimes used for these spaceships; both are interchangeable, as any glide symmetric spaceship is a flipper and any spaceship which is a flipper is glide symmetric.
Now, in the last few years since you joined the forums, I think "flipper" has been used almost exclusively for oscillators -- with one spaceship-related false positive having to do with the two flipper-like back parts of a walrus (!). But the LifeWiki currently documents a broader implied definition of "flipped" than the one you're implicitly proposing here.
Another related use of "flip" is the older standard terminology for Herschel conduits. See the table under "Herschel" in the Life Lexicon, for example.
The exact same premises that you're using in your attempted proof by contradiction would imply that an output Herschel never "appears flipped" (except in hypothetical Herschel-hassling oscillators, where the Herschel reappears flipped with zero translation). But the term "flip" has been used in the context of Herschels and other conduit signal types for a long time, with nobody ever complaining that it's technically incorrect.
Please don't try to keep claiming that it's technically incorrect or false, that "an LWSS appears flipped across an orthogonal line during (period/2)".
- confocaloid
- Posts: 5479
- Joined: February 8th, 2022, 3:15 pm
- Location: learn to protect yourself against stray gliders and sparks and self-destruct mechanisms
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
I think the page kinetic symmetry fails to address the actual underlying issue. It introduces two "related terms" and claims (diff) that "both are interchangeable", without ever linking to any sources to substantiate that claim, and without explaining the need for different terms.dvgrn wrote: ↑January 16th, 2025, 11:58 am[...]
The underlying issue is addressed in the kinetic symmetry article, with this sentence:
[...]The term "flipper" is also sometimes used for these spaceships; both are interchangeable, as any glide symmetric spaceship is a flipper and any spaceship which is a flipper is glide symmetric.
(Side note, "A flipper can refer to any oscillator..." is awkward. A flipper cannot "refer to" any oscillator; a flipper is an oscillator.
The page is supposed to focus on the underlying ideas, instead of terminology.)
I think the assertion about interchangeability is incorrect. The term "flipper" applies to oscillators, which indeed can flip in place without moving.
However, applying it to spaceships is confusing. Spaceships can be glide symmetric, that's a clear and correct description.
Those are different terms, referring to different underlying ideas. They aren't freely interchangeable, despite the claim in the current revision of the wiki page.
No they wouldn't imply that. Herschels aren't spaceships; they don't move by themselves and don't have any inherent direction of movement by themselves.dvgrn wrote: ↑January 16th, 2025, 11:58 am[...] The exact same premises that you're using in your attempted proof by contradiction would imply that an output Herschel never "appears flipped" (except in hypothetical Herschel-hassling oscillators, where the Herschel reappears flipped with zero translation). [...]
(The same applies to most other active objects appearing as inputs and outputs of conduits, with the exception of those conduits that actually accept or produce spaceships.)
The questions asked in the context of Herschel tracks are different from the questions asked in the context of classifying spaceship symmetry types. That's a different topic.
(In particular, for Herschels defining the "output orientation" ignores translations entirely. A conduit that translates a Herschel "backwards" relative to its "expected movement" (with expectations derived from common experience of how R/B/H tends to move) but preserves its orientation would still be labelled "F".
In contrast, for spaceships, the symmetry types need to take into account the translation too. The translations cannot be ignored here.)
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
Well, I guess that I can only offer to review any candidate new versions of that page that you want to try writing. I'll be happy to update the page if I think that your suggested changes are improvements. Presumably the same will be true for anyone else reviewing this thread.confocaloid wrote: ↑January 16th, 2025, 1:32 pmI think the page kinetic symmetry fails to address the actual underlying issue. It introduces two "related terms" and claims (diff) that "both are interchangeable", without ever linking to any sources to substantiate that claim, and without explaining the need for different terms.
Fair warning, though, I definitely won't think it's an improvement if you write anything like "It is obvious that an LWSS never appears flipped". It's completely valid for spaceships to be referred to as flippers. The reason that several categories of spaceships are called flippers is that they reappear in flipped form, with some translation, halfway through their period. So it has absolutely not been obvious to a large number of people over a span of more than thirty years now, that "an LWSS never appears flipped."
That's perfectly true, though that awkward sentence was also perfectly understandable. The intention was presumablyconfocaloid wrote: ↑January 16th, 2025, 1:32 pm(Side note, "A flipper can refer to any oscillator..." is awkward. A flipper cannot "refer to" any oscillator; a flipper is an oscillator.
'Flipper' can refer to any oscillator ..."
but people don't always get that kind of use/mention distinction perfect on the first attempt, and in this case the idea comes across reasonably well. I'll fix it now since you mentioned it... EDIT I see "flipper" was boldfaced in the article; it's fairly common practice to use that kind of emphasis instead of quote marks in LifeWiki article definitions, to signify we're on the "mention" side of the use/mention distinction. I've put in the quote marks for this case, but I'd be perfectly happy if someone thought they looked silly and non-standard, and took them out again.
Another fair warning: I'm not aware of a single community member other than you, who constantly tries to insist that the LifeWiki should focus on underlying ideas instead of terminology (emphasis mine). The LifeWiki has always focused on terminology as well as underlying ideas; the ideas are precisely what the terminology is supposed to help explain. I'm reasonably sure that that general balancing act between terminology and ideas on the LifeWiki is not going to change any time soon.confocaloid wrote: ↑January 16th, 2025, 1:32 pmThe page is supposed to focus on the underlying ideas, instead of terminology.
So I'm personally likely to take a very dim view of any argument you make that depends on the premise that the LifeWiki "is supposed to focus on the underlying ideas, instead of terminology" (emphasis mine again).
If you want to suggest improvements to this kinetic symmetry article, please consider trying some other argument besides that one.
- confocaloid
- Posts: 5479
- Joined: February 8th, 2022, 3:15 pm
- Location: learn to protect yourself against stray gliders and sparks and self-destruct mechanisms
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
I think I essentially replied to that in part of the previous post. I don't buy that claim of "interchangeability" added to the wiki page. The terms have different meanings, and it is confusing to claim they are interchangeable.
confocaloid wrote: ↑January 16th, 2025, 1:32 pm[...]
I think the assertion about interchangeability is incorrect. The term "flipper" applies to oscillators, which indeed can flip in place without moving.
However, applying it to spaceships is confusing. Spaceships can be glide symmetric, that's a clear and correct description.
Those are different terms, referring to different underlying ideas. They aren't freely interchangeable, despite the claim in the current revision of the wiki page.
[...]
In this particular case, the awkward phrasing "A flipper can refer to any oscillator..." is part of what undermines the explanations of the topic of the page. A reader has to stop and think (is a flipper a type of term? Terms can refer to things; claiming that a flipper can refer to something suggests that it must be some sort of a term; but that isn't the case, a flipper isn't a term, a flipper is an oscillator.)dvgrn wrote: ↑January 16th, 2025, 3:07 pm[...]Another fair warning: I'm not aware of a single community member other than you, who constantly tries to insist that the LifeWiki should exclusively focus on underlying ideas. The LifeWiki has always focused on terminology as well as underlying ideas; the ideas are precisely what the terminology is supposed to explain.confocaloid wrote: ↑January 16th, 2025, 1:32 pmThe page is supposed to focus on the underlying ideas, instead of terminology.
[...]
This may be relatively minor compared to other issues about the page in question, but it remains a problem.
In general, I believe I already explained very many times my position on this issue, in various disagreements on the terminology. LifeWIki is supposed to focus on the knowledge, the underlying ideas. The primary target is explaining the ideas and the knowledge. Obviously one needs to use terminology to explain those ideas. However, the terminology is secondary.
When bad terminology (or, worse, local informal jargon misrepresented as if it was agreed consistent terminology) undermines explanation of ideas, the terminology needs to be changed or avoided entirely. Many uses of jargon are unnecessary and distracting.
When a page focuses on the terminology and fails to explain the ideas, it's very likely that the page needs a rewrite. LifeWiki aims to explain the knowledge, rather than the jargon.
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
As I was reading Kinetic symmetry, this sentence seems weird:
The later table lists 27 oscillator symmetries, so should that first "16" be a "27"?As such, oscillators can only have 16 of the possible 43 kinetic symmetry types, which therefore corresponds with the 16 different static symmetry types.
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
Great point. No, not quite -- changing "16" to "27" wouldn't fix the problem.Chris857 wrote: ↑January 16th, 2025, 3:39 pmAs I was reading Kinetic symmetry, this sentence seems weird:The later table lists 27 oscillator symmetries, so should that first "16" be a "27"?As such, oscillators can only have 16 of the possible 43 kinetic symmetry types, which therefore corresponds with the 16 different static symmetry types.
That "16" is trying to say something true and important ... we just need to figure out how to say it a little more clearly!
I'm going to start by fixing up the second column in that table of 27 symmetries, to mention both Hickerson notation and Catagolue notation. I think that will make the intended meaning a little clearer.
That second column does in fact contain 16 static symmetry types -- which are the 16 possible prefixes of the 27 oscillator symmetry types.
(More soon.)
- confocaloid
- Posts: 5479
- Joined: February 8th, 2022, 3:15 pm
- Location: learn to protect yourself against stray gliders and sparks and self-destruct mechanisms
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
I'm thinking that it would be a reasonable guess that the author of that part meant to say "still life" instead of "oscillator" but got sidetracked, but probably it would be better to wait for the author of that sentence to comment on this.Chris857 wrote: ↑January 16th, 2025, 3:39 pmAs I was reading Kinetic symmetry, this sentence seems weird:The later table lists 27 oscillator symmetries, so should that first "16" be a "27"?As such, oscillators can only have 16 of the possible 43 kinetic symmetry types, which therefore corresponds with the 16 different static symmetry types.
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.
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
In this edit, the Hickerson notation has been included in column 2 and column 3 of the table we're talking about.
Now it's possible to see pretty easily that the 27 oscillator symmetries in Hickerson notation in Column 1, "Name" ... always start with the Hickerson-notation "Static symmetry" in column 2. The "Composite symmetry" Hickerson notation from Column 3 is appended to that to make the complete "Name".
It would be true to say that "oscillators can only have 16 of the 43 possible kinetic symmetry types in the prefix part of their designation"... but that might be an unnecessarily complicated way to introduce oscillators! EDIT: ... And it's only sort of true anyway. Only 13 of the 16 static-symmetry prefixes show up in the list of 27. That's because any oscillator where one phase is +e, *c, or *k will just be a plain +e, *c, or *k oscillator -- right? Can't get any different symmetry by adding the other phases...
That said, there's definitely a disconnect in the wording. The sentence following the questionable sentence is
"The symmetry class is the symmetry class of the oscillator in a single generation followed by the symmetry class of the union of the generation and its congruent successors."
That's definitely talking about oscillators -- and it's saying exactly what I've explained above, which is also exactly what confocaloid explained on this thread a long time ago! The (very minor) problem is that if we only replace "oscillator" with "still life" in the previous sentence, then we break that following sentence. So we have to fix both sentences.
I've put in a trial fix. Is it more understandable now? What else still needs to be improved?
-------------------------------------------------
Also, going back to an earlier question... here's a revised example of how I'm currently planning to adjust the strict still life category pages -- this example is for Category:Strict_still_lifes_with_xk_symmetry:
The current content is{{CategoryTools}}
This category contains all notable [[strict still life]]s that have [[static symmetry]] ''xk'' in Hickerson's notation, equivalent to Catagolue's 'D4_x4' symmetry.
For more information see the "Still lifes" section of the [[Kinetic_symmetry#Still_lifes|kinetic symmetry]] article.
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?{{CategoryTools}}
This category contains all notable [[strict still life]]s with the [[kinetic symmetry]] ''xk'' - see the kinetic symmetry page for more information.
[[Category:Patterns with D4_x4 symmetry]]
- confocaloid
- Posts: 5479
- Joined: February 8th, 2022, 3:15 pm
- Location: learn to protect yourself against stray gliders and sparks and self-destruct mechanisms
Re: Adding symmetry types to infoboxes [LifeWiki Discussion; infoboxes]
There are 43 oscillator symmetry types. In Hickerson's notation, each of those 43 types is denoted in a two-part way, "... by appending the one or two character description of the union's symmetry to that of gen 0's symmetry."dvgrn wrote: ↑January 16th, 2025, 6:14 pm[...] the 27 oscillator symmetries in Hickerson notation in Column 1, "Name" ... always start with the Hickerson-notation "Static symmetry" in column 2. The "Composite symmetry" Hickerson notation from Column 3 is appended to that to make the complete "Name". [...]
16 out of those oscillator symmetry types consist of two identical parts (as in "xkxk").
The remaining (27 = 43 - 16) oscillator symmetry types consist of two different parts (as in "-c+e" or "nrk").
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.
DRH/stamps.html wrote: [...] In any case, if we merge all gens which are multiples of M, the resulting pattern will have more symmetry than the original oscillator. We describe the complete symmetry class of the oscillator by appending the one or two character description of the union's symmetry to that of gen 0's symmetry. For example, if gen 0 has 180 degree rotational symmetry about a cell center, and gen M is obtained by reflecting gen 0 across a diagonal, then the union of gens 0 and M is symmetric across both diagonals, so its symmetry class is denoted ".cxc".
The 43 possible symmetry types are:Code: Select all
#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
127:1 B3/S234c User:Confocal/R (isotropic CA, incomplete)
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.
Unlikely events happen.
My silence does not imply agreement, nor indifference. If I disagreed with something in the past, then please do not construe my silence as something that could change that.