Reviewing Special:RecentChanges

[hth3]

https://conwaylife.com/w/index.php?titl ... did=130418
The recent edit lacks any edit summary/explanation.
As far as I know there are no hard-and-fast guidelines for such choices, but the situation with such back-and-forth changes is problematic.

For the record, I would prefer to revert back to the 14-bit catalyst for reasons mentioned in viewtopic.php?p=152467#p152467 while keeping the change in the glider's initial position.

New version of the file:

Code: Select all

#C https://conwaylife.com/w/index.php?title=RLE:P822hdreflector&oldid=159746
x = 19, y = 20, rule = B3/S23
14b2o$bo12bo$2bo9bobo$3o9b2o4$11b2o$11b2o3b2o$15bo2bo2$14bo$b2o11bo2b
o$bo5b2o3b2ob2o$2b3o2b2o3b3o$4bo8bo$2b2o$2bo$3bo8b2o$2b2o8b2o!

Previous version of the file:

Code: Select all

#C https://conwaylife.com/w/index.php?title=RLE:P822hdreflector&oldid=130418
x = 19, y = 20, rule = B3/S23
14b2o$14bo$obo9bobo$b2o9b2o$bo3$11b2o$11b2o3b2o$15bo2bo2$14bo$b2o11bo
2bo$bo5b2o3b2ob2o$2b3o2b2o3b3o$4bo8bo$2b2o$2bo$obo9b2o$2o10b2o!

Earlier version before that:

Code: Select all

#C https://conwaylife.com/w/index.php?title=RLE:P822hdreflector&oldid=113632
x = 19, y = 20, rule = B3/S23
14b2o$14bo$obo9bobo$b2o9b2o$bo3$11b2o$11b2o3b2o$15bo2bo2$14bo$b2o11bo
2bo$bo5b2o3b2ob2o$2b3o2b2o3b3o$4bo8bo$2b2o$2bo$3bo8b2o$2b2o8b2o!

The new version is smaller.

[confocaloid]

Please trim the long quote. Forum rule 3d says "... only quote text that is actually relevant to your post ..." viewtopic.php?f=3&t=2092

[extremely long quote]
The new version is smaller.

Also, please read the post you are replying to. I already covered that. Quoting the relevant part (emphasis added):

https://conwaylife.com/w/index.php?titl ... did=130418
The recent edit lacks any edit summary/explanation.
As far as I know there are no hard-and-fast guidelines for such choices, but the situation with such back-and-forth changes is problematic.

For the record, I would prefer to revert back to the 14-bit catalyst for reasons mentioned in viewtopic.php?p=152467#p152467 while keeping the change in the glider's initial position. [...]

[confocaloid]

The edit https://conwaylife.com/w/index.php?titl ... did=159676 adds some kind of obscure notation. To my knowledge, the added notation was never defined anywhere. Before trying to add it, it would be much more productive to write down a clear definition and make sure that it can be read, can be understood by readers and makes sense as a definition.

I suggest to remove the gibberish. (The same should be done with any other newly coined notations or jargon, and should be covered by LW:NB)

