LifeWiki:Tiki bar

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.

• See LifeWiki:Tiki bar/Archive/2016 for Tiki bar discussions started in 2016.
• See LifeWiki:Tiki bar/Archive/2017 for Tiki bar discussions started in 2017.
• See LifeWiki:Tiki bar/Archive/2018 for Tiki bar discussions started in 2018.

Conduits and converters

I'm gradually gathering the necessary courage to tackle the new Life Lexicon items that start with "P". Looks like one of the big things I should do is to carefully figure out how to make proper use of Template:Reflector, but in this modern LifeViewer age I don't think I agree with the part about "The image in this infobox should NOT include the glider that is to be reflected...".

Seems to me these template recommendations should be updated to say something like "The image in this infobox should include the glider that is to be reflected -- optionally, two input gliders separated by the mechanism's minimum recovery time, and an output glider if that allows a smoother animation. However, the bounding box and population count should be calculated with these gliders removed."

It would actually be pretty annoying to provide RLE of a reflector and not at least show where the input is supposed to go. When copying and pasting one of these to use in a larger construction, it's usually pretty handy to have some kind of marker for where the the input goes and where the output comes from -- thus the ghost Herschels in recently added Herschel conduits.

[Ideally the marks are state-4 LifeHistory so you don't have to edit them out after pasting -- but we should probably stick with simple 2-state Life patterns on the LifeWiki and not open the LifeHistory can of worms.]

... And we can probably get rid of Template:Reflector/Doc while we're at it, no?

Before I start this I'll definitely undertake to review all the existing converters and reflectors and conduits -- there are a bunch with raw RLE and/or uploaded pattern files missing. That's relatively easy to fix, once we have an official decision about whether and how to show inputs and outputs. I'm currently puzzled by the mysterious Template:ConduitInput and Template:ConverterInputOutput. Not that that's surprising -- I'm easily confused by all this wiki template trickery. Dvgrn (talk) 15:26, 8 May 2018 (UTC)

I agree that reflector patterns should include the input glider. I'm the one who originally wrote that they shouldn't, and I'm not really sure why anymore. It can't have been very good reasoning, because I completely disagree with it now.
~Sokwe 07:08, 9 May 2018 (UTC)

Template:Reflector/Doc also asks users not to put animated images on pages, instead suggesting that one should "consider using a static image of the reflector with a caption that links to the animation". I think this does not match the general current LifeWiki practice regarding animated images, or generally animated content. Should we reconsider? Apple Bottom (talk) 05:25, 7 June 2018 (UTC)

It does seem to me that we have a developing consensus that LifeViewer-based illustrations are a good way to go. There are quite a few Help documents and templates that were written long before the advent of LifeViewer. I'd love to have the Help actually explain to a new user how exactly to add RLE to the RLE namespace, how to get that RLE to show up in an infobox or an embedded viewer, how to adjust the LifeViewer config so that animations (if any) look good, etc. It will take a while to get all the docs updated, no doubt. My edit yesterday was just a first attempt to start chipping away at the problem. Dvgrn (talk) 14:48, 7 June 2018 (UTC)

Definitely agree! Unfortunately writing documentation is one of things I'm hopelessly.. well, hopeless at. ;) Apple Bottom (talk) 10:33, 9 June 2018 (UTC)

Lexicon tags

Many of our articles (glossary, in particular) are based on, or at least synced with, Life Lexicon content. This creates a need to update these articles when the Lexicon changes.

Some of that has been handled in an ad-hoc manner on my userpage, but the process is fairly involved: look at the project page, find an article to work on, make sure it needs to be worked on, make the necessary edits, make the necessary changes to the project page to reflect the fact you edited the article.

It's also not easily found by newcomers who may want to help out. (OK, I'll admit, there likely aren't droves of eager newcomers to begin with, but that nonwithstanding, if you don't know said page exists you're not going to find it easily.)

So I was thinking, can't we improve on this? And I just had the idea of tagging articles themselves instead, indicating which version of the Lexicon they correspond to.

The Nethack wiki does something similar; for instance, take a look at their Foodless article, and you'll find that it has an indicator at the top right saying that the page reflects Nethack 3.4.3 (rather than the current 3.6.1), generated by this template.

We could use something similar. There wouldn't necessarily have to be a visible indicator (though there could be); at the very least, though, pages could be tracked in appropriate categories, and we'd know at a glance what needs to be updated (or at least reviewed) and what's current.

This way, all edits would be in one place: review an article and make edits as necessary, and also update the tag to indicate it now reflects a newer Lexicon version. And placing those tracking categories into an appropriate supercategory and placing that in the existing category tree in turn would allow editors interested in helping out find articles in need of review.

There would be two downsides. a) most of the Lexicon doesn't change in each Lexicon release, so we'd have a lot of articles tagged as (say) reflecting v28 when in fact they're also current, by virtue of not having changed since v28. And b) we wouldn't easily be able to see which articles are missing from the wiki entirely.

