LifeWiki:Tiki bar

From LifeWiki
Jump to navigation Jump to search
Taka Tiki Break

Welcome, one and all, to the Tiki bar! This page is used to discuss the technical issues, policies, and operations of the LifeWiki. Or just sit down, relax, and enjoy a cocktail.

Click here to start a new Tiki bar discussion.

Welcome to the Tiki bar

Wikipedia has the Village pump, Wiktionary has the Beer parlour, but the LifeWiki's lacked a central page for discussion so far other than User talk:Nathaniel. So I took the liberty to create the Tiki bar to facilitate discussion in a friendly and relaxed atmosphere. Welcome! Apple Bottom (talk) 11:09, 13 June 2016 (UTC)

Archived discussions

Note: active discussions are never archived while still active.

Redirects from misspelling

I fail to see why redirects from misspellings are prohibited. Atavoidirc (talk) 21:40, 27 June 2022 (UTC)

I think there are too many possible ways to misspell something (just multiply the number of letters in the title by (number of letters in the alphabet - 1) and on top of that add misspellings that add/remove/exchange letters), so that it becomes unreasonable to make redirects for them. For another example, should "jrake" be redirected to rake, or to krake (note that letters j and k are adjacent on a common keyboard layout), or maybe to a disambiguation page created specifically for the purpose of distinguishing possible misspellings? Some redirects for really common misspellings may be acceptable - but I think it is necessary to show explicitly that these misspellings are indeed common, and there are few such cases.
In any case, I do not think it is helpful to quickly make dozens of redirects for misspellings - it clutters the logs of recent changes for editors, and it does not seem a noticeable improvement for readers. Confocal (talk) 07:06, 28 June 2022 (UTC)
(Added later) Although the following does not necessarily imply anything specific (I think the wiki should not promote an incorrect spelling, even if it becomes common), here are results of a quick forum search: "candelfobra" - 0 matches, "candlefobra" - 0 matches, "candelfrobra" - 16 matches, "candlefrobra" - 36 matches. Confocal (talk) 12:06, 28 June 2022 (UTC)
Personally i think redirects from misspellings that are not just typos (e.g. Candelfobra) should be allowed. I've made this specific misspelling several times before, so i know at least one person who would benefit from it. Atavoidirc (talk) 11:25, 28 June 2022 (UTC)
My vote would definitely be to not add misspelling-redirects, and to remove any that have been added. We've already got lots of spelling and punctuation variants showing up in the All Pages lists, and those lists will get extremely cluttered if we also add every possible misspelling of every article name -- or even every reasonable misspelling.
Of course there's a checkbox to hide redirects, but the problem I see is that current policy is fairly consistent about having redirects be valid variant spellings -- terms that people have actually used or might actually use.
So if we add things like "Suprise", we're kind of implying that "suprise" is a valid name that someone has used for something. People might click on it thinking, "what's that, a pun on 'sup' so it's some kind of eater?" and then mysteriously find no explanation of why "suprise" is listed. I'd much rather avoid that unlikely potential confusion, than avoid the unlikely potential confusion that someone can't find the Surprise article because they typed "suprise".
In other words, given that the lexicon of Life terms includes all kinds of things like "Catagolue" that look like misspellings but are actually completely purposeful and have meaning... there's useful information in the current collection of redirects, and it's not an improvement to add a random scattering of misspellings that are really just misspellings. People can perfectly well figure out how to spell "surprise" right, in the incredibly rare cases when they accidentally mistype it and don't get a LifeWiki article match. Dvgrn (talk) 14:59, 28 June 2022 (UTC)
(Replying here to a message left at Talk:T-tetsons, since it is possible that that talk page will be deleted later:) I do not see why "T-tetsons" or "T-tetson" should mean something specific. There is a page Tumbling T-tetson on this wiki, and there is an entry "tumbling T-tetson" in Life Lexicon. There is a page Twirling T-tetsons 2 on this wiki, and there is an entry "twirling T-tetsons II" in Life Lexicon. However, I cannot find "T-tetson" or "T-tetsons" by itself in Life Lexicon. On the forums, the only example I found which might be related is in the thread "Help with names" (link) where there was an attempt to translate a set of words/terms into another language. I think that "T-tetsons" does not by itself mean anything at all, so I proposed the redirect for deletion. Confocal (talk) 00:16, 4 July 2022 (UTC)

2023

This tiki bar discussion did not finish in 2022. I think it is incomplete (for one thing, it implicitly assumes that everyone knows what this is about). Before this discussion started, several redirects-from-misspellings were created in a short timespan, without any edit summaries or other explanation. Overall, this looks like trying to anticipate misspellings before these misspellings actually happen. I do not support making lots of redirects "just in case". But one added or removed redirect does not globally change anything.
I think drawing the attention of everyone to redirects is unfortunate, because the wiki is about writing pages that describe or explain something -- redirects are a relatively minor feature, and ideally should "just work" without becoming the focus of a tiki bar discussion. Confocal (talk) 11:15, 4 April 2023 (UTC)

Proposed deletion of redirects from personal names to pages about a different subject

There is a number of redirects from names of people to pages that are not about the person (Alain Noels, Christiaan Hartman, Kees Kwekkeboom, Roger Banks, Steven Eker, and likely more). I propose that such redirects be deleted.

I believe it is unacceptable to have an imprecise redirect from a personal name. That may incorrectly suggest that the person is known only for one specific contribution (the one mentioned on the target page of the redirect), and also does not provide any context before directing the reader to another subject.

I think either there should be a separate non-redirect page for a person, or (less preferable) a redirect to a category for discoveries made by the person, or there should be no page at all (i.e. no redirect to anything). Confocal (talk) 23:19, 5 September 2022 (UTC)

