Miscellaneous LifeWiki Discussion

[WhiteHawk]

On the Timeline of Life facts, would it be a good idea to potentially add some important events which occurred before CGOL was discovered (e.g. Moore Neighborhood, Garden of Eden Theorem, Alan Turing's work, etc)?

Also might it be useful to note the few results of pre-life exploration which occurred in 1969 (Blinker, Glider, R-pentomino, etc.), as they are currently lumped into the year 1970?

[hotdogPi]

The code for showing OCA rules is broken. Instead of resetting after 256 generations, it continues, but for every generation after 256, it suddenly zooms out and then gradually back in, taking three seconds to process for each generation because the zoom takes time.

[confocaloid]

The code for showing OCA rules is broken. Instead of resetting after 256 generations, it continues, but for every generation after 256, it suddenly zooms out and then gradually back in, taking three seconds to process for each generation because the zoom takes time.

An example of a page where this is currently visible is OCA:Seeds. I think the relevant templates are Template:EmbedViewerRule and Template:LifeViewer config/rule. The templates were not changed recently so it is probably a consequence of a change in LifeViewer.

(As a side note, the idea of using pseudorandom patterns as an illustration is by itself a bit problematic (does a soup have any encyclopedic value at all, other than possibly by producing some notable object?) IMO it would be objectively better to use a fixed non-random pattern for illustration, or omit the infobox illustration entirely and instead put or mention all noteworthy relevant patterns in the main part of the article.)

[WhiteHawk]

Why do only some guns come up when "p[insert gun period here] glider gun" is inputted into the LifeWiki search bar, but not others? (They do come up when you go to extended Search result, but not as immediate links and not as first results)

[confocaloid]

https://www.mediawiki.org/wiki/Help:Redirects

However, in general some types of redirects can be problematic, and especially creating many redirects quickly without previous discussion of that (as well as any significant changes without previous discussion) can be problematic.

In this case, there are several existing redirects (for example p20 glider gun, p30 glider gun, p36 glider gun, p46 glider gun). I think it makes sense to ensure that redirects of the same type exist for all other wiki pages about topics "notable glider guns of period N".

Why do only some guns come up when "p[insert gun period here] glider gun" is inputted into the LifeWiki search bar, but not others? (They do come up when you go to extended Search result, but not as immediate links and not as first results)

[WhiteHawk]

However, in general some types of redirects can be problematic, and especially creating many redirects quickly without previous discussion of that (as well as any significant changes without previous discussion) can be problematic.

(EDIT: Removed incorrect statement) Would it be acceptable to now do the necessary addition of the specific redirects?

[dvgrn]

Now that this topic has been discussed, would it be acceptable to do the necessary addition of the specific redirects?

It seems like you could safely follow confocaloid's suggestion ('ensure that redirects of the same type exist for all other wiki pages about topics "notable glider guns of period N" ') within another day or two -- maybe giving people just a bit more time to respond here. With such a small number of suggested edits, and with the edits being so trivial to roll back in the unlikely event that someone objects to them, the extra waiting around is probably optional in this case.

If you want to be extra cautious, you could add a couple of sample redirects, linking to this discussion in the edit summary, and _then_ wait a day or two -- maximize the chance of bringing any objectors out of the woodwork.

[confocaloid]

However, in general some types of redirects can be problematic, and especially creating many redirects quickly without previous discussion of that (as well as any significant changes without previous discussion) can be problematic.

Now that this topic has been discussed, would it be acceptable to do the necessary addition of the specific redirects?

I didn't reply before, because I noticed in the log that the changes were already done almost immediately after the question was asked (and I personally don't object to those specific changes).

However, I do object to the statement "this topic has been discussed". There was simply not enough time for a discussion that could possibly lead to any observable consensus.

[WhiteHawk]

Period-47 glider gun

The current page has the significant issue of being hard to read with the PNG file being too big and sidelining text. Please advise

[confocaloid]

Period-47 glider gun

The current page has the significant issue of being hard to read with the PNG file being too big and sidelining text. Please advise

