LifeWiki infoboxes

[Haycat2009]

A curious reader will sooner or later find out how random soups behave -- let them explore the rule on their own.

Withholding information for the sake of "exploration" is not something a wiki should do.

Presenting randomly generated soups that change on refresh, as something that is supposed to serve as "illustration" of a rule, is certainly not something I'd expect in a wiki that aims to be an encyclopedia.

If an infobox is going to contain an illustration, it should be a specific picture or pattern, always the same for all readers, and actually illustrating the rule in question. Otherwise, leave only brief technical information in the infobox, and show any patterns/pictures in the main part of the article about the rule -- you do not need to "withhold" any otherwise relevant information.

Like it or not, Lifewiki is not an encyclopedia and the random soup helps to give the idea of how the rule behaves. A specific picture or pattern will most likely not be representative of the rule in question (Like using a pufferfish emitting soup to represent Conway's Life) as it would likely have been picked to produce a rare object, misleading newcomers to think that it is the norm when it is not.

[confocaloid]

Withholding information for the sake of "exploration" is not something a wiki should do.

Presenting randomly generated soups that change on refresh, as something that is supposed to serve as "illustration" of a rule, is certainly not something I'd expect in a wiki that aims to be an encyclopedia.

If an infobox is going to contain an illustration, it should be a specific picture or pattern, always the same for all readers, and actually illustrating the rule in question. Otherwise, leave only brief technical information in the infobox, and show any patterns/pictures in the main part of the article about the rule -- you do not need to "withhold" any otherwise relevant information.

Like it or not, Lifewiki is not an encyclopedia and the random soup helps to give the idea of how the rule behaves. A specific picture or pattern will most likely not be representative of the rule in question (Like using a pufferfish emitting soup to represent Conway's Life) as it would likely have been picked to produce a rare object, misleading newcomers to think that it is the norm when it is not.

This is an interesting opinion that comes from a newcomer. But LifeWiki definitely aims to be an encyclopedia -- it attempts to give a summary of existing knowledge about Conway's Game of Life together in one place.

The random soup is not "representative" of anything. If the ash of a random soup shown to a reader happens to contain any specific object, then other readers will not see the same object, and the same reader will not see the same soup after reload.
Random soups don't work well even to show 2-state rules (soups in distinct rules visually appear very similar), and soups will not work at all for circuitry rules / multistate rules where random soups don't show the intended evolution.

The point of an infobox is to provide brief technical information. If there is no single fixed picture or pattern that can illustrate the subject, there should be no picture or pattern in the infobox at all -- any choice would be "misleading" by the same logic.

[Haycat2009]

Presenting randomly generated soups that change on refresh, as something that is supposed to serve as "illustration" of a rule, is certainly not something I'd expect in a wiki that aims to be an encyclopedia.

If an infobox is going to contain an illustration, it should be a specific picture or pattern, always the same for all readers, and actually illustrating the rule in question. Otherwise, leave only brief technical information in the infobox, and show any patterns/pictures in the main part of the article about the rule -- you do not need to "withhold" any otherwise relevant information.

Like it or not, Lifewiki is not an encyclopedia and the random soup helps to give the idea of how the rule behaves. A specific picture or pattern will most likely not be representative of the rule in question (Like using a pufferfish emitting soup to represent Conway's Life) as it would likely have been picked to produce a rare object, misleading newcomers to think that it is the norm when it is not.

This is an interesting opinion that comes from a newcomer. But LifeWiki definitely aims to be an encyclopedia -- it attempts to give a summary of existing knowledge about Conway's Game of Life together in one place.

The random soup is not "representative" of anything. If the ash of a random soup shown to a reader happens to contain any specific object, then other readers will not see the same object, and the same reader will not see the same soup after reload.
Random soups don't work well even to show 2-state rules (soups in distinct rules visually appear very similar), and soups will not work at all for circuitry rules / multistate rules where random soups don't show the intended evolution.

The point of an infobox is to provide brief technical information. If there is no single fixed picture or pattern that can illustrate the subject, there should be no picture or pattern in the infobox at all -- any choice would be "misleading" by the same logic.

My opinion: put random soups for 2-state and generations rules, and a specific object for a circuitery rule. Randomness is better for such rules, but circuitery rules just have the nature of circuitery (not randomness)

[confocaloid]

My opinion: put random soups for 2-state and generations rules, and a specific object for a circuitery rule.

That will require inventing new infobox templates (or at least new technical functionality) to distinguish between rulespaces.

While that perhaps would be possible (if adding rulespace-specific templates for pattern pages, why not follow the same idea for rule pages as well?), a simpler and more natural solution in this case would be to show all relevant patterns in embedded viewers in the main part of the article about a rule. A rule is not a pattern, nor a random soup.

[MEisSCAMMER]

A rule is not a pattern, nor a random soup.

No, but a pattern or a random soup can be representative of the rule, and it can give newcomers an idea of what the rule is like.
Personally I would suggest keeping Haycat's idea up until the random soups, but instead of random soups, give a predefined soup which produces a typical mix of objects in the ash. That way the risk of finding an incredibly rare object is mitigated. Updating the code for the template would actually be as simple as changing Template:EmbedViewerRule to handle a call to an RLE, changing Template:Rule to handle a call to an RLE and pass it to EmbedViewerRule, and changing Template:LifeViewer config/rule to remove the RANDOMIZE2. (Presumably these would all be duplicate templates.)

[galoomba]

The random soup is not "representative" of anything. If the ash of a random soup shown to a reader happens to contain any specific object, then other readers will not see the same object, and the same reader will not see the same soup after reload.

The point of showing a random soup is not to show any particular pattern. Rather, it's to show the "default behaviour" of the rule, which for most rules will be the same regardless of which soup is chosen.

The idea of generating a single soup and showing the same one every time might work, though I don't see why it's necessary. But I definitely disagree with not showing a soup at all, maybe with the exception of circuitry rules.

[confocaloid]

The random soup is not "representative" of anything. If the ash of a random soup shown to a reader happens to contain any specific object, then other readers will not see the same object, and the same reader will not see the same soup after reload.

The point of showing a random soup is not to show any particular pattern. Rather, it's to show the "default behaviour" of the rule, which for most rules will be the same regardless of which soup is chosen.

The idea of generating a single soup and showing the same one every time might work, though I don't see why it's necessary. But I definitely disagree with not showing a soup at all, maybe with the exception of circuitry rules.

When you are showing a random soup to a reader, you are in fact showing a pattern to a reader, but you don't really know which pattern you are showing. You might accidentally show an empty pattern to someone, or a "soup" that very quickly settles to a single block or vanishes, or (horribile dictu) a "soup" that displays some obscenity.

In other words, the display should be deterministic.

The other problem is that random soups do not explain or illustrate difference between different rules. It always looks basically the same -- a small soup with small hard to see cells, which either settles into some unrecognizable constellation or expands to fill the viewer display. These random animations are irrelevant.

When you are describing a rule, you have to show specific patterns -- not random ones.

[galoomba]

You might accidentally show an empty pattern to someone, or a "soup" that very quickly settles to a single block or vanishes, or (horribile dictu) a "soup" that displays some obscenity.

If the soup is large enough, that won't happen.

The other problem is that random soups do not explain or illustrate difference between different rules. It always looks basically the same -- a small soup with small hard to see cells, which either settles into some unrecognizable constellation or expands to fill the viewer display. These random animations are irrelevant.

Of course they do. Not only does it show whether the rule is stable or explosive, but also shows more detail: B2a rules, B34 rules, and things like B37/S23 are all "explosive", but in very different ways; some stable rules settle down quickly, some take longer; some rules settle into Life-like ash, some into blobs, some into large web-like structures, etc.

[Haycat2009]

A rule is not a pattern, nor a random soup.

No, but a pattern or a random soup can be representative of the rule, and it can give newcomers an idea of what the rule is like.
Personally I would suggest keeping Haycat's idea up until the random soups, but instead of random soups, give a predefined soup which produces a typical mix of objects in the ash. That way the risk of finding an incredibly rare object is mitigated. Updating the code for the template would actually be as simple as changing Template:EmbedViewerRule to handle a call to an RLE, changing Template:Rule to handle a call to an RLE and pass it to EmbedViewerRule, and changing Template:LifeViewer config/rule to remove the RANDOMIZE2. (Presumably these would all be duplicate templates.)

Ok, but a predefined soup which produces a typical mix of objects in the ash might not exist for some rules which tend to form large one-off still lifes and oscillators such as B2-a/S23, S4 rules and B/S012345678. In those rules, the only way to present it clearly is to randomize the soups to show a mix of large objects.

[confocaloid]

You might accidentally show an empty pattern to someone, or a "soup" that very quickly settles to a single block or vanishes, or (horribile dictu) a "soup" that displays some obscenity.

If the soup is large enough, that won't happen.

I think you are seriously underestimating people's ability to see things that are not there.
Assuming the choice in a specific case is to show a pseudorandom soup, it is better to show a single fixed soup, always the same, the same for all readers.

The other problem is that random soups do not explain or illustrate difference between different rules. It always looks basically the same -- a small soup with small hard to see cells, which either settles into some unrecognizable constellation or expands to fill the viewer display. These random animations are irrelevant.

Of course they do. Not only does it show whether the rule is stable or explosive, but also shows more detail: B2a rules, B34 rules, and things like B37/S23 are all "explosive", but in very different ways; some stable rules settle down quickly, some take longer; some rules settle into Life-like ash, some into blobs, some into large web-like structures, etc.

That also depends on initial density, on which states you use in the initial soup, how long you evolve the soup, etc. The implementation does not allow to adjust these for individual rules; on the other hand, allowing these adjustments would introduce even more "potential for bias", by the same logic.

The choice to show a pseudo-random soup (as opposed to either showing some meaningful pattern/patterns, or alternatively not showing any illustrations in the infobox) already constitutes bias. I think the "pseudo-random" implementation is biased towards alien rules that benefit from showing evolution of pseudorandom soups, and against other alien rules where that just plain does not make sense.

Ok, but a predefined soup which produces a typical mix of objects in the ash might not exist for some rules which tend to form large one-off still lifes and oscillators such as B2-a/S23, S4 rules and B/S012345678. In those rules, the only way to present it clearly is to randomize the soups to show a mix of large objects.

If the rule OCA:B/S012345678 is going to have a dedicated page, then it would be one of a number of good examples of why random illustrations are bad. The so-called "illustration" would be always a pseudorandom mixture of "on" and "off" cells, without any evolution. The reasonable thing would be to avoid any illustration in the infobox, and instead explain the rule in the main part of the article.

I think the same goes for many other rules.

[Haycat2009]

Ok, but a predefined soup which produces a typical mix of objects in the ash might not exist for some rules which tend to form large one-off still lifes and oscillators such as B2-a/S23, S4 rules and B/S012345678. In those rules, the only way to present it clearly is to randomize the soups to show a mix of large objects.

If the rule OCA:B/S012345678 is going to have a dedicated page, then it would be one of a number of good examples of why random illustrations are bad. The so-called "illustration" would be always a pseudorandom mixture of "on" and "off" cells, without any evolution. The reasonable thing would be to avoid any illustration in the infobox, and instead explain the rule in the main part of the article.

I think the same goes for many other rules.

So what? That was only an extreme example, what about rules like B2-a/S12 and S4 rules?

[confocaloid]

...
If the rule OCA:B/S012345678 is going to have a dedicated page, then it would be one of a number of good examples of why random illustrations are bad. The so-called "illustration" would be always a pseudorandom mixture of "on" and "off" cells, without any evolution. The reasonable thing would be to avoid any illustration in the infobox, and instead explain the rule in the main part of the article.

I think the same goes for many other rules.

So what? That was only an extreme example, what about rules like B2-a/S12 and S4 rules?

So what? Those are only non-strobing two-state isotropic rules on the {4,4} tiling with range-1 Moore neighbourhood. What about rules like B2-a/S12History or Symbiosis?

Code: Select all

x = 32, y = 32, rule = B2-a/S12History
AF.FE.F.ACECD4.D2A2.D.2ACD$F2.E2.DB.DFD.FDBD.ED2.BF.FD2CB.A$.2A.C.FB
4.E.B2.DE.2DF2.DB.C.AE$2.EDFE.F2C10.C.EA2.C.A.2D$BFBE2.D.B.CF.F.DF.D
2.FBAE2DCF.E$.AB.D2.BFEBA2.BDFED2.2DE2.A2.D2F$.2BE.FABD7.F2.E3.DF.2B
2.EC$A3.C3.FED2.CF2.E2C8.FC$CB.DFDBE2.A.CBDCE.E4.C.DEFD.EB$FD2C.E2.A
3.F.A2BA2B.ED.A.B.2A2C$3.B3.2D.A4.C4.B2.2F4.2F$2.D.C2.C.ED4.E.D.C.A.A
EBCB.A.F$2.AF.ABAB5.C.EF.DF.D.E2D.2CFC$CE5.B.FBECB.C3.BF3.EB.D$2.C.B.
D7.F2CDEC3.E.D.D2C.E$C.C.FB2.2A.C2ACF4.DAFCD.D.D.2F$E3.C4.B.ED.F6.DC
3.C.C2.D$CE.DCF.E.BCF.B.B5.B.E6.A$2.F9.FD.E6.C4.C2.FE$3.A.B2.D.BC.D.A
E.C2.ABEF.C2.F.A$2C2.AE.EBF3.D2.B.D.D7.C.AE$E2.AF.E2.AD.B.BCF2.E2.FA.
A2.DECB$2.C.B.BE2.F.F2.E.B.B2.AE2D3.2FA$CA4.FEF.F.A.D4CFC.C2A.FC2.B$
7.B.EC5.F.C.DF4.C.C$E.AE.2D6.BC3.E4F2A3.FCE$3.F.E.B.BA.E3.B2.C4.EDADB
2.B$2.D3.DCDE.F.CF2B2.ED.E.F.FA3.A$CB.2A2.F3.AB.CB2.EBC.BC.E2.A$A.C.B
DF2A3.D3CB.ABC2AC2.EB3.D$.F.F.CF.B3.CFBC2.A5.F2.DBF$.2AD3.FD3.E.F2C3.
FB.B.B2E2.DE!

Code: Select all

x = 32, y = 32, rule = Symbiosis
B2.B3.2A2.AB2.2A.B.2B2.B.3A$3A.B5.B.B2.2B2.AB2.A.2B3.B$.2B5.BA3.2BAB.
A3.AB.B3.B$4.B.A.B2.A.A2B2.BA.A.A.3B.2AB$4AB.B.A.2B2.B2.2AB.A.AB3.B$A
7.A3.2B.B.2A.2BA2B2.BABAB$3.B2.B.BA2.2A2.B3.A3B3.BA.AB$3A4.2A2.2B2A.
3AB.A.B.2BA.B.A$.AB.B.A2.B.A.AB2.A3.B2.BAB2.B.B$.2B.2BA.A2.A2BA.B.AB.
B.AB.B3.B$2.AB.4A3.BA3.B.A.AB2.2A.A.AB$2.B.3AB.A4.A.A2B.AB6.B.AB$A.B
3.3B5.B3.A.2A3.B2A3.A$A2.A2.A.B.B2.A2.AB6.B2.BAB2A$A2.2B.AB3.A.B2.AB
2.A7.B$2.A4.2A.BA.B.B2A3B.2A4.B.AB$AB.BA2B5.2BAB.3B2.BAB2.AB$.2B4.AB.
2A.B4.3BA2B2.ABA.AB$B.BAB6.A.A.2B3.4BABAB.2BA$3.A.BAB2A2BAB.BABA.A.2B
2.BABA.B$5.A.A.A.2B.B2.3A3.4B.B.AB$.BA.A4.2B6.2A.2A2B.A.2BA.A$.A.2B3.
B2.A2.B2.A3B3.B3.B.AB$.AB6.4A5.B.BA.B2.2A$3BA2.AB2.2AB2.AB.B.3A5.B.A$
B3.B2.2A.3B4.2A.BAB2.A2B.A$.2AB.2A.BAB5.B6.ABA2B3.A$B.2A2.B.B.ABA3.A
3.A.2BA.2A3.B$.A.A2.A.ABA.2BA.B.A.A.A.B3ABA$3.BAB.A2.B.AB.B.AB2.2A3.
2B.BAB$2AB2.3BA3.2BA.A3.AB5.2AB.A$.B.ABA.A2.A.2A2B.B6.A2.2B!

And even for those two-state isotropic rules, a specific rule may be notable not because of "how it behaves with pseudorandom initial soups", but instead because the rule itself was specifically fine-tuned/rulegolfed to enable some engineering or unusual behaviour. Using a pseudorandom soup to "illustrate" such a rule (a rule that is not notable for evolution of pseudorandom soups in it) would be misleading.

Insisting on pseudorandom soups as "the single best choice" is biased, towards a small subset of all notable alien rules.
For the majority of all notable alien rules, I think that a better choice would be to leave the infobox without any viewer or picture at all.

[MEisSCAMMER]

Insisting on pseudorandom soups as "the single best choice" is biased, towards a small subset of all notable alien rules. For the majority of all notable alien rules, I think that a better choice would be to leave the infobox without any viewer or picture at all.

In fact the majority of notable rules would benefit from a pseudorandom soup. Your rules are mostly edge cases; however, I will grant that those rules shouldn't get soups. However, this does not mean that e.g. INT, Generations, LtL, etc. would not benefit from pseudorandom soups! If soups are unreasonable for some rules, that doesn't mean that they should be kicked for all rules.

[Haycat2009]

...
If the rule OCA:B/S012345678 is going to have a dedicated page, then it would be one of a number of good examples of why random illustrations are bad. The so-called "illustration" would be always a pseudorandom mixture of "on" and "off" cells, without any evolution. The reasonable thing would be to avoid any illustration in the infobox, and instead explain the rule in the main part of the article.

I think the same goes for many other rules.

So what? That was only an extreme example, what about rules like B2-a/S12 and S4 rules?

So what? Those are only non-strobing two-state isotropic rules on the {4,4} tiling with range-1 Moore neighbourhood. What about rules like B2-a/S12History or Symbiosis?

Code: Select all

x = 32, y = 32, rule = B2-a/S12History
AF.FE.F.ACECD4.D2A2.D.2ACD$F2.E2.DB.DFD.FDBD.ED2.BF.FD2CB.A$.2A.C.FB
4.E.B2.DE.2DF2.DB.C.AE$2.EDFE.F2C10.C.EA2.C.A.2D$BFBE2.D.B.CF.F.DF.D
2.FBAE2DCF.E$.AB.D2.BFEBA2.BDFED2.2DE2.A2.D2F$.2BE.FABD7.F2.E3.DF.2B
2.EC$A3.C3.FED2.CF2.E2C8.FC$CB.DFDBE2.A.CBDCE.E4.C.DEFD.EB$FD2C.E2.A
3.F.A2BA2B.ED.A.B.2A2C$3.B3.2D.A4.C4.B2.2F4.2F$2.D.C2.C.ED4.E.D.C.A.A
EBCB.A.F$2.AF.ABAB5.C.EF.DF.D.E2D.2CFC$CE5.B.FBECB.C3.BF3.EB.D$2.C.B.
D7.F2CDEC3.E.D.D2C.E$C.C.FB2.2A.C2ACF4.DAFCD.D.D.2F$E3.C4.B.ED.F6.DC
3.C.C2.D$CE.DCF.E.BCF.B.B5.B.E6.A$2.F9.FD.E6.C4.C2.FE$3.A.B2.D.BC.D.A
E.C2.ABEF.C2.F.A$2C2.AE.EBF3.D2.B.D.D7.C.AE$E2.AF.E2.AD.B.BCF2.E2.FA.
A2.DECB$2.C.B.BE2.F.F2.E.B.B2.AE2D3.2FA$CA4.FEF.F.A.D4CFC.C2A.FC2.B$
7.B.EC5.F.C.DF4.C.C$E.AE.2D6.BC3.E4F2A3.FCE$3.F.E.B.BA.E3.B2.C4.EDADB
2.B$2.D3.DCDE.F.CF2B2.ED.E.F.FA3.A$CB.2A2.F3.AB.CB2.EBC.BC.E2.A$A.C.B
DF2A3.D3CB.ABC2AC2.EB3.D$.F.F.CF.B3.CFBC2.A5.F2.DBF$.2AD3.FD3.E.F2C3.
FB.B.B2E2.DE!

Code: Select all

x = 32, y = 32, rule = Symbiosis
B2.B3.2A2.AB2.2A.B.2B2.B.3A$3A.B5.B.B2.2B2.AB2.A.2B3.B$.2B5.BA3.2BAB.
A3.AB.B3.B$4.B.A.B2.A.A2B2.BA.A.A.3B.2AB$4AB.B.A.2B2.B2.2AB.A.AB3.B$A
7.A3.2B.B.2A.2BA2B2.BABAB$3.B2.B.BA2.2A2.B3.A3B3.BA.AB$3A4.2A2.2B2A.
3AB.A.B.2BA.B.A$.AB.B.A2.B.A.AB2.A3.B2.BAB2.B.B$.2B.2BA.A2.A2BA.B.AB.
B.AB.B3.B$2.AB.4A3.BA3.B.A.AB2.2A.A.AB$2.B.3AB.A4.A.A2B.AB6.B.AB$A.B
3.3B5.B3.A.2A3.B2A3.A$A2.A2.A.B.B2.A2.AB6.B2.BAB2A$A2.2B.AB3.A.B2.AB
2.A7.B$2.A4.2A.BA.B.B2A3B.2A4.B.AB$AB.BA2B5.2BAB.3B2.BAB2.AB$.2B4.AB.
2A.B4.3BA2B2.ABA.AB$B.BAB6.A.A.2B3.4BABAB.2BA$3.A.BAB2A2BAB.BABA.A.2B
2.BABA.B$5.A.A.A.2B.B2.3A3.4B.B.AB$.BA.A4.2B6.2A.2A2B.A.2BA.A$.A.2B3.
B2.A2.B2.A3B3.B3.B.AB$.AB6.4A5.B.BA.B2.2A$3BA2.AB2.2AB2.AB.B.3A5.B.A$
B3.B2.2A.3B4.2A.BAB2.A2B.A$.2AB.2A.BAB5.B6.ABA2B3.A$B.2A2.B.B.ABA3.A
3.A.2BA.2A3.B$.A.A2.A.ABA.2BA.B.A.A.A.B3ABA$3.BAB.A2.B.AB.B.AB2.2A3.
2B.BAB$2AB2.3BA3.2BA.A3.AB5.2AB.A$.B.ABA.A2.A.2A2B.B6.A2.2B!

And even for those two-state isotropic rules, a specific rule may be notable not because of "how it behaves with pseudorandom initial soups", but instead because the rule itself was specifically fine-tuned/rulegolfed to enable some engineering or unusual behaviour. Using a pseudorandom soup to "illustrate" such a rule (a rule that is not notable for evolution of pseudorandom soups in it) would be misleading.

Insisting on pseudorandom soups as "the single best choice" is biased, towards a small subset of all notable alien rules.
For the majority of all notable alien rules, I think that a better choice would be to leave the infobox without any viewer or picture at all.

History rules are not notable for a page as it is just the base rule that is being documented, and if the rule itself was specifically fine-tuned/rulegolfed to enable some engineering or unusual behaviour, I just said that a set info box pattern could be used.

[confocaloid]

Sorry - anyway the edit has been reverted and I will not attempt to redo it.

I just restored the template functionality, after another your attempt to redo that same edit.

For context, the "hideimg" parameter is consistently added to all infobox templates: viewtopic.php?p=160959#p160959

[confocaloid]

The recent wiki edit https://conwaylife.com/w/index.php?diff ... did=142384 by DroneBetter apparently confuses embedded viewers with infoboxes. (I.e. "... smaller than the first infobox ..." when referring to embedded viewers.)

Clarification:

• An infobox is a panel, usually in the top right of an article, that summarizes key features of the page's subject. https://en.wikipedia.org/wiki/Wikipedia ... /Infoboxes
• An embedded viewer is a LifeViewer shown on the page (either a single viewer or a gallery of viewers), surrounded by text.

There can be multiple embedded viewers, but there should be at most one infobox per page.

[confocaloid]

Talk:Rumbling river 1

Should the infobox show a smaller version or a wick and the particular version in the stamp collection be moved to the page body? --Galoomba (talk) 00:17, 12 April 2024 (UTC)

No it should not. As was explained in an earlier comment on the talk page Talk:Rumbling river 1, the larger size helps the reader to see how the oscillator is arbitrarily extensible.

If you shorten it to the limit (as in the headerless RLEs posted on the talk page), it will become nearly impossible to see the "rumbling river" in it. It will become unnecessarily hard to see the extensibility. And it will become hard to explain why a particular reduction was chosen for the infobox.

If the infobox shows the version from the stamp collection, then the question "why this version?" can be answered "because it was in Dean Hickerson's stamp collection". That is a sufficient explanation.

[hotdogPi]

I agree that the rotor should not be reduced, as it clearly needs to be a wick. If the stator isn't minimal, I'm fine with reducing that as long as doing so doesn't make it impossible to tell how to extend it.

[galoomba]

If the infobox shows the version from the stamp collection, then the question "why this version?" can be answered "because it was in Dean Hickerson's stamp collection". That is a sufficient explanation.

That is an explanation, but i'm not sure i'd call it "sufficient". Why is that better than "it's the smallest one" or "it's the underlying wick"? "It was picked by one person in 1994 presumably for showcase reasons" seems way more arbitrary than those two. I don't see a problem with calling all these patterns "rumbling river 1", my main issue is that all the data e.g. bounding box, volatility, rulespace, apgcode is based on that one arbitrary variant.
Also, why is it called "rumbling river 1"? I'd assumed Dean Hickerson called it that, but he just called it "p3 rumbling river". I'm guessing the reason is "it was the first rumbling river discovered", but then that name should apply to all the variants. If we give that specific variant the number 1, what should the shorter ones be called? Rumbling river -3 through 0?

[confocaloid]

[...] I don't see a problem with calling all these patterns "rumbling river 1", my main issue is that all the data e.g. bounding box, volatility, rulespace, apgcode is based on that one arbitrary variant. [...]

I think that may be a case of an infobox added where no infobox is needed.

Does the intended topic of the article even have well-defined properties "bounding box", "volatility", "apgcode"?

If you want to have those properties in the infobox, then it makes sense to retain the version from the stamp collection, and list properties of that version. It is arbitrary in a sense, but it is well-defined and will never change. (It will always be "the version from the stamp collection".)
Otherwise, if you reject that simple choice, then you will end up with more arbitrariness. Where to cut the wick? How to define "smallest" / how to determine the best reduction? Who discovered that specific reduction? How to explain all that, and where the pattern came from, in the infobox?

If you do not want to have those properties in the infobox, that may mean an infobox is not needed on that page. The patterns can be shown in embedded viewers, each with its own caption, providing only relevant information without any ill-defined/irrelevant properties. Discovery information can be given in text as well.