Good issue to raise. It would be good to have an explicit "policy" about such things. I think we also need a similar agreement about whether and when a person should be linked at all even if there is little likelihood of the link ever having a landing (I'm thinking mainly of well-aged red links). Book (talk) 23:37, 5 September 2022 (UTC)
In general, I like red links; they are a very simple lightweight way to tell other editors "This page is missing", and they interact nicely with other available tools.
Speaking of pages about people specifically (and excluding all other LifeWiki topics), I'm inclined to agree that it's probably better to unlink long-missing pages about people. My reason is that such pages are harder to write, and the usual simple "process" of starting a short stub to be expanded later does not really work when writing about a person. Confocal (talk) 05:46, 16 April 2023 (UTC)

Usage of a non-default viewer theme

I added to several pages patterns that use #C [[ THEME Book ]] (this viewer theme is related to the book), as an attempt to understand how to improve presentation of patterns in pages. (For my edits adding this theme, see current versions of pages LWSS, MWSS, HWSS, Blockic.) I chose this theme because I like how it displays "off" cells that were "on" differently from cells that were always "off", in the same way as in the patterns printed in the book.

The first (more specific) question here is: does #C [[ THEME Book ]] look fine in the LifeWiki? Is it a good idea to optionally use this LifeViewer theme, in those cases when it seems preferable to display history trail? Or it is better to stick with the default theme everywhere without exceptions?

I note that there was already an objection to one of my edits, on the grounds of consistency with the rest of the wiki. However, I think presentation of patterns across the wiki is currently already inconsistent in several distinct ways. For instance, sometimes static images are used - and that may be preferable in some cases but not others. Another example is that {{EmbedViewer}} is used often but not everywhere - again, there may be good valid reasons for that. Hence a second, less specific question: how to improve presentation of patterns in the wiki?

Any feedback to the above? Confocal (talk) 09:02, 11 October 2022 (UTC)

Yes to theme Book (no pun intended). Good choice for the reasons and usage you state. Book (talk) 17:45, 12 October 2022 (UTC)
I personally think that themes with history cells should be avoided on the wiki except in cases where the history cells provide a substantial benefit in understanding the pattern. With regard to the consistency issues mentioned above, many pages have static images because they were created before LifeViewer existed. Sometimes LV:viewer is used because {{EmbedViewer}} adds an additional frame and caption that is not always desired. Neither of these represents inconsistency in how the wiki is currently updated.
~Sokwe 01:31, 28 February 2023 (UTC)
Since 42P38 has seen some edits trying to work out a standard for galleries, I want to also leave a comment regarding the use of the book theme on that page. I think the book theme should be used with the LCM oscillators, as it shows that the sparks of the two oscillators interact. However, I don't think the book theme provides sufficiently useful information in the honeyfarm hassler viewer to justify its use. I prefer that we err on the side of not using the book theme as it, in my opinion, clutters the image. In fact, I think when the book theme is used we should mention that the viewer includes the pattern's envelope.
~Sokwe 07:13, 29 April 2023 (UTC)
I added mentions of the pattern envelope in the article, without changing visibility of envelopes.
That p38 hassler is composed of interacting subpatterns, and (I think) it becomes easier to see "how it works", when the envelope is visible. (If the general agreement for that oscillator is that envelope does not provide substantial benefit, I will not object -- but it would be strange for me to remove it, given that I added it myself and I think it's useful.) Confocal (talk) 14:49, 29 April 2023 (UTC)
I think the animation, or the user running the pattern in the viewer themselves, is sufficient to show how the components interact in the honey farm hassler. In contrast, the LCM viewers are not animated and the interaction occurs rarely so understanding the exact interaction without history cells takes more time and effort by the user. The history cells work well for the LCM viewers. I still think they cause unnecessary clutter in the honey farm hassler viewer. I too will submit to the popular view if it disagrees with my own. If we care to find out what that is, we will probably need to ask on the forums or Discord.
~Sokwe 19:55, 29 April 2023 (UTC)

One of "use cases" where I was changing the theme is when history cells make it easier to see how a certain pattern is composed of smaller parts. For oscillating patterns, currently available features of LifeViewer make it possible to show the reaction envelope, by auto-running the pattern for one complete cycle (with history cells enabled) and then auto-stopping. In p8 glider reflector, it seems to help to see how a p128 oscillator is made out of two 180° reflectors. I used the same technique in p143 Bandersnatch loop to show how catalysts are arranged relative to the reaction. There are other pages where I used "THEME Book + AUTOSTART + STOP" combination to show reaction envelopes. Would this be considered a valid use case? Confocal (talk) 02:46, 28 February 2023 (UTC)

Another common "use case" is when showing a complete glider synthesis of a pattern. I think it becomes significantly easier to understand an animated synthesis (i.e. to see "how it works") if gliders leave traces behind them, and pauses are inserted in appropriate points. An example of this usage can be seen in Amphisbaena. If anyone is interested, I think I can write a more detailed explaination for how I was formatting glider syntheses with the "Book" theme -- I'm trying to be reasonably consistent with syntheses. Thanks for any feedback. Confocal (talk) 02:46, 28 February 2023 (UTC)

Creating pages in the OCA namespace

As we all know, well maybe not, but that's not important, I have an incomplete OCA:LeapLife page, currently under my user namespace. I'm considering completing it and moving it to the OCA namespace soon, and I would like to 1. know if there's any objection to it. 2. Know what makes an OCA rule notable enough to have an entry in LifeWiki.

Additionally, it was once planned to create some subpages under OCA:LeapLife, to document the many patterns of LeapLife. 3. Is this acceptable, and will this cause any trouble to the LifeWiki? Ultimium (talk) 08:16, 14 October 2022 (UTC)

I support the idea. If in doubt about whether the page is well-written / well-formatted / up-to-date / etc., the template {{stub}} can always be added on the top of the page, as a lightweight way to indicate that it may need expansion. Subpages are already used - see for example OCA:HighLife/Bomber, OCA:Pedestrian Life/List of common objects. Confocal (talk) 09:49, 14 October 2022 (UTC)
I am fine with the proposal in the description, but not with the proposal in the title — the OCA namespace is there for a reason, and if pages on specific OCA pages are moved to mainspace, it will cause confusion over what exists in CGOL itself and what doesn't. HotdogPi (talk) 11:22, 14 October 2022 (UTC)
Apologies - fixed now. Ultimium (talk) 11:59, 14 October 2022 (UTC)

User:Ultimium/OCA:LeapLife is halfway now. Do anyone have suggestions? Especially what to say in the Oscillators section.

Is the current version considered ready to be moved to the OCA namespace? I do not want to move it without making sure that main contributor(s) are okay with that. Confocal (talk) 03:05, 28 February 2023 (UTC)
If anyone thinks the page is good enough to be moved in its current state, move it. Ultimium (talk) 09:50, 21 April 2023 (UTC)
I just did a round of editing. I'm not yet moving the page right now -- will wait for others a few days. Confocal (talk) 11:32, 21 April 2023 (UTC)
I see that you added a note about trans-very long fuse with two tails appearing naturally. I think in this case I would rather correct the inaccurate information in the article outright, instead of making the page self-contradictory; I've already done the appropriate edit now.
Unrelatedly, I noticed that hotdogPi keep adding trivias (like the block corner catalysis) to the page. I don't think reverting someone else' contribution is polite, but I can think of quite a few things that are as noteworthy as the block catalysis, so maybe they shouldn't appear on an overview article of LeapLife. Ultimium (talk) 03:28, 23 April 2023 (UTC)
Is it possible to expand that part into a section on catalyses and other reactions in LeapLife, based on what is currently known? Confocal (talk) 07:04, 23 April 2023 (UTC)
If someone is interested in doing so (without going into too much details), go for it. (And indeed there are a non-zero amount of catalysts in LeapLife, if not much.) I would hestitate to mention reactions that are essentially due to the B2n or S3-q, though. Ultimium (talk) 02:08, 24 April 2023 (UTC)

Looks like there are a few to-be-done sections now. Since I don't know much of writing wiki pages, is anyone interested to help me? Ultimium (talk) 01:35, 25 April 2023 (UTC)

A problem that I encountered while making the methuselah list: Do we usually remove non-interacting cells for methuselahs from soup search? Especially when no one has done the minimalization at that time. Ultimium (talk) 02:58, 25 April 2023 (UTC)

A modest proposal

Any objections to boldly moving the LeapLife page to the OCA namespace? This would make it beneficial to the wide public of people interested in LeapLife (and not just relatively few enthusiasts who already know where to look). Then further discussion of incompleteness/improvements can go directly on the talk page of the article. (And this Tiki bar section would gradually become inactive and go to archives.)
Of course, one might say that the page is incomplete -- but then again, I doubt there are many "complete" articles on LifeWiki. In some sense everything here is a work-in-progress. Even seemingly "mission-critical" articles like Conway's Game of Life or HighLife are incomplete, in the sense that I can imagine how those pages could be expanded further. Confocal (talk) 03:52, 25 April 2023 (UTC)

I would prefer to fill in all the "(TODO)"s first. Ultimium (talk) 04:11, 25 April 2023 (UTC)
Additionally, I would like to hear other people's opinion on the content. There is currently a lack of discussion. Ultimium (talk) 04:22, 25 April 2023 (UTC)
Re "(TODO)"s: understood -- I just wanted to say that this discussion could potentially continue indefinitely long, because it's always possible to improve something.
Re: lack of discussion: this is usual (and I think it's to be expected) for on-wiki discussions. There are often few (if any) quick responses. Partly this is because the community is small, and even fewer people have LifeWiki accounts. Partly this may be because the content of the article could just as well be discussed on its talk page over time -- Tiki bar is probably best reserved for "large-scale" questions that are relevant to multiple different pages, or the way the website functions, etc. Confocal (talk) 04:30, 25 April 2023 (UTC)
Indeed; If you think it might be appropiate to move this discussion to User talk:Ultimium/OCA:LeapLife and/or continue the discussion about the page on User talk:Ultimium/OCA:LeapLife, I would do so.
The lack of discussion is not just applicable to this page; I think not many pages on LifeWiki took comparable effort to most articles on Wikipedia. That might be because the nature of LifeWiki, most articles are stubs and it is a stub because there are not much to write about it. But I definitely would like to see more well-written pages with people discussing. Ultimium (talk) 06:33, 25 April 2023 (UTC)\

I would prefer to have someone else to move the page, but since no one is replying, I'm doing the next best thing: If no one objects or make major changes to the page, I'm moving it to the OCA namespace. Ultimium (talk) 05:20, 27 April 2023 (UTC)

I went ahead and moved it, just to keep anyone else from agonizing over it further. I left a redirect for now, since there are some leftover links to it multiple places.
(If you did move it yourself, then someone might complain about that, citing the "don't document your discoveries" guideline -- even though several other people did in fact significantly contribute to the LeapLife article. However, now a mere mention of "don't document your own stuff" will not suffice; any further objection would have to be an objection to my judgment call.) Confocal (talk) 06:01, 27 April 2023 (UTC)

Regarding the censuses

Many pages for stable objects, such as Octagon 2, state their commonness with their rank among all objects in Achim Flammenkamp's census, then their rank among only oscillators in Catagolue. Is the reason for this that infinite-growth patterns are excluded in Achim's census, or that it's meant to be more representative of the dynamics of ash in an infinite non-sparse universe? Is this truly worth it having (at present) (159214128553422*162)/(1829196*20482)>5312 times fewer initial random cells simulated and (159214128553422*162)/(1829196*20482*(-(1-0.375)*log2(1-0.375)-0.375*log2(0.375)))>5566 times fewer bits of entropy?

Should this information, when only given in the form of a commonness rank (and sometimes also expected number of soups per occurrence), have an infobox section instead?

Also, speaking of which, what should be done with the pages for strict still lifes with the sections stating that all with sufficiently few cells (including them) are known to be constructible within a maximum number of gliders? These aren't useful, surely, to duplicate information so much, can we assume that people looking for this information (that is numerical and conducive to being presented in tabular form) will go to Catagolue instead? Especially those with apgcode-only titles, pages here aren't necessary for lookup by conventional name if they have none. DroneBetter (talk) 13:51, 9 December 2022 (UTC)

Re: infobox -- my preference would be to leave the commonness/occurrence information in plain text. The infoboxes are already long enough, so that they often conflict with sufficiently wide viewers not fitting to the left of the infobox, and it is sometimes necessary to reorder sections to avoid that conflict. As a consequence, I'd prefer not to make infoboxes even taller than they are. Stating what is known in the text also gives more flexibility. Confocal (talk) 14:13, 9 December 2022 (UTC)
Re: synthesis -- the glider synthesis sections of pages could contain information not only about the current cheapest synthesis cost, but also historical information about when the synthesis was found, and also about previously known / alternate syntheses. Here is an example: Krake. I'm slowly adding this kind of information to pages. I think this is useful and interesting to readers - instead of just the cheapest glider cost, show the syntheses themselves and tell when/how these were found. Confocal (talk) 14:13, 9 December 2022 (UTC)

Should LifeWiki be more like the chessprogramming wiki?

It contains things like an article on general algorithms and others on things like bitwise operators (that don't pertain inherently to the nature of the problem it documents (playing chess as well as possible with finite resources), but are useful to human endeavours to solve it), should we have some (covering things that arise frequently enough in the study or implementation of cellular automata to be worth detailing with more specifics than Wikipedia) also?

Specifically, should there be pages here with contents of at least some of the sections of Tutorials/Coding Life simulators, in the instructive style of the other tutorial pages on how to set up and use various other software? Perhaps also one on writing simple row-based search programs that find oscillators and spaceships in equivalent multistate Wolfram rules for given widths in 2D ones. If we had one explaining the idea of David Buchanan's simulator (not the specifics of the conversion to YUV4MPEG but the simulation, using it as a basis for teaching (being that Python is a simple language to read, though it has doubtless been thought of before)), and perhaps even some of the ideas in my fork, perhaps such a page could link to the Stanford bit-twiddling hacks page (which may be of a great deal of interest to the kinds of people who'd be interested in such articles), or even an intermediate page here? I could create such an explanation of Buchanan's and my programs in my user area, then see whether it's deemed sufficiently useful to be moved to the mainspace, if anyone would like. DroneBetter (talk) 01:16, 13 December 2022 (UTC)

There are some forum discussions that seem relevant to the idea of documenting various interesting technical details of algorithms e.g. Searching algorithms, Re: 3c/7 othogonal and 2c/9 diagonal spaceships, Re: Beta Reader Thread for Game of Life Textbook and others. I personally like the idea -- if someone understands something and can explain it in words, why not do that? Confocal (talk) 04:39, 13 December 2022 (UTC)
I don't know enough about those to do so (though I hope to one day), however I have made Tutorials/Coding Life simulators/bitwise SWAR Life (covering my program up to the three different simulation modes and implementation of manifolds), being that I have some more time on my hands now I think I will make another regarding the application of the Pólya enumeration theorem to implementing efficient indexing methods for binary matrices under symmetry eventually (after finishing and optimising and cleaning my program for that), if it's okay
Since the user Magma from the ConwayLife lounge taught me about the Pólya enumeration theorem, I made my "eightfold reducer" its own program (much was made when I was relatively new to Python and the rest only as a proof-of-concept, I will eventually get around to cleaning it up (optimising and reducing some things) and adding the rest of the class methods), it was originally only an implementation of my idea for exhaustively generating single canonical representations of nonequivalent states under symmetry in square boards (more efficiently than iterating over all states and discarding those that are not their own lexicographically-minimal orientation), but that I realised could have efficient indexing methods using the theorem, and I more recently made a "dimensional INT enumerator," originally for confirming the number of 3D Moore transitions in the INT rulespace table and supporting arbitrarily many dimensions but then today modified for returning closed forms for numbers of nonequivalent binary hypercubes in terms of width using the theorem, given a number of dimensions (see the comment on the gist for a brief explanation). Being that the first one only pertains to cellular automata slightly (ie. the indexing methods are useful for parallelisation, initialising the threads at the beginnings of different slices of the search space (that would be able to proceed through with the even more efficient next() method)) and the second only extremely tenuously (and to a more theoretical area of the study of cellular automata), would it be okay for me to make articles about their ideas (and explaining their implementations' specifics (such that the pages contains within them both a set of instructions to implement the idea and documentation of a functionally complete demonstration), like I did in the bitwise SWAR Life page)? DroneBetter (talk) 03:56, 30 December 2022 (UTC)
I have made Pólya enumeration theorem and Tutorials/Coding Life simulators/eightfold reducer now :-) DroneBetter (talk) 17:51, 2 January 2023 (UTC)

Attempting to show huge patterns in infoboxes

What is the current consensus on attempting to show huge patterns in infoboxes (with the alternative being to display the pattern in a viewer inside the text)? I am not sure whether changes like this or this are improvements. It seems like infoboxes work better for small patterns. Confocal (talk) 00:00, 20 December 2022 (UTC)

And some bigger patterns end up looking like smudged fingerprints in the infobox. But I think we need the categorization that follows from infobox, as well as the standard presentation. Maybe do both presentations? And while we're at it, maybe agree on a max width for whatever is shown to the left of an infobox? Book (talk) 17:55, 20 December 2022 (UTC)
I think it would be much better to have some reasonable upper limit on the width of the infobox itself, to leave enough space for the main part of the page. The automatic categorization could in principle be done in a completely invisible way without enforcing any particular layout/presentation (e.g. see {{Glossary}}). I'm not convinced that all pages need to be indiscriminately converted to infobox-based layout - being able to explain/describe/show the pattern in some reasonably good way is more important than any "standard presentation". Sufficiently large patterns simply do not fit well in the infobox. Some patterns may be better shown as images or schemes, and/or by explaining/describing/showing smaller components. Confocal (talk) 19:00, 20 December 2022 (UTC)
OK, I see the issue and the benefit. Hiding the infobox in these cases would be good, if 1)the data in the hidden infobox still functioned as usual in terms of all the things it triggers; 2) the article displayed important infobox data in its text. How does one do #1? Book (talk) 23:57, 6 January 2023 (UTC)
No significant updates so far, just adding links back to related forum posts for future reference: p158434 p158438. Confocal (talk) 05:43, 6 March 2023 (UTC)

Regarding programming language syntax colouring support in code blocks

It would greatly benefit Tutorials/Coding Life simulators/bitwise SWAR Life and Tutorials/Coding Life simulators/eightfold reducer if we were to have this. Also, how do I prevent linebreaks followed by indentation (which appear often in my programming, as you may expect) causing code blocks to generate others nested inside them? Neither <pre> nor <code> seem to allow this. And is there a way to have inline monospaced text (ie. without line breaks) like the Python docs? DroneBetter (talk) 17:51, 2 January 2023 (UTC)

Addendum: The second question's answer is <tt>, I have since learned. DroneBetter (talk) 00:02, 26 May 2023 (UTC)
What about <blockquote><pre>...</pre></blockquote>? Confocal (talk) 17:58, 2 January 2023 (UTC)
class Thingy:
   pass

def example():
   print("Hello World!")

Regarding "known" information

For instance, List of period-2 oscillators with 17 cells says there are 199 known such oscillators, implying that the explicit examples provide only a lower boun, however A056614(17)=199 and Mark Niemiec had a section of a page, entitled The 199 seventeen-bit period 2 oscillators, do these count as sufficient sources in and of themselves or should a program be provided to act as proof of the nonexistence of any more? As mentioned above, I cited my program for the confirmation of the disputed number of 3D INT transitions in the table, should this be the convention for proofs of other such values that are given in pages but currently imply that they're only accurate to as far as is known and not objective?

I don't think the OEIS would add values not known to be correct (assuming no bugs in implementations), being that they say "Thousands of people use the sequence database every day. Please take great care that the terms you send are absolutely correct. The standards are those of a mathematics reference work." as you edit a sequence, but A231427 was amended with the discovery of the rattlesnake, so perhaps not too rigorous when it comes to Life matters. — Preceding unsigned comment added by DroneBetter (talk • contribs) 21:55, 3 January 2023‎

Added the two references to pages for 17 cells and for 18 cells -- these links seem to be useful as ways of helping the curious reader to find more information. I think it is safe to leave "known" in -- a computer program may have bugs, a mathematical proof may have gaps, and so on. Confocal (talk) 05:18, 6 March 2023 (UTC)
Related to "known", see also LifeWiki talk:Did you know/78#Proof of "the only still life"?. Confocal (talk) 09:45, 6 August 2023 (UTC)

Single column vs Two columns of EmbedViewer

What is the reason to restrict layout to stacking all {{EmbedViewer}} in a single column like in this edit? That could made the page overly long with much whitespace around. Well, I am not suggesting possibilities for three or more columns — which would made the page too wide — I am just curious about the case of two columns. GUYTU6J (talk) 14:42, 5 March 2023 (UTC)

Actually, I prefer three, which is what I use on my userpages. HotdogPi (talk) 15:04, 5 March 2023 (UTC)
The question in the first sentence appears to be about the specific edit. As explained in the edit summary, it is a revert to a single column. The reverted edit is a previous edit made by someone else (diff=126024&oldid=111614), changing the layout from single column to double column, with false edit summary stating "The last version still looks too wide for me". The edit summary is false, because the edit made the gallery more wide, not less. Confocal (talk) 15:13, 5 March 2023 (UTC)
More generally for the main/OCA namespaces, single-column galleries are preferable, because a two-column gallery already does not fit to the left of the infobox. For galleries in later sections of the page that can be reasonably assumed to appear strictly below the infobox on all devices, two columns could be used. Three columns are already too wide, even without the infobox. Confocal (talk) 15:13, 5 March 2023 (UTC)
By "looks too wide for me" I meant individual viewers, not the sum of two. Is there a demonstration for a two-column gallery failed to fit to the left of infobox? GUYTU6J (talk) 15:23, 5 March 2023 (UTC)
https://conwaylife.com/forums/viewtopic.php?p=158624#p158624 Confocal (talk) 15:44, 5 March 2023 (UTC)

Is there a potential way to make it change based on screen width? On my screen, 5 columns easily fit to the left of the infobox, and 1 column leaves a ridiculous amount of white space. --Galoomba (talk) 07:33, 29 March 2023 (UTC)

For static images only, the <gallery>...</gallery> tag should work (example). For embedded viewers, I'm not aware of any existing solution.
See also a forum thread for all infobox-related issues/discussions: link. Confocal (talk) 09:29, 29 March 2023 (UTC)

Adding kinetic symmetry to infoboxes

Currently, pattern symmetries are tracked by an invisible template at the bottom of the pattern page which does nothing other than add a category. I don't like this, since it's in stark contrast to every other pattern statistic which is tracked in the pattern infobox. However, the current system is in place for basically every oscillator and spaceship with time symmetry, so moving things to the infobox would take a long time and require a lot of changes. I think it'd be worth it, however, since kinetic symmetry is currently only described in the currently rather obscure kinetic symmetry page. Having this in the infobox would direct more traffic to that page, increase the understanding of kinetic symmetry in the Life community, and also make the symmetries of patterns far more obvious and clear since people wouldn't have to sift through the twenty categories each pattern is in to find out what each pattern is classified as.

Any thoughts? - AwesoMan3000 (talk) 10:54, 7 March 2023 (UTC)

It's doable. However, a script that does it automatically would also need to look at the bounding box, as the templates don't distinguish between odd and even symmetry. HotdogPi (talk) 14:03, 7 March 2023 (UTC)
Would a script even be able to distinguish between a D2_+1 pattern that flips across the edges and vertices of cells (-f+e) and a D2_+2 pattern that flips through the faces and edges of cells (-e+e)? Both are orthogonally flipping oscillators which would have odd by even bounding boxes. - AwesoMan3000 (talk) 14:24, 7 March 2023 (UTC)
I like the idea to add specific kinetic symmetry to the infobox (and perhaps create corresponding categories for every possible value, so that objects with a given symmetry can be viewed).
However, on the other hand the infoboxes are already quite tall, and significantly reduce the available width for the main content that is located in the beginning of the page.
Given that there are several related-but-distinct issues with infoboxes (as evidenced by the Tiki bar), would it be possible to discuss infobox-related questions as part of a broader discussion of infoboxes (perhaps preferably on the forum rather than on the wiki, so that forum members without LifeWiki accounts could reply as well)? Confocal (talk) 06:55, 8 March 2023 (UTC)
A forum thread for infobox-related issues: link. Confocal (talk) 06:19, 26 March 2023 (UTC)

"Oscillators made of still lifes"

I was perusing Catagolue (by means of my program), and found a D4_+1 oscillator comprised of still lifes, already named the half-tub harbour, that also has rarer (single-occurrence) C4_1 and D4_x1 variants. There wasn't any result for "oscillator made of oscillators," only Constellation (which seems vaguely fitting but not very), should a page be created dedicated to oscillators that are separable into still lifes (that hassle each other) in at least one phase? Are there any other such cases to document? DroneBetter (talk) 22:50, 28 March 2023 (UTC)

Amendment: I didn't notice the much more common D8_1 occurrence (due ot it having lower volatility and not appearing in my sortings) — Preceding unsigned comment added by DroneBetter (talk • contribs) 23:40, 28 March 2023

Apologies if the following is a bit off-topic; one interesting kind of oscillators is those where several consecutive phases consist of nothing but gliders and stationary objects, in such a way that the oscillator permanently becomes a strictly-lower-period pattern if all the gliders are instantly removed from one of such phases. These oscillators look quite cool and may well deserve a dedicated collection. Here's a recently posted alien example: post159731 (Catagolue). In Life, several examples are the p143 Bandersnatch loop (and its period-doubling stabilisation), this p253, this p160, the (capped) period-563 glider gun. There should be more examples, even not counting adjustable glider shuttles. (And even more, if the requirements are relaxed to allow any oscillators with temporary internal well-separated gliders.) Confocal (talk) 06:36, 29 March 2023 (UTC)

Another example is a p182 honey farm hassler (forum post, Catagolue). Confocal (talk) 11:17, 9 August 2023 (UTC)

Pauses in glider syntheses

Why do most glider synthesis LifeViewer embeds have pauses in them? I get it's to see important intermediates (although sometimes it pauses before the gliders even collide) but it's really awkward to watch.
On a related note, why do they all have a copy of the final object on the right side? Seems redundant. --Galoomba (talk) 09:02, 9 April 2023 (UTC)

Some (not all) glider syntheses have pauses in them, because I decided to add pauses in them. I'm not aware of any previous conventions regarding of how exactly to represent glider syntheses on LifeWiki. The relatively long pause T = 20 (before the gliders collide) in particular is so that it is visible where each glider comes from, and it is easier to see that the synthesis is rewindable.
The reason behind adding a copy of the (stationary) final object is because Mark Niemiec's glider synthesis database does this, and I did not really want to invent something entirely new from scratch, when there are existing tested ideas that can be reused in this context. Confocal (talk) 09:22, 9 April 2023 (UTC)
How does the pause at T = 20 do anything that the pause at T = 0 doesn't?
You don't need to invent anything new. Just show the synthesis. --Galoomba (talk) 16:35, 25 April 2023 (UTC)
Please don't modify formatting in other replies. Especially in this case, this makes it confusing and hard to view the reply by looking at the diff of the change. Confocal (talk) 16:45, 25 April 2023 (UTC)
I'm intentionally inserting the pause T = 20 before the gliders collide, so that it is visible where each glider comes from, and it is easier to see that the synthesis is rewindable. The pause at T = 0 does not highlight rewindability. Confocal (talk) 16:48, 25 April 2023 (UTC)
If this can be useful for setting future guidelines, I think I could write a more detailed explaination for my particular choices when formatting syntheses. Earlier I already asked about that on Tiki bar, but got no response there so far. Confocal (talk) 09:21, 9 April 2023 (UTC)

User:Confocal, I'd like to bring this up again. You seem to be inserting pauses in syntheses because that's how you personally best see the things you personally look out for. That might work well for you, but you can't assume other people work the same way. I find the pauses very disorienting. (It would be nice to get the opinions of some other people here.) --Galoomba (talk) 09:04, 26 May 2023 (UTC)

I'm trying to format syntheses in a consistent way. It is possible that there's a better presentation, but this question would be something that's best discussed once for all affected pages, rather than arguing about presentation for individual pages. Otherwise, any other possible formatting is subject to the exact same critique: without general guidelines, any possible formatting is "just some editor's opinion on what works best".
There are lots of different possible ways how one could show a glider synthesis with a LifeViewer applet. To give some examples: (a) non-animated pattern; (b) looped animation without any pauses; (c) looped animation with pauses (several variations depending on where you add the pauses); (d) non-moving gliders that are animated for e.g. 20 ticks and then stopped with visible reaction envelope to highlight where each glider comes from.
For the record, my own preferences can be seen in pages where I added syntheses. The pause at T = 0 is so that the gliders don't immediately begin moving after appearing out of nowhere. The pause at T = 20 is to give some time to look at the non-moving synthesis (with visible traces behind gliders). The final pause at the end is to give time to see the final constructed object before restarting animation. Other pauses are between intermediate steps for multi-step syntheses, or to show "interesting" intermediate unstable objects (e.g. symmetric phases). Confocal (talk) 09:39, 26 May 2023 (UTC)

I'd just like to interject that I find the pauses in patterns extremely annoying. The Silver reflector infobox pauses for two full seconds at each Herschel intermediate, which is sufficiently long to get frustrated. A half-second pause would be much better, or maybe a second at most, but a two-second pause is excessive. Calcyman (talk) 12:04, 26 May 2023 (UTC)

For reflectors and conduits, I suggest to leave the infobox viewer non-animated. I think there is no obviously good way to animate a conduit (outside some larger pattern) that would not make the resulting animation non-intuitive or disorienting in some way to some significant subset of readers.
One alternative is to show a pattern where the conduit accepts a continuous signal stream that comes from outside the frame, and the output signal(s) leave to somewhere else. That pattern will be different from the subject of the article, so it could be shown outside the infobox. For example I already did this in Rectifier article. Confocal (talk) 18:58, 26 May 2023 (UTC)

In case this Tiki bar discussion settles into some guidelines on how to format glider syntheses, then I believe it will be relatively easy to convert all existing glider syntheses to follow the new guidelines. Assuming I'll still be active here by that time, I may be able to do the conversion myself. (It'll be just boring and repetitive, but hopefully non-controversial by that time.)
To keep consistency in those articles where I'm adding syntheses, before the end of discussion I'm going to use the same formatting as I used earlier. (Briefly: short pause at T = 0, longer pause at T = 20 before collision, short pause at the end, repeat. For multi-step syntheses, also short pauses between steps.) Confocal (talk) 20:01, 27 May 2023 (UTC)