Two possibilities are either to replace the image with a smaller one, or to hide the infobox image entirely (and put all relevant notable patterns into embedded viewers within the main part of the article, instead of the infobox).

The latter can be done by adding "hideimg=1" into the infobox. viewtopic.php?p=160959#p160959

Code: Select all

| hideimg = 1

I can confirm the problem (of the infobox sometimes being way too wide and making the page hard to read).

[hotdogPi]

I think the infobox should have the smallest one. Unlike the earlier ones which had many repeated parts and screamed "this looks improvable", improving the current one would require a new trick rather than just optimization. Doing so would also reduce the size of the infobox by a lot.

Water strider keeps getting updates and the infobox gets updated each time.

[dvgrn]

Period-47 glider gun

The current page has the significant issue of being hard to read with the PNG file being too big and sidelining text. Please advise

Hmm. I can maybe see why the original article was created with a PNG -- there wasn't any text to speak of to compete for space with the image, and the pattern might have been big enough to be thought of as "too big for an infobox". However, a lot of changes have happened since that original decision was made.

Four embedded-LifeViewer RLEs have been added, with the first two being the same order of magnitude as the original gun shown in the infobox -- a five-digit bounding box.

LifeViewer has been significantly improved to handle big patterns better -- see the recent discussion here.

It doesn't work very well to have the pattern in the infobox be the only one of the five visible patterns that is awkwardly displayed as a static PNG. PNGs are inconvenient, which is why they've been replaced on the LifeWiki, pretty much everywhere that they can be replaced. A "normal" article infobox contains the relevant pattern in a form that can be easily interacted with, with the pattern copied out of LifeViewer easily with Ctrl+C. There are relatively few exceptions to this rule.

What would be the downside of simply replacing the PNG with a standard LifeViewer, at this point? That would give us easy control over the size of the display, and it seems like it shouldn't slow down the page load to any significant degree.

I think the infobox should have the smallest one. Unlike the earlier ones which had many repeated parts and screamed "this looks improvable", improving the current one would require a new trick rather than just optimization. Doing so would also reduce the size of the infobox by a lot.

Water strider keeps getting updates and the infobox gets updated each time.

This is a much thornier question, and solving it ... well, it doesn't really work to cite examples of other articles where one thing or another is done. We've got equally good examples where both things have happened -- keeping the original, and constantly updating to the newest.

Here the precedent has been established of keeping the original and putting newer versions at the end of a growing gallery. It might be a good idea to just stick with the established precedent for this article, just because it's such a can of worms to re-open the original-form-vs.-newest-form discussion.

Here's a link to one of many previous discussions about update-in-place vs. keep-original-form:

I don't have a strong opinion on whether "54P23" or "55P23" is a better place to leave the article. Not surprisingly, given the edits that I made, my impression was that on balance it was good to have the record-breaking minimal version of the oscillator in the infobox, and put the original form in the article text.

If there's a groundswell of support for moving it back, I'll be happy to move it back; it would be nice to have a clear set of rules for handling this kind of situation, since we have valid precedents in both directions at this point -- see, e.g., Heavyweight volcano, but see also 51P384.

EDIT: In the 54P23-vs.-55P23 case, my guess was that update-in-place was a slightly better idea. And I absolutely do admit that in this p47 gun case, hotdogPi's idea of swapping in the latest smallest discovery and moving the original form to the gallery would solve more than one problem, and probably wouldn't create very many new problems.

So I'd be perfectly happy with that option if that seemed to be the general consensus. But if some people want to keep the original gun in the infobox, then I'm happy with that too; it seems like switching to LifeViewer in the infobox also doesn't have a lot of downside.

[confocaloid]

I would prefer to either

(a) keep the original version of the pattern that's the topic of the article (and the correct matching discovery information) in the infobox, in a reasonably small infobox viewer so that the infobox is not too wide; all noteworthy newer versions go in the main part of the article (outside the infobox); or

