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]

Another infobox-related question: LifeWiki:Tiki_bar#Future_of_the_spartan_parameter