I still feel that this would be an improvement though, and there's no reason we couldn't combine these tags with a manually-curated project page to get the best of both worlds.

Also, re: downside a) specifically, I think this could be dealt with by also having an indicator on the wiki saying which Lexicon release is current; pages that haven't been tagged as reflecting the current version would then display a gentle, unobtrusive note, and anyone viewing such a page could quickly check that it does indeed match the current Lexicon release, and update the tag if so.

Thoughts? Apple Bottom (talk) 07:49, 18 July 2018 (UTC)

This seems like a fine idea to me. As far as downside a) goes, I think that the last year of Life Lexicon updates is highly unusual, since it involved catching up after over a decade of no maintenance at all.

The standard editing methodology for new Lexicon releases is to maintain a Changes section at the top of the raw Lexicon text file, carefully listing every "added" or "edited" entry since the last release, by name. Nobody is supposed to edit a Lexicon definition without updating the change log. This should make it trivial to find missing articles, and hopefully should also allow an easy update to the tags. Every Lexicon entry that's not listed in the change log can be automatically bumped to the latest lexicon release.

That's a lot of small changes to a lot of articles with every Lexicon release, though. Does it make sense to have the default Lexicon tag be just Template:LexiconLatest or some such, with a template to display on the page whatever the latest Lexicon release number actually is?

Then, for the next Lexicon release (30), we can just update the (relatively small) list of changed definitions to say "Release 29" -- and then after each definition is reviewed and patched, the tag is updated at the same time, back to Template:LexiconLatest? Dvgrn (talk) 22:15, 18 July 2018 (UTC)

I suppose that would work, but it's pretty much the opposite of what I was trying to accomplish. ;) I was thinking of this as a status checkbox of sorts where editors would check off that yes, this article has been reviewed for Life Lexicon release 30 or 50 or whatever, and any articles that lacked that virtual checkmark would automatically be herded and available for review and/or updating, as necessary.

Having a "LexiconLatest" tag instead would mean checkmarks that check themselves, by default, and that we'd then have to go and un-check. That's not so different from the current approach, with my TODO page.

But you raise a good point. We have a log of Life Lexicon changes, and once we're actually caught up with the Lexicon in general all we'd have to do is keep an eye on those. Hmmm.

Here's a thought, admittedly a rather complicated one. How about we do both? That is to say, how about a tag template that has both an explicit parameter and uses a default "low watermark", displaying the higher of both?

The explicit parameter would be used by editors to indicate that a page has been reviewed/updated to reflect a certain Lexicon release; the "low watermark" (kept in a template of its own) would be updated by us whenever we're sure that every Lexicon-related entry reflects a certain Lexicon version.

For instance, assume that all our articles conform to Lexicon release 30. Suppose that release 31 comes out now. We then go through the changelog, edit all articles that need updating, and after that's done, we conclude that no further changes are necessary, and bump the "low watermark" to 31, thus causing all articles (that reference the Lexicon) to declare that they match release 31.

One advantage of this would be that we'd still see when an article was last explicitly reviewed. For instance, an article might say it reflects Lexicon release 31, but the "version=" parameter might still say it was last reviewed for 28. If nothing else, this would make it easier to spot articles that haven't been reviewed for a long time and where discrepancies might've crept in.