(b) leave the infobox without any pattern at all (i.e. neither a static image nor an infobox viewer; hideimg=1) and instead put all the patterns in embedded viewers in the main part of the article (outside the infobox).

When the original version is large, I think it's better to do hideimg=1 and put all patterns in the main part, surrounded by text above and/or below.

[dvgrn]

(a) keep the original version of the pattern that's the topic of the article ...
(b) leave the infobox without any pattern at all ...
When the original version is large, I think it's better to do hideimg=1 and put all patterns in the main part, surrounded by text above and/or below.

Would you say that the original version is large in this case? To agree on any kind of standard rule for situations like this, it seems like we'd have to come up with a specific dividing line, since people will otherwise interpret "large" in different ways, and there's no clear way to decide which interpretation is better.

Here I'm thinking that the original gun is no more than "medium-sized", so I've gone ahead and implemented your option (a). Looks pretty good -- same zoom level as the first two embedded LifeViewers.

Possible generalization
In practice the most awkward detail with implementing hotdogPi's update-in-place suggestion is that it's not as simple as just changing the pattern in the infobox. To avoid confusion, a lot of infobox parameters end up having to change along with the pattern.

And then it's still somewhat confusing! If we showed the current smallest p47 glider gun in the infobox, then would the discoverers be Entity Valkyrie and iNoMed, or Period1GliderGun? Would the year of discovery be 2024 or 2025?

It seems like option (a) above neatly avoids that headache.

A previous tough case
We have an equivalent problem for heavyweight volcano which is still unresolved -- we've currently got Dean Hickerson listed as the original discoverer of heavyweight volcanoes, because that's true, but then we've got the actual current useful version of the heavyweight volcano in the infobox -- because that seemed like the variant that was worth putting on special display as what "heavyweight volcano" means these days.

Moving the heavyweight volcano infobox image back to Dean Hickerson's original, seems like it would solve the data mismatch problem, and it would help set a fairly decent precedent for "What To Do In Cases Like This". It would definitely be nice to have one standard method for handling these things. Somehow the article text would have to highlight Scot Ellison's more modern volcano as much as possible.

Reasonable exceptions to any such "standard method" are still going to be a good idea sometimes, of course. The water strider optimizations that hotdogPi pointed out are kind of a weird case, for example. I think the right choice was made in that case, to show the current optimized water strider instead of the original one.

Further thoughts on any of this?

[confocaloid]

A different issue (about the current revision of period-47 glider gun page) is that there are multiple viewers that are animated by default. I think it is better to disable most animations (no AUTOSTART), possibly either leaving the infobox viewer animated or disabling all animations.

With multiple patterns on a page, it is better to let the reader decide whether they want to view some of those patterns animated.

[WhiteHawk]

The former wording on Period-14 glider gun page:

"There is no known [[true]]-period p14 glider gun (although there are known [[partial]]s, and finding an example using a direct search is well beyond current search algorithms' abilities. One possible way to create a true-period 14 gun would be to find a p14 [[pi]] [[factory]], which can be converted to a glider using the same mechanism as the [[period-21 glider gun]]."

Now that a p14 gun is known, it probably doesn't matter. However, I feel that certain aspects of the statement above are very much incorrect.