[2,1],[1,0] ((1,0;1)-(0,1;1)

[CARuler]

The edit https://conwaylife.com/w/index.php?titl ... did=159676 adds some kind of obscure notation. To my knowledge, the added notation was never defined anywhere. Before trying to add it, it would be much more productive to write down a clear definition and make sure that it can be read, can be understood by readers and makes sense as a definition.

I suggest to remove the gibberish. (The same should be done with any other newly coined notations or jargon, and should be covered by LW:NB)

[2,1],[1,0] ((1,0;1)-(0,1;1)

it shall be defined soon. just wait a bit

[confocaloid]

[...] it shall be defined soon. just wait a bit

I'm not optimistic on how clear any "definition" is going to be.

Regardless of whether or not it is/will be defined, it violates LW:NB (attempting to document your own newly coined stuff).

[CARuler]

i would like to make it clear that that does not excuse anyone from removing the neighborhood from the list!!!!!!
whoever did that come forward and put it back!
can i write the notation without a neighborhood being pulled off the wiki for goodness' sake!

EDIT by dvgrn: @CARuler, this post seems to indicate some significant confusion about how LifeWiki editing works. In particular, it seems like you were not aware of the "history" tab on each article, where you can easily see who made what changes. In this case, hotdogPi did a very appropriate manual rollback of a non-notable addition to a table.

It would be great if you could demonstrate somewhere that you understand wiki-editing conventions and notability guidelines better than this post indicates. Until you've had some clarifying discussions with the rest of the community, it's probably best if you don't attempt any further LifeWiki edits along these lines.

[confocaloid]

What do you mean by neighbourhood and notation without a neighbor, exactly? It is unclear how your post connects to your edits on the wiki.

[...] can i write the notation without a neighbor [...]

[CARuler]

What do you mean by neighbourhood and notation without a neighbor, exactly? It is unclear how your post connects to your edits on the wiki.

[...] can i write the notation without a neighbor [...]

i meant from the table of neighborhoods

[confocaloid]

There are way too many neighbourhoods (infinitely many) to put them all in a table.

Most of them are non-notable. Your edits violate LifeWiki:Notability (documenting your own stuff) regardless of whether your newly-coined notation is defined (and so far it isn't clearly defined either).

[CARuler]

here maybe???
where did you expect?

There are way too many neighbourhoods (infinitely many) to put them all in a table.

have you read the page??????????? the table there!

[confocaloid]

The table is there, it is finite, but the set of neighbourhoods is infinite. You can't document them all. I suggest to read LW:NB

[CARuler]

The table is there, it is finite, but the set of neighbourhoods is infinite.

but for now you can document the ones that have a list of transitions

[confocaloid]

That's also infinite, for any plausible meaningful interpretation and regardless of jargon used. All of them already exist, along with all associated information that is easily computable from how it is defined.

[confocaloid]

https://conwaylife.com/w/index.php?diff ... did=159486
Not an improvement. Removing output gliders from a glider gun (which was previously shown in the canonical form, as far as I can tell).

Glider guns should be shown in the canonical form. See the readme file:
https://entropymine.com/jason/life/dpguns/readme.txt
https://entropymine.com/jason/life/dpguns/

EDIT by dvgrn: Reviewed this item. WhiteHawk's edit summary was

It's more standard on the wiki to show the gun without any emitted gliders (see p15, p16, p60 guns, GGG, etc.

which seems accurate. As far as I can recall, it has been quite seldom that we've used gun-collection canonical form for gun patterns in LifeWiki infoboxes. That has always obscurely annoyed me, but it is what it is; the README from Dieter and Peter's gun collection isn't particularly relevant.

The gallery items for the p14 glider gun article definitely are in canonical form, but that doesn't seem to set a precedent for the infobox -- where, for that particular article, the LifeViewer display was disabled quite a long time ago, and was only restored recently when the p14 gun was reduced to a reasonable size so that it worked to display it in the infobox after all.

[confocaloid]

https://conwaylife.com/w/index.php?diff ... did=159486
Not an improvement. Removing output gliders from a glider gun (which was previously shown in the canonical form, as far as I can tell).
[...]
EDIT by dvgrn: Reviewed this item. WhiteHawk's edit summary was

It's more standard on the wiki to show the gun without any emitted gliders (see p15, p16, p60 guns, GGG, etc.

which seems accurate. [...]

I disagree. That edit summary isn't really accurate.

First, there is currently no "standard" on this that would be specific to LifeWiki.
There is readme.txt from the old glider gun collection, and people continued and continue to follow the same guidelines for glider guns in other contexts.
Other than those guidelines from Dieter and Peter's gun collection, I'm not aware of anything else relevant to the question that would be anywhere close to a "standard".

Second, showing the gun without any emitted gliders leads to particularly awkward display in this case:

Code: Select all

x = 72, y = 64, rule = B3/S23
39b2o$38bo2bob2o$37bo2b2obobo$37b2obo4bo$38bo2b2o2bob2o$36bo2bobo2b2o
2bo$35bob3obobo2bo$26bo9bo5bob2o$26b3o8b3o$4b2o23bo10b6o$4bobo4b2o3b2o
6b4o2bo4b3ob2o4bo$7bo3b2o2bobo6bo3b2o4bo3bobob2o$2o3b2obo6bobob2ob2o3b
o4bo2b4obobo$bo2bobob7obobobobo5b6obobo2bo3bo$o3bo2bo8bo3bo2bo4bo6bo2b
o2b4o$4obo2b6o2b2ob6o5b5o3b2o$5b3o4bo2b3obo4bo8bo5bob2o$2o3bobobo4bo5b
ob2o10b2obobobobo$o4bobobob10obo4bo6bo3bobo2bo$b3ob2o2bo12bo3bobo5bo3b
obobo$4bo4b4o2b2o2b2obob3obo4b5o3bo$b2obo7bo2bo4bo2bo4b2o2b5o$bobo7bo
4bo3bo3b4o2bo5bo$10bob4o2b2ob3o4b2o5bo$11bo4b2obobo3b2obobo3b2o3b2o$12b
3obo9bobo2b2obo3bo2bo$14bo2b4o4bo2bo4bo4b3o$15b2o4bo4b3ob3obo$17b5o7b
ob2o3b3o$17bob4o3b2obo4b2o3bo$4b2o8b2obo5bobobob2o4bo3bo$5bo8bo2bo2bo
2bobo3bo2b2o3bob2o$5bobo7b2o2bobobo2bo2bo6b2o3bo$6b3ob2o5b5ob3o2b2obo
6b3o3b2o$8b2obo5bo4bo7b2obo4bo5bo2b2o$8b3o7b3obob6o2b2o11bobo$4b2o3bo
10bobobo9b2o8b2obo2b2o10b2o$4bo2bobo17b2obo2bobo7bo3bobobo10bobob2o$6b
2obo2bo8b3o3bo4bo2bo6b3ob2obo14bobobob2o$10b2o16bo3bo2b2ob2o23b2o3bob
o$29b2ob2o6bo5b2o4b2ob2o7bo3bo2bo$22bo9b2o3bo2bo4b3o3b6o2b2o2bo5b2o$21b
3o13bo2bo3bo13bo5b5o$11b2o7b5o12b2obo3b2o4bobo2bobo3bo6bo$11b2o6b2o3b
2o12bobo3bo3bobob2obob11o$10bo8b2ob3o13bobobobobobobo14bo$9b3o8b4o15b
obob2ob2o2bobob9o$19bo2bo18bo3bo4bob2o5bo2bo$40b2o3bob3o5b2o$14b3o7bo
21b2o8bo$15bo7bobo28bo$13b2o9bo29b2o$13b2o4$14b2o$14bobo$15b2o2$12b2o
$13bo$10b3o$10bo!

The previous revision of the RLE in question ( https://conwaylife.com/w/index.php?titl ... did=159486 ) was the canonical form, and it was much easier to see where are the actual output gliders:

Code: Select all

x = 72, y = 64, rule = B3/S23
39b2o$38bo2bob2o$37bo2b2obobo$37b2obo4bo$38bo2b2o2bob2o$36bo2bobo2b2o
2bo$35bob3obobo2bo$26bo9bo5bob2o$26b3o8b3o$4b2o23bo10b6o$4bobo4b2o3b2o
6b4o2bo4b3ob2o4bo$7bo3b2o2bobo6bo3b2o4bo3bobob2o$2o3b2obo6bobob2ob2o3b
o4bo2b4obobo$bo2bobob7obobobobo5b6obobo2bo3bo$o3bo2bo8bo3bo2bo4bo6bo2b
o2b4o$4obo2b6o2b2ob6o5b5o3b2o$5b3o4bo2b3obo4bo8bo5bob2o$2o3bobobo4bo5b
ob2o10b2obobobobo$o4bobobob10obo4bo6bo3bobo2bo$b3ob2o2bo12bo3bobo5bo3b
obobo$4bo4b4o2b2o2b2obob3obo4b5o3bo$b2obo7bo2bo4bo2bo4b2o2b5o$bobo7bo
4bo3bo3b4o2bo5bo$10bob4o2b2ob3o4b2o5bo$11bo4b2obobo3b2obobo3b2o3b2o$12b
3obo9bobo2b2obo3bo2bo$14bo2b4o4bo2bo4bo4b3o$15b2o4bo4b3ob3obo$17b5o7b
ob2o3b3o$17bob4o3b2obo4b2o3bo$4b2o8b2obo5bobobob2o4bo3bo$5bo8bo2bo2bo
2bobo3bo2b2o3bob2o$5bobo7b2o2bobobo2bo2bo6b2o3bo$6b3ob2o5b5ob3o2b2obo
6b3o3b2o$8b2obo5bo4bo7b2obo4bo5bo2b2o$8b3o7b3obob6o2b2o11bobo$4b2o3bo
10bobobo9b2o8b2obo2b2o10b2o$4bo2bobo17b2obo2bobo7bo3bobobo10bobob2o$6b
2obo2bo8b3o3bo4bo2bo6b3ob2obo14bobobob2o$10b2o16bo3bo2b2ob2o23b2o3bob
o$29b2ob2o6bo5b2o4b2ob2o7bo3bo2bo$22bo9b2o3bo2bo4b3o3b6o2b2o2bo5b2o$21b
3o13bo2bo3bo13bo5b5o$11b2o7b5o12b2obo3b2o4bobo2bobo3bo6bo$11b2o6b2o3b
2o4bo7bobo3bo3bobob2obob11o$10bo8b2ob3o3bobo7bobobobobobobo14bo$9b3o8b
4o5b2o8bobob2ob2o2bobob9o$19bo2bo10bo7bo3bo4bob2o5bo2bo$34bo5b2o3bob3o
5b2o$14b3o7bo7b3o11b2o8bo$15bo7bobo28bo$13b2o9bo12bo16b2o$13b2o20bobo
$36b2o$40bo$41bo$14b2o23b3o$14bobo$15b2o27bo$42bobo$12b2o29b2o$13bo33b
o$10b3o35bo$10bo35b3o!

This is why I wrote "Not an improvement. Removing output gliders from a glider gun (which was previously shown in the canonical form, as far as I can tell)."

Removing the gliders fails to make a better display, and also changes the display away from the canonical form of the gun.

[dvgrn]

I disagree. That edit summary isn't really accurate.

First, there is currently no "standard" on this that would be specific to LifeWiki.

I have now taken the time to click through and look at all eighty-some guns in the LifeWiki “Guns” category, one at a time.

As you say, there definitely is no consistently applied standard that is maintained across all of the gun pages at the moment. The form of each gun is an individual choice made by each article’s author — and those choices are all over the map. There are guns with gliders well outside the bounding box, slightly outside the bounding box, well inside the bounding box, and just after the glider first appears. Occasionally an RLE got copied from the gun collection so it’s in canonical form — especially for guns in the mid-double digits, for some reason.

But more often, no output is shown at all. So that edit summary still seems accurate to me. There is a LifeWiki standard that I think is implied by the no-output patterns.

A sometimes-followed LifeWiki standard
When the LifeWiki displays and describes a pattern, it’s trying to be accurate and not confusing. Gun patterns without outputs are the miminal form that can accurately be labeled a “gun”. Output gliders are certainly handy for some purposes, but they’re not part of the gun, and they’re easy to obtain by running the pattern.

I haven’t surveyed all the no-output guns to this level of detail, but it looks like they’re very often in a low-population phase.

Check the period-690 glider gun article, for example. I find the chosen phase to be pretty irritating, really, because it takes so long for the glider to escape that I think I must have missed it! However, the infobox lists a population of 62 — and the T=0 form shown has a population of 62.

That was a deliberate choice, made to align with a LifeWiki-specific standard. It shows the form that we need to know about to correctly fill in the infobox population parameter.

Gun-collection canonical form, by contrast, has some number of extra gliders included, bulking up the population. Those patterns usually aren’t the minimal form of the gun at all— there’s a widely varying number of extra gliders, plus an arbitrary-looking non-minpop phase of the gun that happens to align a glider with the gun’s all-phases bounding box — which may not match the current phase’s bounding box. It’s a complicated standard. It might be better to stick with a simple minpop standard on the LifeWiki.

The minpop state of a gun often doesn’t give much hint about where the output will appear, but it often does a good job of showcasing the active objects that will interact to create the output.

Long story short
There are advantages to both of these competing standards. If we want to go around standardizing gun articles, it’s not clear to me why a non-LifeWiki standard should necessarily be chosen over an existing LifeWiki-specific standard— given that neither standard has been followed particularly well to date!

Next steps
If someone wants to take on this gun standardization problem as an editing project, I’d suggest starting a discussion thread first to see if there’s a consensus about which standard we should consistently use. Otherwise this is in the category where it’s easy to get into accidental edit wars, because there are perfectly decent reasons to make changes to individual articles in either direction.

Unless we’re going to decide to pick one standard and stick with it, there’s no strong reason either to make changes (in either direction) to any one individual gun page, or to undo such a change once it is made.

[confocaloid]

[...] Check the period-690 glider gun article, for example. I find the chosen phase to be pretty irritating, really, because it takes so long for the glider to escape that I think I must have missed it! However, the infobox lists a population of 62 — and the T=0 form shown has a population of 62.

That was a deliberate choice, made to align with a LifeWiki-specific standard. It shows the form that we need to know about to correctly fill in the infobox population parameter. [...]

The first question is: where that "a LifeWiki-specific standard" was previously documented? Maybe I simply forgot about its existence, but I don't remember seeing where that was written.
To me, it looks like there is simply no such "standard".

Further, glider guns are traditionally measured / reduced by the bounding box area (rather than population). The readme.txt file linked above explains good reasons for that preference. Various people on the forums also repeatedly explained reasons for measuring guns by the bounding box area. Catagolue also measures glider guns by the bounding box area. If there is anything close to a standard at all, then it is this approach (measure by the bounding box area, and put the gun into the form where the output glider is about to leave the bounding box; more details can be found in readme.txt).

It is also significantly easier to manually double-check that the gun is in the canonical form, compared to double-checking that the population is stated correctly. (Especially for high-period guns.)

In the period-690 glider gun entry, the infobox may claim that the population is 62, but how would a reader verify that claim? Is that indeed the minimum population (and in what sense)? Double-checking that "manually" would likely involve looking at every single phase in Golly or LifeViewer, deleting output gliders that can be proven to never interact in future, and finding the lowest population of a single phase with output gliders deleted.

In contrast, double-checking that the gun is in the canonical phase doesn't require looking at every single phase. One can evolve the gun long enough that next output glider appears, look at the history envelope and calculate the last generation before the glider left the bounding box.

[LuveelVoom]

In the period-690 glider gun entry, the infobox may claim that the population is 62, but how would a reader verify that claim? Is that indeed the minimum population (and in what sense)? Double-checking that "manually" would likely involve looking at every single phase in Golly or LifeViewer, deleting output gliders that can be proven to never interact in future, and finding the lowest population of a single phase with output gliders deleted.

Place an eater 1 in the output stream, use identify, and subtract 7 from the lowest population? Right?

[confocaloid]

[...] Place an eater 1 in the output stream, use identify, and subtract 7 from the lowest population? Right?

No, because you didn't tell where exactly the eater should be placed (it might make difference with the output glider not yet eaten or partially eaten), and either way, the eater doesn't delete the glider instantly from the first generation where it can be detected and will never interact again.

[WhiteHawk]

Well, I figured out the reason why PseudoLife's randomized soup was not showing up on the page was because Naszvadi installed a

"|hideimg = true"

line on the page on the same edit that included mention the discovery of a gun in the rule.

I know there has been some debate over the relevance/notability of randomized soups on CA pages, but I see no reason for this line to be there, let alone not being on any other wiki page. Please let me know if I did the wrong thing removing it.

[dvgrn]

I know there has been some debate over the relevance/notability of randomized soups on CA pages, but I see no reason for this line to be there, let alone not being on any other wiki page. Please let me know if I did the wrong thing removing it.

You did fine. I don't think that that "hideimg" line had anything to do with Naszvadi's edit. It's been there for a couple of years, since this edit by confocaloid.

There's been quite a bit of discussion about the presence of random soups in OCA rule articles. See especially the discussion starting somewhere around confocaloid's post here on the "LifeWiki infoboxes" thread.

Several people have spoken up, mostly on that older thread, in favor of having random soups show up in OCA rule infoboxes.

Request for input
I'm looking for input from anyone who thinks that the random soup should not appear in the Pseudo Life article. Please, if you think that, post something here to say so. Until someone new shows up with a different opinion, there have already been plenty of people supporting random soups in infoboxes, so it seems like we can safely leave that article with the "hideimg" parameter removed.

[confocaloid]

[...] There's been quite a bit of discussion about the presence of random soups in OCA rule articles. See especially the discussion starting somewhere around confocaloid's post here on the "LifeWiki infoboxes" thread. [...]

The discussion of soups in infoboxes goes mostly from the next page. viewtopic.php?f=16&t=5981&start=50

As far as I can tell, the more interesting attempts to explain how such "soups in infoboxes" might possibly make sense are as follows: (for details, check the previous discussion)

• There was a claim to the effect that failing to show a soup would somehow amount to "withholding information".
  
  The problem about that is, a soup by itself doesn't really make any kind of relevant noteworthy encyclopedic information that would deserve to be mentioned in the article at all. It is easy to generate lots and lots of soups. By itself, soup-generating activity doesn't automatically produce relevant noteworthy information. (Until explicitly proven otherwise, by writing down a clear explanation of why some specific soup is relevant to the topic and belongs in the article.)
• There was an objection on the grounds that showing a specific pattern (chosen by a wiki editor) in the infobox would be subjective, and would leave "... room for presenting a biased/skewed view. It would discredit the wiki ..."
  
  The problem about that is, showing soups in infoboxes is also subjective, and it also presents a biased/skewed view and "discredits the wiki" in much the same way.
  "Showing soups in infoboxes" creates a bias towards those CA where showing an evolving soup makes sense at all. It is a bias towards soup-searching, and against other ways of exploring cellular automata.
  (Further, if one adds the possibility of adjusting "... technical details such as what density, symmetry and grid type should be used for illustration, ..." (as was suggested), then that would leave even more room for bias.)

The most unbiased way to deal with this issue that I can imagine, is to avoid having any pattern in the infobox. Unless some CA is specifically designed for the sole purpose of having a single noteworthy pattern in it (and that pattern is small enough to fit in the infobox), a cellular automaton cannot be illustrated by a single pattern in an unbiased way. One can leave only brief technical information in the infobox, and give any extended information and illustrations in the main text.

The point of an infobox is to provide brief technical information about the topic of the article. If there is no single fixed picture or pattern that can illustrate the topic, there should be no picture or pattern in the infobox at all.

If it is considered useful to show a soup for some specific purpose, then the soup (or even several soups, if there are several noteworthy relevant soups) also can be shown in the main article (via EmbedViewer template), along with a caption for every shown pattern that clearly explains where it comes from, what is the purpose of showing that particular pattern, what it is supposed to tell or illustrate.

Having said all that, I think I personally wouldn't object to illustrating Conway's Game of Life

• by showing the glider (which is a specific spaceship) in the infobox, or
• by showing the pentadecathlon (which is a specific oscillator) in the infobox, or
• by showing Gosper's glider gun (which is a specific p30 glider gun) in the infobox, ...

as long as there is a clear accurate description of the pattern in a caption nearby.
All of the patterns I listed are relevant and notable in the context of CGoL, that's well-known, but even then there should be a clear description if you are going to add the pattern into the article.

It would be fine to illustrate a CA by putting a single pattern in the infobox, as long as there is an explanation of how exactly that pattern is relevant and notable in the context of that CA.

An unexplained soup fails to be a relevant notable pattern. (E.g. showing a soup fails to illustrate Conway's Game of Life, and I think it is worse than it would be to show a single notable pattern instead.)

[confocaloid]

(For the preferred name in credits, see the leftmost filled column in User:77topaz/Forum handles table.)

• https://conwaylife.com/w/index.php?titl ... did=161218 Misspelled username in a reference.
• https://conwaylife.com/w/index.php?titl ... did=144709 Misspelled username in a reference. "p24" needs to be lowercased by convention.
• https://conwaylife.com/w/index.php?titl ... did=158178 "p67" needs to be lowercased by convention.
• https://conwaylife.com/w/index.php?titl ... did=159086 The linked edit adds a false claim that Gabriel's p138

  "... does not have strict volatility. ..."

  Every oscillator has strict volatility, which is a number between 0 and 1. LifeViewer reports that Gabriel's p138 has strict volatility approximately 0.87.
  
  The same linked edit adds a claim that Statorless p3

  ... and therefore also has standard volatility 1

  That should be reworded (the phrase "standard volatility" fails to be a defined term).
  The volatility and the strict volatility are defined properties of an oscillator.
  
  Later in the same edit, "Strictly volatile and Statorless" needs to be lowercased.
• https://conwaylife.com/w/index.php?titl ... did=141174
  The word "glider" should be lowercased.
  The phrase "stable supported rotors" is unclear, what kind of thing could possibly count as a "stable supported rotor"? That needs to be reworded to communicate whatever was the intended meaning.
  The claim is also unsubstantiated, there should be references to some relevant pages or discussions, to make it clear e.g. what should be done if some new discovery makes the claim no longer true.
• https://conwaylife.com/w/index.php?titl ... did=161149
  Adding a multistate pattern in a CA that isn't Conway's Life, with dubious relevance to the topic of the article. Viewing the pattern in Golly would require readers to install a ruletable. Suggested removal, the primary focus of the wiki is CGoL, the added content is a piece of trivia and there are way too many arbitrary observations of the same kind to add them all.

EDIT by dvgrn: Thanks for pointing these out, confocaloid! As of 4/7/2025 these points have all been addressed by additional edits, mostly by WhiteHawk -- thanks, WhiteHawk! -- except the final item. I had a look at that one, and did not decide to remove it; other editors might decide differently.

[confocaloid]

https://conwaylife.com/w/index.php?titl ... did=154879
The added p57 oscillator is of dubious notability (least-common-multiple oscillator that isn't the smallest known oscillator of its period by population), see LW:NB.
The linked forum post (post192843) fails to contain the shown oscillator (i.e. unrelated reference that doesn't support the added content).

At least the irrelevant reference should be removed, and probably the oscillator also should be removed (not sufficiently notable to be mentioned on the wiki).

[...] An unexplained soup fails to be a relevant notable pattern. (E.g. showing a soup fails to illustrate Conway's Game of Life, and I think it is worse than it would be to show a single notable pattern instead.)

[...] https://conwaylife.com/w/index.php?titl ... did=161149
Adding a multistate pattern in a CA that isn't Conway's Life, with dubious relevance to the topic of the article. Viewing the pattern in Golly would require readers to install a ruletable. Suggested removal, the primary focus of the wiki is CGoL, the added content is a piece of trivia and there are way too many arbitrary observations of the same kind to add them all. [...]

[WhiteHawk]

https://conwaylife.com/w/index.php?titl ... did=154879
The added p57 oscillator is of dubious notability (least-common-multiple oscillator that isn't the smallest known oscillator of its period by population), see LW:NB.

'

there are very few p57 oscillators in life not based on snark loops, and this one happens to only be 5 cells larger than SKOP57, so I would consider it notable enough to be at least mentioned, since it clearly doesn't deserve it's own page (It is also the only p57 LCM currently known, and likely would remain the smallest if another was found). Besides, it showcases LCM interactions the other LCM doesn't.

[*] I posted at 08:57: viewtopic.php?p=210722#p210722
[*] Your most recent edit at the time was the revision as of 08:45: https://conwaylife.com/w/index.php?titl ... did=154879 with an irrelevant referenced post.
[/list]

Edit: dang it I read the time stamp wrong. In any case it was fixed before I read your previous post.