Another idea: we've already got Template:LinkLexicon to link to Lexicon entries. We could repurpose this to also additionally display a tag, which would save us the need to edit 831 articles just to add a tagging template.

Apple Bottom (talk) 07:50, 19 July 2018 (UTC)

This all seems reasonable to me -- especially sneaking a displayed tag into Template:LinkLexicon. Now that Golly 3.2 and Release 29 are safely out the door, I'm sorta kinda planning to get back to work on the LifeWiki ToDo list for Lexicon updates, with the intention of getting everything up to date eventually -- hopefully well before Release 30 comes along to confuse things any more. We already have some kind of a tracking system set up for Release 28 and 29, so maybe it makes sense to keep using that, and design the new template/tag system to really come into use once everything has been updated to Release 29.

So in early 2019, if we end up with a list of say fifty articles that have changes for Lexicon Release 30, my thought would be to update just those fifty articles to specifically say "Release 29" (however we decide to do that exactly -- maybe with a template saying "this article is out of date, please help out by updating it"?). Then bump up the "low watermark" to 30 right away. As articles get updated, the "please help" template can get removed again with the same edit. Does that work? Dvgrn (talk) 18:49, 19 July 2018 (UTC)

OK, cool. :) Good to hear you'll have some time to devote to the Lexicon-to-LifeWiki TODO list. I'm not able to put in much effort there myself --- too much studying, too many exams. Ah well.

Re: marking e.g. fifty articles as needing updates and everything as conforming to e.g. release 30 by default --- that would be a lot easier if we had Lua scripting available! MediaWiki's templates only go so far and aren't really meant for pushing lots of structured data around.

Our options there would include at least the following:

1. Manually edit each of those 50 articles (e.g. by setting an extra template parameter) to override the "low watermark". Not ideal --- we might as well just edit those 50 articles to update them if we're already editing them anyway.
2. Provide a global "kill switch" for the low watermark that, when set, causes the low watermark to be ignored. Pages explicitely listing a conforming Lexicon release would then display that instead, so those 50 "release 29" articles would show up in the right category, etc. Also not ideal --- there might be many other articles that would also have the explicit "reviewed for release 29" tag, or older tags at that, which would NOT need to be updated.
3. Keep a list of those 50 articles, and rig the template to display a notice if the title of the transcluding page happens to be on that list. Also not ideal --- we'd have to curate that list, and as I said, MediaWiki templates aren't really meant for this sort of thing.

Maybe there's another solution I'm not seeing, though.

That said I also have a feeling we're trying to overengineer the solution, though, or perhaps attacking the problem from the wrong angle. After all, what do we want to do? Keep the LifeWiki current as far as Lexicon content goes. How do we achieve that? By importing Lexicon as necessary, and (once done) keeping an eye on changes made to the Lexicon and mirroring them on the wiki (again, as necessary). And how do we do that? By rolling up our sleeves and working on it. Fancy templates and tagging nonwithstanding we won't get anywhere if we don't just jump in and do it.