Also, because there is a true-period p14 gun known now, and because it is not traditionally pertinent to include pseudo-period guns on their true-period completion pages (Simkin's GG being an exception due to pseudo-period 1-barreled version being smaller in Pop and BB than the true-period 1-barreled version), I feel that it would be best to rename this page for pseudo-period-14 guns and give the p14 glider gun it's own page

EDIT:

In which ways?

Sorry. Firstly, " finding an example using a direct search is well beyond current search algorithms' abilities" is incorrect, for one. Secondly, though not necessarily incorrect, is the mentioning of the mechanism which may not actually be pertinent (and ended up not being pertinent) to the discovery of a p14 glider gun.

[confocaloid]

[...] However, I feel that the statement above is very much incorrect in several ways [...]

In which ways?

[muzik]

Finally ended up completing this page after leaving it dormant for much longer than I should have: https://conwaylife.com/wiki/Triangular_tiling

What improvements can be made to the included information, layout presentation and so on? In addition, how does this compare to the existing pages for the square and hexagonal grids?

[confocaloid]

One of several issues I noticed so far is that the current revision ( https://conwaylife.com/w/index.php?titl ... did=159621 ) claims

[...] Since triangles, inline squares and hexagons, do not tesselate the plane through translation only [...]

I don't understand how that would be the case given that (regular) hexagons do tessellate the plane through translations only.
I also don't know what is meant by "inline squares" here, it might be something that isn't a square at all, squares definitely do tessellate the plane through translations only; the word 'inline' does not seem to appear anywhere else on that page.

Also, the page incorrectly claims "the RuleLoader format does not support triangular neighbourhoods, and therefore custom triangular rules cannot be created."
The RuleLoader algorithm doesn't have direct support for triangular tiling. However, it supports them indirectly. You can subdivide every square into two triangles and define a (n^2)-state cellular automaton on the square tiling to work with a n-state cellular automaton on the triangular tiling. This is a well-known old approach, it works reasonably well, it needs to be mentioned.

[confocaloid]

https://conwaylife.com/w/index.php?diff ... did=124087 (and many other similar edits: https://conwaylife.com/w/index.php?targ ... tributions)

I don't see the usefulness of quickly editing dozens of pages to add the line

Code: Select all

{{reupload|Consistency}}

instead of either

1. discussing here on the forums whether "reupload" is needed at all, and what sort of "reupload" would be needed,
2. or (in the event that it was already discussed and well-understood) simply reuploading the files according to results of earlier discussion, without bothering with the request template. A link to the relevant discussion from the edit summaries would be enough.

An obvious problem with edits similar to the linked edit is that many such edits clutter the logs, and it remains unclear whether there was any relevant discussion / where this was discussed / what sort of reupload is needed / etc.

[WhiteHawk]

Some pages have recently been updated with different Reference formats (that, TBH, are visually confusing and dense). What is going on here?

[confocaloid]

Please be more specific. Which pages? In what way confusing?

Some pages have recently been updated with different Reference formats (that, TBH, are visually confusing and dense). What is going on here?

[WhiteHawk]

Please be more specific. Which pages? In what way confusing?

Some pages have recently been updated with different Reference formats (that, TBH, are visually confusing and dense). What is going on here?

Several (e.g. Period-40 traffic light hasslers)

[confocaloid]

[...] Several (e.g. Period-40 traffic light hasslers)

I don't see in what way the current content on that page is confusing. Can you explain more?

As for the reference format, there is only one reference (which could and should be improved, ideally there should be links to sources for all patterns). I don't see in what way it's confusing or "dense".

Note also that all recent edits are by yourself: https://conwaylife.com/w/index.php?diff ... did=157128

It should be an improvement to get rid of "THEME Book" which (in LifeWiki context) was mostly a failed experiment. Patterns usually look better when they are plain two-state black/white.

[WhiteHawk]

[...] Several (e.g. Period-40 traffic light hasslers)

I don't see in what way the current content on that page is confusing. Can you explain more?

As for the reference format, there is only one reference (which could and should be improved, ideally there should be links to sources for all patterns). I don't see in what way it's confusing or "dense".

Note also that all recent edits are by yourself: https://conwaylife.com/w/index.php?diff ... did=157128

It should be an improvement to get rid of "THEME Book" which (in LifeWiki context) was mostly a failed experiment. Patterns usually look better when they are plain two-state black/white.

Oh, agree with the idea that there should be far more specific information and citations of discovery on pages concerning oscillators. Getting rid of book themes is something i may tackle later

What I am referring to is that single citation, which is no longer directly listed under "==references==" but is now linked there from the gallery.

<ref>{{LinkForumThread|format=ref|f=2|t=1437|p=145447|title=Re: Oscillator Discussion Thread|author=David Raucci|date=May 11, 2022}}</ref>