Volatility rounding

Seems like volatility is rounded to two decimal places, and there are categories for each of those. But is it rounded up, down, or to nearest? This also applies to heat. --Galoomba (talk) 16:54, 21 April 2023 (UTC)

Autostart

User:Confocal, you removed AUTOSTART in viewers on Raucci's p38. Why? --Galoomba (talk) 23:42, 4 May 2023 (UTC)

As explained in the edit summary, I disabled animation in Gallery/LCM sections on that page. The reason is the same as already explained before for another page: there are multiple viewers on the page, hence it seems better to not make all of them continuously running animation. In this case, I stopped all viewers in galleries and left "singular" viewers running, just because that was a simple solution. Confocal (talk) 00:04, 5 May 2023 (UTC)
I guess the "real question" is not this particular page, but rather when to animate and when to not animate. When there are many viewers on a single page, AUTOSTARTing them all makes the page slow. Confocal (talk) 00:04, 5 May 2023 (UTC)
Does it actually make the page slow or are you just guessing? A few low-resolution 10fps animations shouldn't have a significant effect on performance. --Galoomba (talk) 22:48, 19 May 2023 (UTC)
Yes, each added animated viewer does actually make the page noticeably slower. Apart from that, animation draws attention which is another reason why too much animation is bad.
Unrelated: please do not "fix" markup in my replies. Confocal (talk) 22:54, 19 May 2023 (UTC)
Using indents for replies is convention on Wikipedia, is there a different convention here? --Galoomba (talk) 23:05, 19 May 2023 (UTC)
There are no hard-and-fast conventions here as far as I know, apart from the general convention to avoid editing replies by other people. LifeWiki is not Wikipedia, but for completeness here's the relevant quote from Wikipedia (Wikipedia:TPO):
"It is not necessary to bring talk pages to publishing standards, so there is no need to copy edit others' posts. Doing so can be irritating. The basic rule, with exceptions outlined below, is to not edit or delete others' posts without their permission." Confocal (talk) 23:14, 19 May 2023 (UTC)
From the same page:
"Examples of appropriately editing others' comments
[...]
Fixing format errors that render material difficult to read. In this case, restrict the edits to formatting changes only and preserve the content as much as possible. Examples include: fixing indentation levels, removing bullets from discussions that are not consensus polls or requests for comment (RfC), [...]" --Galoomba (talk) 23:26, 19 May 2023 (UTC)
The basic point remains: don't edit other's replies without their permission.
Wikipedia is a much bigger project (compared to LifeWiki), and it naturally has a larger set of detailed rules and exceptions. Confocal (talk) 23:36, 19 May 2023 (UTC)
I'm not editing the replies though. --Galoomba (talk) 17:40, 20 May 2023 (UTC)
I replied on your talk page: link. Confocal (talk) 21:18, 20 May 2023 (UTC)
What exactly do you mean by "making the page slower"? --Galoomba (talk) 23:07, 19 May 2023 (UTC)
I mean literally that the page becomes slower. A continuously running animation is a running computation and it slows down everything that runs. I think a few "small" animations or a couple "large" animations per page should suffice in most cases. Beyond that, either most or all viewers should remain non-animated (e.g. in large unstructured galleries, it seems reasonable to leave all viewers non-animated), or some content with viewers should be moved/split into a separate page where there are fewer viewers and so some of them can be animated. Confocal (talk) 23:14, 19 May 2023 (UTC)
What is there on the page, except the viewers themselves, that can become slower? The rest of the page is static. --Galoomba (talk) 23:26, 19 May 2023 (UTC)
I think I already answered the question above. Confocal (talk) 23:36, 19 May 2023 (UTC)
You said "everything that runs". But the viewers are the only thing that's running. --Galoomba (talk) 00:39, 23 May 2023 (UTC)
Only if you count things that are shown on the page itself, and do not count the browser itself and other running things in the system. And even then, my points above remain valid: (a) every added running animation slows down everything that runs (including every running animation), (b) every added running animation is an added distraction that draws attention to it and decreases helpfulness of other animations. Confocal (talk) 01:08, 23 May 2023 (UTC)