(And by "we", I mean whoever's willing to do that job.)

Apple Bottom (talk) 18:16, 20 July 2018 (UTC)

Re: overengineering... yeah, offhand I don't see a better solution than the first one: manually edit 50 articles, copying and pasting the same "stub"-like template marker in as a header. This is a bit tedious, but that's what multiple browser tabs are for, and it can be done pretty easily in half an hour or so. The idea is that we can make a little bit of effort to spread the update work around. (Here "we" means the small group of people who have done the work so far -- a small group because it's kind of tricky to do everything right, so not many people have figured out all the fiddly details.)

I can add "needs Lexicon update" headers to 50 articles in half an hour, but I sure can't do a careful comparison and repair on 50 articles, especially if it will require adding new illustrations or modifying existing ones. But it seems to me that there's a larger (and growing) population of LifeWiki users who can perfectly well review a particular Lexicon definition when they trip over a "needs Lexicon update" template header begging for help. Often it isn't too hard to find what needs changing, make the required edits, and remove the "needs Lexicon update" tag at the same time.

Every one of these articles that someone picks up and fixes, is one that I don't have to do myself... and in the meantime, a half hour of work has already brought the LifeWiki more up to date, by specifically flagging the fact that there's newer information somewhere else that needs to be integrated into the article. Seems like this might be a good habit to get into, for as long as the Life Lexicon is kept more or less in synch with current reality.

Sound reasonable? And could you have a look at Template:NeedsLexiconUpdate and see if it has everything in it that this plan might need? Dvgrn (talk) 21:02, 20 July 2018 (UTC)

Redirect pages don't need any markers saying they're from a Lexicon entry -- do they? I've been trying to rebuild some momentum by getting the remaining redirects done... Dvgrn (talk) 21:57, 26 July 2018 (UTC)

Cool, good to see this is already progressing. Good job! :) I'm a little less swamped now, so I'll take a look at the Template'n all over the weekend.

No, I don't think redirect pages need markers. I don't consider these "content" in the strictest sense, in either the Lexicon or the LifeWiki --- they're just tools that help people find content.

Apple Bottom (talk) 08:31, 28 July 2018 (UTC)

Object frequency classes

I do apologize for my somewhat extended absence. That said, I had an idea (long ago actually) about adding information on the commonness of objects to pattern infoboxes, using data from Catagolue (specifically, B3/S23/C1).

I don't think saying "this still life is the 1,691th most common object on Catagolue" is useful, of course. What I'm proposing instead is the frequency class, defined as follows: a pattern is in frequency class X if the most commonly-occurring object (the block, in this case) is 2^X times more common. X need not be an integer; to strike a balance I'd suggest using one decimal digit.

Let me give an example. The twin hat has appeared 240,372,408 times on Catagolue (as of this morning), whereas the block has appeared 71,146,901,659,666 times. So the block is approximately 295,986 ≈ 2^18.17517 times more common, and the twin hat's frequency class is 18.2, rounded to one decimal digit.

I think this is a fairly intuitive way of capturing commonness. An additional nice property is that if an object has occurred sufficiently often, its frequency class is unlikely to change much, if at all; this is true even for objects whose commonness is very similar and who might switch ranks regularly, with one or the other having occurred more often at any given moment. So once this information's added, we wouldn't need to edit it much, if at all ever.

Like I said, only sufficiently common objects should have this information added; there's too much uncertainty about the frequency class of an object that has only appeared once, say. I unfortunately lack the statistical background to suggest a good cut-off value ("objects should only have this information in their infoboxes if they have occurred at least n times"), but unless there are objections I'll add this, or at least do the necessary template work.

...heck, I'll just go ahead and do it, it's been a while since I've edited anything here. If anyone thinks that this is a load of bull, please just speak up and say so. :) Apple Bottom (talk) 17:56, 1 September 2018 (UTC)

(P.S. --- although the block is the most common in B3/S23/C1, it isn't necessarily for other B3/S23 censuses; in some symmetries, the blinker is more common.)

Replying to myself, I've started doing this; there is a new template parameter, fc=, currently only for Template:Stilllife, Template:Oscillator, Template:Spaceship and Template:Puffer (no other types of object have appeared on Catagolue anyway). I've also added a short glossary entry at Frequency class, and added frequency calss data to a couple of object infoboxes, including all with FC ≤ 10.0. The script used to generate the necessary data from Catagolue's textcensus is this:

#!/usr/bin/perl

# usage eg.:
# perl ../frequencyclasses.pl b3s23.C1.txt >frequencyclasses.txt

use Modern::Perl '2016';

# only patterns with more than $cutoff occurrences should be considered.
# mark all other patterns with an asterisk.
our $cutoff = 10;

# throw away header line
<>;

my %objects = ();
my $mostcommon = -1;
my $mostcommoncode = "";
while(<>) {
    chomp;
    next unless m/^"([^"]*)","(\d+)"$/;

    my ($apgcode, $count) = ($1, $2);
    $objects{$apgcode} = $count;

    if($count > $mostcommon) {
        $mostcommon = $count;
        $mostcommoncode = $apgcode;
    }
}

my %frequencies = ();
foreach my $apgcode (keys %objects) {
    my $frequencyclass = sprintf("%.1f", (log($mostcommon / $objects{$apgcode})) / log(2));
    $frequencies{$frequencyclass}->{$apgcode} = $objects{$apgcode};
}

foreach my $frequency (sort { $a <=> $b } keys %frequencies) {
    foreach my $apgcode (sort { $frequencies{$frequency}->{$a} <=> $frequencies{$frequency}->{$b} } keys %{ $frequencies{$frequency} }) {
        print "*" if($frequencies{$frequency}->{$apgcode} <= $cutoff);
        say "$frequency\t $apgcode\t $frequencies{$frequency}->{$apgcode}";
    }
}

(I'm sure there's better ways of doing this, but this worked for me.) Apple Bottom (talk) 18:52, 1 September 2018 (UTC)

Another reply to myself --- Goldtiger997 suggested a cut-off value of 10 (non-inclusive). This strikes me as sensible. So unless there's objections, how about we run with this, and only add frequency class information to objects having appeared more than 10 times?

Also --- right now the information is Catagolue-specific, which is sensible but still somewhat arbitrary; if we want to include more information later (e.g. from Achim's, Andrzej's and Nathaniel's censuses, or from whatever future censuses people may come up with), we can easily adjust the infoboxes to include a new "Commonness" section, and re-interpret fc= as "frequency in [c]atagolue". Apple Bottom (talk) 09:08, 2 September 2018 (UTC)

Sounds good. However, I already broke my "suggestion" of the 10 occurence cut-off twice; for the Coe ship and Achim's p8. Is it worth removing the fc parameter for those two articles, or should they just be left as they are? Goldtiger997 (talk) 09:26, 2 September 2018 (UTC)

I think we can grandfather those in --- would be good if you could keep an eye on them in case the information changes, of course, but it's just two articles, so that should be fine. I've also added the cutoff of >10 to the script above; patterns not reaching that cutoff are marked with an asterisk. Apple Bottom (talk) 09:35, 2 September 2018 (UTC)

Infobox vs. EmbedViewer

All this interminable Life Lexicon import work has been leading me to believe that there are two classes of articles that can use LifeViewer animations. There are the named patterns, where if you say "Pattern X" there's really only one likely Pattern X that you could be referring to. These get put into an infobox category, with appropriate statistics collected and so forth. The most recent example of this kind of imported Lexicon article is line crosser.

The other class of article is for a term that might refer to a variety of different patterns, so that there are various examples but no specific example should really be considered to be the one canonical one. In these cases I've been using an embedded viewer but haven't been bothering with an infobox. The most recent examples along these lines are line-cutting reaction and line-mending reaction. I like the way these are turning out, but am curious to hear if anyone thinks that these should also be infoboxed somehow, or if anything else should be added as standard practice. Dvgrn (talk) 09:45, 12 September 2018 (UTC)

I think this is eminently sensible. Off the top of my head, aren't there a few articles that have infoboxes despite being about a family of patterns rather than a specific individual one? (Or patterns with variants, anyway --- the bee shuttles come to mind there.) I've never been quite sure how to handle those, though that's not limited to LifeViewer and embedded patterns: the same goes for other infobox'ed information, such as bounding box, population etc. Apple Bottom (talk) 07:54, 13 September 2018 (UTC)

Yup, those are the ones where I find the infoboxes to be not-helpful. Would suggest in those cases maybe just using an embedded viewer to show one of the family, or maybe a small stamp collection would be better. The most recent example I dealt with was HFx58B from the Life Lexicon. Rather than pick a variant, and/or leave out perfectly good information that the Lexicon had, I just threw caution to the winds and put both patterns in the same infobox, but picked the older variant to do the infobox stats about. Probably this will puzzle somebody sometime, but sometimes Life can be confusing... Dvgrn (talk) 11:20, 13 September 2018 (UTC)