Inconsistent names

There are cases where a still life or family of still lifes has several different names and the wiki uses different ones on different pages. Examples include long snake vs python siamese snake and melusine vs long fuse with two tails. Should these be renamed? --Galoomba (talk) 01:01, 28 May 2023 (UTC)

For the first example above, see earlier discussion: Talk:Python siamese snake (I'm not repeating here to not make reply very long). Second example above is more interesting.
Niemiec's Life Page (p1.htm, lifesrch.htm) gives names "11.16; Long fuse w/ two tails" for the 11-bit still life and "10.14; Fuse w/two tails" for the 10-bit still life.
The current Catagolue names are "Long melusine" for the 11-bit still life (xs11_17842sg) and "melusine" for the 10-bit still life (xs10_ggka23z1).
I'm not sure whether any page moves are needed, because there's no obvious benefit in using either of two names. I suggest move from Long fuse with two tails to Long melusine, to prefer a shorter name that also matches the Catagolue name.
I think such questions are hard to resolve "in general" -- there are different kinds of consistency. For individual pages, you can check edit history/move logs/talk pages to see previous relevant events, and check Niemiec's Life Page/Catagolue/forum search to see which names are used. Confocal (talk) 06:43, 28 May 2023 (UTC)

Still lifes vs still lives

This edit finally motivated me to ask about this on Tiki bar. Which variant should be preferred on LifeWiki? Might be a simple issue, but it's nice to be able to link to an existing discussion from edit summaries/any future discussions. (Note that both variants are in common use: forum search for "still lives", forum search for "still lifes".) Confocal (talk) 07:32, 28 May 2023 (UTC)

The Still life page says the plural is "still lifes". --Galoomba (talk) 08:01, 28 May 2023 (UTC)
Yes, that footnote was added by someone a few months ago, but I don't know if it was previously discussed anywhere before being added. After all, "still lives" as a plural of "still life" easily can be a valid domain-specific usage, as opposed to "still lifes" as a plural of the more popular still lifes. Confocal (talk) 08:13, 28 May 2023 (UTC)
Yeah, that etymology feels a bit sus to me. --Galoomba (talk) 08:31, 28 May 2023 (UTC)

Regarding One-dimensional cellular automata and a potential article on generating functions

I know there has been the discussion of Template:LinkWeisstein's removal, which is regarding his Life pages, but the different Wolfram Mathworld (originally known as Eric Weisstein's World of Mathematics) has resources on many of the rules. We have Template:LinkMathworld, should links to it be provided in Rule 22, Rule 54 and Rule 110, and in their own column in the table in my Wolfram rule page? Is there any reason (similar to that of LinkWeisstein's deletion) why they don't have links to it currently?

Also, we have Pólya enumeration theorem[1D 1] and Modular congruence[1D 2], however what would people say about a page regarding generating functions? I would like to mention (in a rewrite of bitwise SWAR Life) a fact of which I was informed, that a number with a binary representation comprised of n 1-bits, at intervals m bits apart, is (2n*m-1)/(2m-1) (computable as ⌊(1<<n*m)/((1<<m)-1)⌋ for all intervals m>=2),[1D 3], and it occurred to me that (though the Wolfram rule page currently only contains multivariate generating functions over x and y) the sequences encoding states from single cells as binary integers, which have closed forms in terms of linear combinations of powers (and thus generating functions) in more well-behaved rules (like Rule 28, where A001045(n)=(2n-(-1)n)/3=(1<<n|n&1)//3), are based on a similar idea. There is also the modulo-2 case noted in Pseudo-random number generator, though I'm biased in favour of such an article (due to my love for the OEIS) and am not sure how tenuous the relationship with the wiki's purpose would otherwise be. Can I get anyone's blessing to put it in the mainspace, if I am to create it? DroneBetter (talk) 22:52, 7 July 2023 (UTC)

Certainly I may be wrong on this, but I think "the relationship with the wiki's purpose" hits it. If the subject of generating functions does appear in cellular-automata-related discussions, then yes, that can make it useful to have a page explaining it. (In fact, I redlinked Modular congruence for this reason -- this is an idea that commonly appears in CA-related discussions, to the point that it is discussed in the textbook, as mentioned above. So I think Modular congruence has its place in LifeWiki.) Confocal (talk) 23:54, 7 July 2023 (UTC)

Notes

  1. ↑ I was told a few months ago that someone in the ConwayLife Lounge noted this page, asking whether it ought to be deleted, however I have recently rewritten much of it (since I originally didn't know how to do inline monospacing or superscripts (which are somewhat relevant when involving nested exponentiation :-), instead having then used Python-like ** syntax), I hope it is now acceptable.
  2. ↑ I created this due to it being redlinked in several places by Confocal, before learning this to be because it was already the name of an appendix in Conway's Game of Life: Mathematics and Construction.
  3. ↑ This allows the bitmask generation to be done much more concisely than my previous method (where m=1<<l), reduce(lambda r,i: r|r<<(1<<i+l),range(n.bit_length()+l-1),1)&~(~0<<(n<<l|1))), which ostensibly takes O(n*m) time (due to bitwise operators on length-n integers being O(n) and the convergence of ∑_{n=0..∞}(2-n)) instead of O(n*m*log(n*m)), but in reality will probably always be slower in Python.

"Cellular Automata FAQ"

I happened upon [1] recently. It was created at about the time of comp.theory.cell-automata, as it seems, and is quite in-depth (and contains some answers from notable people like Harold McIntosh (now deceased)), but isn't linked to anywhere on the LifeWiki. It seems to be unmaintained now, but says (in the main directory) that "a text version of the FAQ" was intended. Being that we have had our project to preserve LifeLine (and convert it to use nicely-formatted diagrams), is it notable enough that a copy of it should be added here also? DroneBetter (talk) 22:52, 7 July 2023 (UTC)

I support the idea to preserve "Cellular Automata FAQ" somehow, if that's feasible -- how painful it is going to be? Maybe this could be a way to initialise the LifeWiki:FAQ idea with existing content.
E.g. I had the page threads/natural/0007.html bookmarked, which discusses possible rule formats, such as counting alive corners separately from alive edges when determining the new state of the central cell (so there would be 250 possible rule definitions -- from 0 to 4 alive corners, from 0 to 4 alive edges, and the central cell either alive or dead). I know this particular idea did surface several times in discussions, so it is notable -- but I don't think it is documented anywhere on LifeWiki. IIRC there was an existing abbreviation specifically for this type of rule definition (around 7 or 8 letters), but I don't remember what it was.
(Added later:) I think the abbreviation is CWCFSMNCA. Forum posts: p75323, p129786. Confocal (talk) 23:48, 7 July 2023 (UTC)

Moving large patterns out of infoboxes

As one can currently see in the recent changes, Confocal has moved the LifeViewer embeds out of infoboxes in

should they not have asked here before doing so? I liked them more the way they were, why does Confocal make edits with such arbitrary purposes? What is the benefit? DroneBetter (talk) 15:31, 3 August 2023 (UTC)

I believe it's because a viewer outside the infobox can have a greater width and height. HotdogPi (talk) 15:33, 3 August 2023 (UTC)
See https://conwaylife.com/forums/viewtopic.php?p=160959#p160959 for the previous discussion of infoboxes (and #Attempting to show huge patterns in infoboxes for an earlier Tiki bar discussion).
The main intent is to make viewers larger, and surround them with article text, without making the infobox wider. Confocal (talk) 15:39, 3 August 2023 (UTC)

Suggested deprecation of EmbedViewerRule

(Previous discussions: Template talk:Rule, Talk:Conway's Game of Life#Random soup)

I propose to phase out/deprecate the random soup animations that are shown on rule pages (such as Conway's Game of Life). Behind the scenes, those random soup animations are implemented via {{EmbedViewerRule}} template. Current issues include:
• The idea behind the template is flawed. Trying to illustrate an arbitrary rule by evolving a random (or "randomly-looking") soup does not do justice to the rule. For many rules, it does not make sense. Even when it does, a better illustration would be a specific pattern chosen by a human.
• When the reader clicks on the infobox viewer (intentionally or accidentally), the viewer expands directly on the page. This breaks the widely followed convention "when the infobox pattern is clicked, show the pattern in a new window". I tried, and could not find a way to fix this issue (see post164483)). Clicking on an infobox viewer should display a pop-up window (an example can be seen by clicking the infobox viewer in Glider).
• The initial soup takes only a small fraction of the available display area, and cells are very small. Maybe a randomly filled torus with larger cells would look better (this would not solve the other mentioned issues, though).
In general, I suggest to use some non-random pattern chosen by a human being to illustrate how the rule works (either shown as a separate viewer outside the infobox, or shown in the infobox via alternate functionality yet to be implemented). Confocal (talk) 11:30, 8 August 2023 (UTC)

Update (see post165674, change) Second issue should now be resolved, e.g. clicking the infobox viewer on the Conway's Game of Life page should show a popup window. Confocal (talk) 13:17, 24 August 2023 (UTC)
A popup window now appears on any rule page without even clicking. I don't think this should be happening. HotdogPi (talk) 13:25, 24 August 2023 (UTC)
Oops -- that was supposed to be fixed. I reverted the change in template for now. Does the same happen on the test page User:Confocal/Test3? Confocal (talk) 13:53, 24 August 2023 (UTC)
Yes, it still does on the test page. It's been removed from the normal pages, though. HotdogPi (talk) 14:07, 24 August 2023 (UTC)
Are you on LifeViewer build 1035 or later? You may need to hard refresh your browser. Confocal (talk) 08:10, 25 August 2023 (UTC)
1033. HotdogPi (talk) 14:11, 25 August 2023 (UTC)

Hopefully everyone's browsers are already hard refreshed. If this change happens to causes problems, it might be better to disable the animation by default. Confocal (talk) 06:29, 31 August 2023 (UTC)

For the current discussion, see replies starting from this page and later replies in the same forum thread. Confocal (talk) 01:47, 15 September 2023 (UTC)

Alternatives to hassler pages

Related discussion: Talk:Honey farm hasslers, Talk:Butterfly hasslers.

What are possible alternatives to grouping oscillators by the hassled sequence? One possibility is to create a single wiki page for each "medium" period, and group oscillators further by sections. (For low periods, it was already mentioned that there would be probably too many oscillators to list them all.)
One of the issues with the existing grouping in {{HasslerList}} is that oscillators of a specific period appear on multiple different pages. Another issue is that when the reaction switches between two or more common sequences, the same oscillator appears on two or more different pages (e.g. 84P199 is both an R hassler and a LoM hassler). Another issue is that "hassler" is not sufficiently well-defined. Confocal (talk) 02:32, 13 August 2023 (UTC)

Why would the "same oscillator appearing on multiple pages because the reaction switches between sequences" thing be an issue? It's not like we're finding one of such type every day. C28 (talk) 17:20 August 2023 (UTC)
I support the idea of having a page for each period. It also seems more useful - usually when you're looking for oscillators (say to use in a larger pattern) you'll probably be looking for oscillators of specific periods. --Galoomba (talk) 22:06, 22 September 2023 (UTC)
This seems like it would be better accomplished with a simple stamp collection like this one. I don't see a need to include such collections on the wiki. ~Sokwe 09:41, 23 September 2023 (UTC)
One stamp collection for every period could indeed be more convenient, if that is believed to be a viable alternative. (I think one stamp collection for all periods is way too big.)
One advantage of wiki pages is that patterns can be shown directly, without expecting that readers use Golly or other software to view the RLEs. Another potential advantage of wiki pages is that associated information (discovery info, related links) could be gradually added by multiple people. Confocal (talk) 09:52, 23 September 2023 (UTC)

Mass conversion of RLEs in EmbedViewers into headerless form

(Previous discussion: User talk:C28#Conversion of RLEs into headerless RLEs in EmbedViewer transclusions)

I think these edits are not an improvement. I suggest to revert back to the multiline form.
The headerless form makes a very long line, does not match the "copy and paste from Golly" form, and does not work for alien rules (you need header for alien rules). Confocal (talk) 16:44, 15 August 2023 (UTC)

Nah. The fact that the headerless lines end up in a long line of text is not a bad thing since the RLE's still function as they should. The point about the patterns only working in alien rules being negatively affected by the changes is somewhat moot since the patterns affected by the conversion to headerless RLEs were patterns that worked in B3/S23 (which is the rule that Lifeviewer seems to default to). C28 (talk) 17:03 15 August 2023 (UTC)
The point is that consistency is negatively affected by these changes -- it will not work in all cases. I think the preferred form of a RLE should be the result of direct copy and paste from Golly. Confocal (talk) 17:09, 15 August 2023 (UTC)
Consistency is not exactly a thing when it comes to a wiki. i've seen so many different forms of a citation, paragraph writing, order of sections and more. C28 (talk) 17:16 15 August 2023 (UTC)
Some kinds of useful consistency are possible / practical. This discussion is specifically about RLEs in EmbedViewer transclusions. Confocal (talk) 17:21, 15 August 2023 (UTC)
If it works, it works. Anything beyond that wouldn't be of much concern. C28 (talk) 17:29 15 August 2023 (UTC)
By that logic, wouldn't it be better to leave the RLEs in the multi-line form? They did already work, so the current bulk conversion into single-line form was not necessary (and perhaps increased the amount of stored data on the server, and cluttered the log of recent changes). Confocal (talk) 17:37, 15 August 2023 (UTC)
It's sort of a double-edged sword. The only reason i'm converting the RLEs into a single-line form is to reduce the size of the page. Sure that would "clutter" the changelogs, but any sort of edits (expanding, updating information, removing useless/redundant sentences, etc.) would too. C28 (talk) 17:48 15 August 2023 (UTC)
That's kind of why it's better to discuss "large scale" changes (that affect multiple wiki pages) before implementing them.
Something like fixing obvious typos in articles won't be controversial in most cases -- unless e.g. the intent is to preserve typos that were present in an original.
Something like converting every RLE to single-line form is more likely to be controversial. I don't remember previous discussions of this issue. Confocal (talk) 18:01, 15 August 2023 (UTC)
Well what exactly constitutes "large scale"? C28 (talk) 18:23 15 August 2023 (UTC)
Once is happenstance. Twice is coincidence. Three times is enemy action.
That said, there are some cases when multiple pages are affected but the change is very unlikely to be controversial/mistaken, and there are other cases when only a few pages are going to be affected but it's still better to discuss before changing. Confocal (talk) 00:08, 16 August 2023 (UTC)

Sides of torus.

Will it be better if people can see the sides of torus in the wiki? TYCF (talk) 08:23, 17 August 2023 (UTC)

I don't know what is meant by the sides of torus. I assume the question is related to Lightspeed bubble.
Personally, I like the new version; the animation shows the object in question moving through the background agar. In comparison, the previous version was not animated (and running it would show how the bubble eventually reaches the edge of the finite patch and everything is destroyed). Confocal (talk) 08:35, 17 August 2023 (UTC)
I mean will it be be better if people can see the grey box. TYCF (talk) 10:41, 17 August 2023 (UTC)
Also, do you think it is a good idea to make a collection of lightspeed bubbles in lightspeed bubble?TYCF (talk) 10:45, 17 August 2023 (UTC)

MediaWiki math extension

See also the Extension:Math page in the MediaWiki wiki

There was a talk between Nathaniel Johnston and Elithrion regarding the prospect of adding LaTeX support, which Nathaniel said was out of scope while it remained on its shared Windows host. It has been 5288 days (≈14.48 years) since then, would it now be feasible to do? I have a few somewhat formula-heavy pages that would look nicer if converted, namely Pólya enumeration theorem and the miscellaneous curiosities page in my userspace. I have created {{sum}}, {{product}}, {{lim}} and {{frac}} to make do with pure HTML (as can be seen in Big-Θ notation), but it would be nice to have things like brackets that change size to enclose fractions correctly, if you would, please. DroneBetter (talk) 22:50, 23 August 2023 (UTC)

Backward rake

Is it a good idea to make a redirect page named Backward rake and redirect it to backrake? ( A lot of people use it in the forums: [2]) TYCF (talk) 17:11, 27 August 2023 (UTC)

Go ahead. You generally don't need permission unless you're creating a whole bunch of redirects at once. HotdogPi (talk) 17:34, 27 August 2023 (UTC)

Thank you! TYCF (talk) 19:25, 27 August 2023 (UTC)

Red links

Should I create links to pages that has not been made yet? TYCF (talk) 06:56, 28 August 2023 (UTC)

If you know about notable topics that are currently missing from LifeWiki, feel free to create red links to the missing pages about such topics (so that other editors know the page is missing). Confocal (talk) 07:57, 28 August 2023 (UTC)

Thank you! TYCF (talk) 09:24, 29 August 2023 (UTC)

Alien pattern pages

(For previous discussion see Template talk:Spaceship, LifeWiki:Tiki bar/Archive/2020#LifeViewer and RLE on OCA subpages)
Yet another infobox-related question. Are infoboxes needed on pages about alien patterns in the OCA namespace?
My opinion is that it is better to use {{EmbedViewer}}/{{gallery item}} to show any patterns and add describing captions; unlike infoboxes, this also allows to put the RLE of a small pattern directly into the code of the article.
The current infobox infrastructure assumes that it is used in CGoL context; I think it would be better to create a separate infrastructure (if needed at all), instead of complicating legacy template code. Confocal (talk) 17:25, 4 September 2023 (UTC)

The point of templates is that the same code can be used in multiple places and modified all at once. Making a separate template for OCA infoboxes kinda goes against that.
Where does the infobox assume CGoL? Fields that aren't relevant for OCA (e.g. glider synthesis) can just be omitted.
And please stop instantly reverting other people's contributions. At least discuss first and/or provide an equivalent implementation if you think it would be better. --Galoomba (talk) 17:43, 4 September 2023 (UTC)
Your modifications to infobox templates are undiscussed large-scale changes, that's why I reverted them. It is up to you to convince others that these changes are useful, preferably by discussing before changing.
Making a separate template allows to get rid of any irrelevant fields, and/or add fields that don't make much sense for CGoL. The idea to use separate set of templates for alien patterns was already suggested in 2020: LifeWiki:Tiki bar/Archive/2020#LifeViewer and RLE on OCA subpages. That was neither rejected nor implemented. Confocal (talk) 17:51, 4 September 2023 (UTC)
The changes aren't exactly large-scale. There are only about a dozen pages for alien patterns on the wiki, and the changes don't affect any other page. (And I did not even change a single non-template page before you reverted my edits.) This is also a very hypocritical statement for someone who frequently makes undiscussed changes to hundreds of pages at once, many of which are way more commonly used than the OCA ones. --Galoomba (talk) 18:09, 4 September 2023 (UTC)
As the person who basically decided in the past that OCA pages don't get infoboxes, such as when I created the HighLife p7 and p10 pages: it was for technical reasons. I would have preferred them to exist. HotdogPi (talk) 18:17, 4 September 2023 (UTC)
Categories Category:Alien patterns and Category:Alien spaceships contain more pages, e.g. OCA:HighLife/Bomber. I think infoboxes are redundant for this class of pages -- {{EmbedViewer}} is simpler to add, it allows to add explanatory captions, multiple variants of a pattern, etc. without needing to fill a whole set of parameters at once. For short pages, galleries look more reasonable than an infobox that is longer than the main page content. Confocal (talk) 18:28, 4 September 2023 (UTC)
A lot of CGoL pattern pages have infoboxes longer than the main page. Also, you can have both an infobox and EmbedViewers - as most pages do, of course. --Galoomba (talk) 18:36, 4 September 2023 (UTC)
Well, my opinion is that a lot of CGoL pattern pages don't really need infoboxes. However, infoboxes on CGoL pattern pages are already taken for granted. This Tiki bar discussion is about pages about alien patterns, and in this case there is a choice between
(a)committing to the same legacy infrastructure (which will complicate templates further -- you'll need to mark non-CGoL patterns clearly, avoid irrelevant fields, add new fields, etc.),
(b) creating a new solution for alien pattern pages, that is simpler to implement (because of being specific to the context) and works better in this context.
My preference is (b), with galleries ({{gallery item}}) already usable as an existing solution. Confocal (talk) 18:45, 4 September 2023 (UTC)
OCA patterns aren't fundamentally different from CGoL patterns.
Like I've already said, you don't need to fill in irrelevant fields. And what new fields exactly would need to be added?
OCA are more general than CGoL, not more specific.
And again, your opinion is only your opinion, and if most people disagree with you, you don't get to stop them. --Galoomba (talk) 18:59, 4 September 2023 (UTC)
Alien pattern pages on LifeWiki are a more specific context, because the majority of pages on LifeWiki are (and will be) about patterns/ideas related to Conway's Game of Life.
At the very least, you will have to add a field to indicate that the pattern is not in Life (and change the display somehow accordingly, so that readers don't get confused about which patterns are in Life and which are alien). You will likely have to add a field to specify the rule. Then there are already several fields about rules (rulemin/rulemax/rulespecial), and questions about whether it makes sense to have them all. (See also Tiki bar discussions and archives.) Confocal (talk) 19:09, 4 September 2023 (UTC)
Readers won't get confused because the page is in the OCA namespace, that seems clear enough to me.
Rule fields already exist, so I'm not sure what the problem is. --Galoomba (talk) 19:17, 4 September 2023 (UTC)
The problem is that changes like this make existing templates (which are already fairly complicated to understand and maintain) even more complicated and harder to understand and maintain. Perhaps one could say "if you break it, you own it", except that doesn't seem to work here.
There are already galleries, which are more flexible than infoboxes, can be formatted in a relatively simple way, and do not require to fill a whole bunch of parameters. Confocal (talk) 19:32, 4 September 2023 (UTC)
That is not relevant to any of the message you're replying to. --Galoomba (talk) 19:43, 4 September 2023 (UTC)
That is relevant to the question of whether to reuse/extend existing infobox structure (with whatever comes with it), or to use a simpler/lightweight alternative that is easier to maintain.
You claim in edit summaries that "The changes have now been discussed, and more people agree with them than not.". I consider that misleading, since this Tiki bar discussion started only a few hours ago. I do not believe the changes to the templates were sufficiently discussed (or even well-understood) before pushing them forward. Confocal (talk) 00:03, 5 September 2023 (UTC)
Why not use the same templates? I don't understand what you mean by "extend", are you saying that OCA patterns have traits that CGoL patterns don't that would need to be accounted for? --Galoomba (talk) 15:06, 5 September 2023 (UTC)
One such "trait" is the rule itself (as you mentioned yourself elsewhere). The existing infrastructure assumes b3s23 by default (e.g. links to Catagolue object pages); the workaround is to append the rulestring to the apgcode so that the correct Catagolue object page is linked. (This would make "apgcode" imprecise as a description of the link -- it would be more precise to write e.g. "Catagolue object page" to describe that infobox field.)
Now, what about multistate rules, hexagonal rules, rules on aperiodic tilings, etc.? My point here is that "in general" there are few commonalities between rules that could be put into an infobox.
Also, the infobox pattern does not have an associated caption the way {{EmbedViewer}} does, leading to awkward expressions in the text like "... shown in the infobox" (which assume understanding of what an infobox is). I believe a free-form plain-text explanation of the rule, with embedded viewers/galleries (with explanatory captions), should be preferred to infoboxes. Confocal (talk) 15:32, 5 September 2023 (UTC)
> One such "trait" is the rule itself (as you mentioned yourself elsewhere).
Yeah, that should be sorted out, but it shouldn't be hard.

> Now, what about multistate rules, hexagonal rules, rules on aperiodic tilings, etc.?
I don't see the problem with those; sure, some fields don't make sense with some rules, but they can be omitted. And it's not like any patterns in those rules currently have pages.

> Also, the infobox pattern does not have an associated caption the way {{EmbedViewer}} does, leading to awkward expressions in the text like "... shown in the infobox" (which assume understanding of what an infobox is).
This is not specific to OCA.

> I believe a free-form plain-text explanation of the rule, with embedded viewers/galleries (with explanatory captions), should be preferred to infoboxes.
We're talking about pages for specific patterns, not rules. --Galoomba (talk) 18:23, 5 September 2023 (UTC)

Re: "We're talking about pages for specific patterns, not rules." -- correct; I meant patterns. Even though this is not specific to patterns (as opposed to rules) or alien topics (as opposed to CGoL topics), this applies here as well. Before committing to the whole idea of having infoboxes in the OCA namespace, it makes sense to consider more lightweight/maintainable/flexible alternatives. Confocal (talk) 18:41, 5 September 2023 (UTC)

To respond to a detail from Template_talk:Spaceship: confocaloid mentioned that 

The RLE namespace nontrivially interacts with downloadable LifeWiki pattern collection.

This is definitely true, but possibly not as big a problem as it might be -- depending on what our eventual goals are for oca.zip, the automatically-generated alien pattern collection.

At the moment, the downloadable pattern collections all.zip and oca.zip do not grow automatically whenever anyone makes an addition to the RLE namespace. They grow only when one of the LifeWiki moderators uses additional permissions granted by Nathaniel, to go to a separate upload page and upload patterns to be added to the downloadable collection.

The upload page used to require choosing patterns for upload one at a time (!) but that was recently adjusted to be up to 100 patterns at a time, which is much less painful. Still, currently the only system that prepares standard-format patterns for upload is the auto-upload script, which I'm currently running once a month to keep everything reasonably synchronized. That script currently only looks at references to pnames inside main-namespace pages, so for the most part it will only ever find new Conway's Life patterns that have been added to the RLE namespace -- nothing from other rules.

At this point it seems like an open question whether the LifeWiki will be able to successfully expand its coverage to include lots of patterns from other rules. As of today there are only 73 patterns in oca.zip, which is barely a drop in the OCeAn.

If there's some level of confidence that there will eventually be a lot of OCA patterns being added as separate articles, and that we'll be needing a more automated way to collect them -- then it might be good to have something like a separate OCARLE namespace, and set up an automated collection system for that namespace.

However, at the moment, there doesn't seem to be a whole lot of pressure to document dozens or hundreds of notable named individual OCA patterns -- we seem to be talking about a fairly small set. I'm not sure if I have the correct impression about that, but if I do, then enabling infoboxes for those exceptional cases might be a reasonable option for the time being. Separately, we could add any of those patterns to the oca.zip collection that are not in there already -- since that currently has to be a separate manual step in any case. Dvgrn (talk) 22:44, 4 September 2023 (UTC)

To repeat my thoughts from the above argument with Galoomba: I believe that embedded viewers and galleries ({{EmbedViewer}} / {{gallery item}}) provide a more flexible/lightweight/maintainable alternative to infoboxes. I don't believe infoboxes are needed or useful on OCA pages about alien patterns. (Even though infoboxes are used and "taken for granted" in the main article namespace for CGoL patterns, it does not follow that infoboxes should be used in the OCA namespace as well. My preference would be to remove the infoboxes added recently, and revert associated recent changes to the infobox templates. These changes are made without seeking consensus first, and I do not consider them to be improvements.) Confocal (talk) 21:14, 5 September 2023 (UTC)

Related discussion: https://conwaylife.com/forums/viewtopic.php?f=3&t=5981#p166560 Confocal (talk) 10:37, 7 September 2023 (UTC)

I'm not sure if I'm going to count as "someone else who does not have a strong preference one way or another" -- this was the wording from the edit summary from the latest set of reverts. I do think that infoboxes are sometimes kind of annoying. Infoboxes cause difficulties when a name applies not to a single pattern but to a class of related patterns, and there's no particular reason to pick one of those patterns over another (except maybe according to some "smallest" criterion, and that's almost worse because then the parameters in the infobox might end up having to be changed every time a new record is set.)
On the other hand, when names apply unambiguously to specific patterns, I think infoboxes are a fairly nice way to present them. After reviewing the pro and con arguments, I'm not seeing why OCA patterns shouldn't occasionally have infoboxes. The four cases that were reverted seem like good examples of unambiguous names where it would be okay to have an infobox. Given that consensus had been sought after an initial revert, I'm not at all clear why the second round of reverts happened.
It's true that consensus did not in fact appear, but on the other hand it doesn't seem as if any support for the original revert was expressed either. Doing another revert with the same justification as the first one, in the face of opposition from multiple people and in the absence of any support, seems like an action that's unnecessarily slipping down the slope toward an edit war. Dvgrn (talk) 17:01, 8 September 2023 (UTC)
Regarding recent changes, my proposal is to continue to avoid infoboxes on pattern pages in the OCA namespace. Infoboxes were not previously used on those pages, and there is no evidence that infoboxes are needed or useful for this class of pages.
Giving the same information in plain text with embedded viewers/images will always be more flexible/lightweight than filling an infobox. Unlike an infobox, plain text will work for any CA rules and for any unusual/weird patterns.
"Occasionally" would be problematic, because then it would be unclear when to add an infobox and when to not add it. Confocal (talk) 03:17, 9 September 2023 (UTC)

I'm going to redo the changes as this post by dvgrn makes it pretty clear that there is sufficient consensus. --Galoomba (talk) 21:12, 9 September 2023 (UTC)

Disagree -- the linked post does not say that there is consensus. Until now, only a few people responded. Further, the above reply makes it pretty clear that consensus did not in fact appear. Confocal (talk) 21:22, 9 September 2023 (UTC)
My wording was bad - dvgrn's post explains how the existing consensus is sufficient, one person disagreeing does not mean there isn't a consensus. --Galoomba (talk) 21:47, 9 September 2023 (UTC)
There is no existing consensus on this issue. One person actively trying to push the same changes to infobox-related templates does not mean there is a consensus.
Maybe give time to let other people respond as well, rather than (making this an argument between two active editors) and/or (trying to push your preferred changes as if there was already understanding and clear consensus for them)? Confocal (talk) 21:50, 9 September 2023 (UTC)
There is a existing consensus on this issue. 4-1 (me, dvgrn, galoomba, MEisSCAMMER) against you. One person actively trying to push the same changes to infobox-related templates... is you, and you're in the minority. HotdogPi (talk) 22:24, 9 September 2023 (UTC)
Neither "3-1" nor "4-1" would be a consensus to make changes from the existing state, given that there was not enough time to discuss these changes, and there was not much opportunity (the discussion places are filled by an argument between few active editors, giving little opportunity for others to respond and explain their opinions). https://conwaylife.com/forums/viewtopic.php?p=166737#p166737 Confocal (talk) 22:31, 9 September 2023 (UTC)
> given that there was not enough time to discuss these changes
How much exactly is "enough time"?

> (the discussion places are filled by an argument between few active editors, giving little opportunity for others to respond and explain their opinions)
This seems like a non-sequitur to me. --Galoomba (talk) 23:12, 9 September 2023 (UTC)

Back into the Future of the rulespecial parameter

There was Tiki bar discussion (link) where it was proposed to get rid of the "rulespecial" parameter in infoboxes. From looking at that discussions, it appears that there was consensus, but the proposed changes were not actually implemented.
(I also support removal of this parameter. Any information about "special" rules should be accompanied by an explanation of why these rules are considered "special", which would go in the main part of the article, and cannot really be packed into the infobox.) Confocal (talk) 13:00, 5 September 2023 (UTC)

I agree with its removal. HotdogPi (talk) 13:24, 5 September 2023 (UTC)
Makes sense, it's not objective info like the rest of the infobox. --Galoomba (talk) 14:59, 5 September 2023 (UTC)
I'm sure it made sense at the time, but I'd love to get rid of rulespecial. Dvgrn (talk) 23:33, 7 September 2023 (UTC)

I just removed the "rulespecial" parameter in two edits. Pages where the parameter is specified are automatically placed in category "Pages needing cleanup". Confocal (talk) 06:43, 16 September 2023 (UTC)

That is over 1400 pages (minus however many pages are in there for unrelated reasons). It makes sense to remove it iff we can automate it. --Galoomba (talk) 08:56, 16 September 2023 (UTC)
To clarify: the infobox parameter functionality is already removed, and "rulespecial" will not be visible for readers. The values that were specified in the markup are ignored now. Even though it is not strictly necessary to remove them from the source code of the pages, this can be made gradually, in combination along with other (more substantial) edits. Confocal (talk) 09:07, 16 September 2023 (UTC)
Yeah, that's what I meant. --Galoomba (talk) 10:15, 16 September 2023 (UTC)

LifeViewer speed

Why is the LifeViewer GPS parameter not working? --Galoomba (talk) 18:33, 7 September 2023 (UTC)

For LifeViewer issues, you might want to ask in https://conwaylife.com/forums/viewtopic.php?f=3&t=1622 or https://conwaylife.com/forums/viewtopic.php?f=4&t=4742 threads. I'm adding two test viewers in a subsection below. Confocal (talk) 19:06, 7 September 2023 (UTC)

Test patterns

x = 40, y = 15, rule = B3/S23 b2o5b2o20b2o5b2o$b2o5b2o20b2o5b2o2$17b6o$bo7bo6bo6bo6bo7bo$3o5b3o4bo8b o4b3o5b3o$o9bo5bo6bo5bo9bo$b3o3b3o7b6o7b3o3b3o2$4bobo26bobo4$b2o5b2o 20b2o5b2o$b2o5b2o20b2o5b2o! #C [[ THUMBSIZE 2 THEME 6 GRID GRIDMAJOR 0 SUPPRESS THUMBLAUNCH ]] #C [[ THUMBSIZE 2 ZOOM 8 GPS 4 AUTOSTART ]]
GPS 4
(click above to open LifeViewer)
RLE: here Plaintext: here
x = 40, y = 15, rule = B3/S23 b2o5b2o20b2o5b2o$b2o5b2o20b2o5b2o2$17b6o$bo7bo6bo6bo6bo7bo$3o5b3o4bo8b o4b3o5b3o$o9bo5bo6bo5bo9bo$b3o3b3o7b6o7b3o3b3o2$4bobo26bobo4$b2o5b2o 20b2o5b2o$b2o5b2o20b2o5b2o! #C [[ THUMBSIZE 2 THEME 6 GRID GRIDMAJOR 0 SUPPRESS THUMBLAUNCH ]] #C [[ THUMBSIZE 2 ZOOM 8 GPS 10 AUTOSTART ]]
GPS 10
(click above to open LifeViewer)
RLE: here Plaintext: here
It's fixed in build 1059. Hard refresh your browser to ensure you have it. Chris Rowett (talk) 23:00, 7 September 2023 (UTC)

Background grid for tracked moving objects

Can anyone confirm the distracting visual effect when background grid is visible and TRACK/TRACKLOOP is on? Perhaps tracking would work better with GRID OFF? Confocal (talk) 18:32, 9 September 2023 (UTC)

I do see an effect, but I'm not sure if i'd describe it as "distracting". I don't really care either way, so maybe having the grid off could be better if it's significant to you. --Galoomba (talk) 19:06, 9 September 2023 (UTC)
Obviously the question is not what is significant to either of LifeWiki editors here, but rather what affects reader's experience. If the effect is visible on other devices as well, then probably grid should be disabled for tracked patterns. Confocal (talk) 19:12, 9 September 2023 (UTC)
Also, this only makes sense for low zoom levels. When the pattern is small, or the viewer is large, the grid is definitely better. --Galoomba (talk) 21:20, 9 September 2023 (UTC)

Example patterns

x = 9, y = 14, rule = B36/S23 bo$bo$bo3$3bo$2b2o$bobo$3o2$6b3o$5bobo$5b2o$5bo! #C [[ THUMBSIZE 2 THEME 6 GRID GRIDMAJOR 0 SUPPRESS THUMBLAUNCH ]] #C [[ AUTOSTART GPS 8 TRACKLOOP 48 1/6 1/6 ]]
The bomber (taken from OCA:HighLife)
(click above to open LifeViewer)
RLE: here Plaintext: here
Catagolue: here
x = 9, y = 14, rule = B36/S23 bo$bo$bo3$3bo$2b2o$bobo$3o2$6b3o$5bobo$5b2o$5bo! #C [[ THUMBSIZE 2 THEME 6 GRID GRIDMAJOR 0 SUPPRESS THUMBLAUNCH ]] #C [[ AUTOSTART GPS 8 TRACKLOOP 48 1/6 1/6 GRID OFF ]]
GRID OFF
(click above to open LifeViewer)
RLE: here Plaintext: here
Catagolue: here

For this example I prefer the grid on Chris Rowett (talk) 10:42, 16 September 2023 (UTC)

{{gallery top}} and {{gallery bottom}}

These currently do nothing. Is there a reason to keep using them? --Galoomba (talk) 13:08, 18 September 2023 (UTC)

See this forum post. It is possible that the underlying formatting will change in future, so that either of {{gallery top}} / {{gallery bottom}} / {{gallery item}} will have to be changed. The intent is to simplify update if/when formatting has to be updated later. Confocal (talk) 13:12, 18 September 2023 (UTC)
Unrelated: the broken autogenerated section link in this edit summary is one reason to avoid links/markup in section headings. Confocal (talk) 13:41, 18 September 2023 (UTC)

"logarithmic" replicator rule and prospect of "OCA:rule 225" page

As I noted in my comment on the talk page, in AforAmpere's rule (equivalent to the "logarithmic" replicator rule), there are the limiting bounds on the bit-length in the tth iteration 2 < l(t)√t < 2*√5√3. Perhaps I was too fast to move it (and use Θ notation unnecessarily), but should it be renamed to the "sqrt replicator rule" and note the erroneous name in common use?

It seems AwesoMan3000 named it incorrectly in his creation of the article as a redirect, since David Eppstein made no such claims.

Also note, the single-cell initial state Wolfram rule 225 (that inverts itself and thereafter follows the evolution of a pair of cells in rule 120) also has Θ(√t) growth and admits a complete description (finding the state of a given cell at a given iteration) in terms of a finite number of logical and arithmetic operations (if one is allowed to use a function that returns a number whose output's base-4 representation is its input's base-2 representation), and is the first member of a series of rules with integers ∑2n+1-1k=2n+1(2k)+1 = (22n-1)2 (emulating those with integers ∑2n+1-2k=2n-1(2k) = (22n2)) providing Θ(n√t) growth in width-n+1 neighbourhoods (which may likewise have cells' states at given positions in space and time found in terms of a function whose base-2n output is its base-base-2 input). Should a page be created for rule 225 (noting these generalisations) also?

Re: Logarithmic replicator rule: I think two natural possibilities are either to leave the current name (because the existing name is in common use), or alternatively move the page to B36/S245 (because it is always correct to refer to a Life-like rule using its rulestring in the standard semitotalistic notation, and it is convenient when there is no single commonly-agreed name). Confocal (talk) 12:39, 30 September 2023 (UTC)
I prefer the rulestring, but keep the redirect from logarithmic replicator rule because it's in use. AwesoMan3000 had a tendency to make up names. HotdogPi (talk) 12:47, 30 September 2023 (UTC)
(To clarify, I prefer to leave the existing name. If we move the page to the rulestring, then other people who have a tendency to make up names will want to move it again to some other newly coined name, which will not be nearly as common.) Confocal (talk) 13:01, 30 September 2023 (UTC)


I have no idea why recent issues like this appear to be pinned uniquely to me over the past year - it doesn't take much searching at all to find out that the rule B36/S245 was first named "logarithmic replicator rule" on the Gun page, in a mid-2009 addition by Adam P. Goucher himself: https://conwaylife.com/w/index.php?title=Gun&diff=next&oldid=9711

Refrain from automatically blaming anything you disagree with on my actions. The triangular neighbourhoods incident from months ago was irritating enough, singling me out for introducing an allegedly useless neighbourhood while neither paying attention to the exact context it was suggested under (instead calling it a "mindless suggestion") nor noticing that the "triangular outer" neighbourhood, introduced by Chris himself without me suggesting it (possibly after looking at this 2012 thread which was included the Tripod neighbourhood), suffers from the exact same problem as the "radiation" neighbourhood everyone was complaining about.

I understand I'm not the most liked member in this community, but I'm noticing a pattern that things people don't like appear to be instinctively attributed to myself and would very much like this to stop as soon as it can. AwesoMan3000 (talk) 16:35, 30 September 2023 (UTC)

Retrieved from "https://conwaylife.com/w/index.php?title=LifeWiki:Tiki_bar&oldid=137877"