Suggested LifeWiki edits

[PHPBB12345]

https://conwaylife.com/patterns/eater2variant2.rle and https://conwaylife.com/patterns/eater2variant2.cells look like:

Code: Select all

#C [[ GRID VIEWONLY ]]
x = 5, y = 10, rule = B3/S23
2o$bo$bo$2ob2o$3b2o2$2ob2o$bobo$bobo$2bo!

It should be

Code: Select all

#C [[ GRID VIEWONLY ]]
x = 5, y = 9, rule = B3/S23
2o$bo$bob2o$2ob2o2$2ob2o$bobo$bobo$2bo!

correct pattern:

Code: Select all

#C [[ GRID VIEWONLY ]]
x = 7, y = 7, rule = B3/S23
o2bob2o$4ob2o2$2b2ob2o$3bobo$3bobo$4bo!

[rattlesnake]

Oscillator should have an update for SKOP 122 (currently says 118 cells, but this is 102 cells):

Code: Select all

x = 55, y = 44, rule = B3/S23
25bo$25b3o$28bo$27b2o5$39bo$38bobo$12bo26bo$12b3o$15bo$14b2o$9b2o20b2o
$9bo22bob2o17b2o$7bobo26bo16bo$6bobo27bo14bobo$2b2o3bo26b3o9b2o3b2o$2b
2o42b2o5$7b2o42b2o$2b2o3b2o9b3o26bo3b2o$bobo14bo27bobo$bo16bo26bobo$2o
17b2obo22bo$22b2o20b2o$39b2o$39bo$40b3o$15bo26bo$14bobo$15bo5$26b2o$26b
o$27b3o$29bo!

[confocaloid]

The claimed "eater 2 variant", hat on block on table, isn't an eater 2 variant at all. It can't perform catalyzes.
Observe the reactions below: [...]
EDIT by dvgrn: Yup, somebody just got the wrong orientation for the table. Will fix now. Not necessarily useless, e.g., if it turns out to be easier to slow-salvo construct, or easier to weld to something else nearby.

https://conwaylife.com/patterns/eater2variant2.rle and https://conwaylife.com/patterns/eater2variant2.cells look like: [...]
EDIT by dvgrn: Fixed.

Not really fixed -- now the linked files show the wrong pattern. For context, see https://conwaylife.com/w/index.php?diff ... did=118901.
EDIT by dvgrn: Re-fixed...

[dvgrn]

I noticed that there's literally a 1.5 month gap in the news. I think it's impossible for this community to not have a notable discovery for so long. Can anyone fill in the gap?

I've reworked the reports of the very exciting recent progress on calcyman's "Silk" search program, so that now at least there's an entry for May.

The gap is now just slightly over a month long. Anyone have any good suggestions for the time period between May 6th and June 7th? Drop them into Template:CurrentNews/editcopy!

[confocaloid]

Add links to Cordership

Code: Select all

[...]
== External links ==
* {{LinkForumThread
|format = ref
|f      = 2
|t      = 4713
|p      = 103773
|title  = Cordership Discussion Thread
}}
* {{cite web
|url    = https://github.com/Matthias-Merzenich/jslife-moving/tree/master/velocity-c12d
|title  = jslife-moving/velocity-c12d
}}
* {{cite web
|url    = https://web.archive.org/web/20200421005446/http://pentadecathlon.com/lifeNews/2005/06/new_compact_corderships.html
|title  =  New Compact Corderships
|publisher = Game of Life News
}}
[...]

EDIT by dvgrn: Done.

[rattlesnake]

Blocker has blunding box 10x6 but the page says 10x5.

[b-engine]

Blocker has a bounding box of 10x6 but the page says it's 10x5.

LWSS also have this problem (actually 5x5 according to your opinion and LV identification, but 5x4 in LW). I can edit but I chose to wait until confirmed.

[confocaloid]

I agree on the blocker; I disagree on the LWSS.

Blocker has blunding box 10x6 but the page says 10x5.

By the LifeWiki conventions for oscillators (include the entire oscillator in all phases), the bounding box of the blocker is 10-by-6, so the info should indeed be changed:

Code: Select all

x = 10, y = 6, rule = LifeHistory
6.ABA$.B2.BA3B$2A2BA4BA$2ABA2BAB2A$.3B2A2.B$.3B!

Blocker has a bounding box of 10x6 but the page says it's 10x5.

LWSS also have this problem (actually 5x5 according to your opinion and LV identification, but 5x4 in LW). I can edit but I chose to wait until confirmed.

Unlike the blocker, LWSS is a spaceship. As far as I know, currently LifeWiki does not have a standard for spaceship bounding boxes (see Talk:Loafer). Consequently, any possible value in the infobox (either 5x5, 5x4, or anything else) is equally arbitrary at this point.

[squareroot12621]

As far as I know, currently LifeWiki does not have a standard for spaceship bounding boxes (see Talk:Loafer). Consequently, any possible value in the infobox (either 5x5, 5x4, or anything else) is equally arbitrary at this point.

LifeWiki has an unstandard, if that counts…

The bounding box of a moving object is often considered in only one phase, but may also refer to the bounding box that contains the object in all phases of its period.

[dvgrn]

By the LifeWiki conventions for oscillators (include the entire oscillator in all phases), the bounding box of the blocker is 10-by-6, so the info should indeed be changed.

Is there anything in LifeWiki documentation that says that? Or is the main reference Sokwe's summary in Talk:Loafer? I'm thinking something should probably be added somewhere. LifeWiki:Pattern_pages defines the "bx" and "by" parameters, but neither it nor the linked bounding box seem to give any standard advice about how to measure oscillators.

Seems like we sometimes use minimum bounding box for oscillators -- e.g., Eye of Sauron -- but other times we use the bounding box of the oscillator's envelope as per Sokwe's suggestion -- e.g., Octagon 2. And, heh, apparently sometimes we take the average, as in Blocker!

Blocker has a bounding box of 10x6 but the page says it's 10x5.

LWSS also have this problem (actually 5x5 according to your opinion and LV identification, but 5x4 in LW). I can edit but I chose to wait until confirmed.

Yeah, definitely don't change the LWSS bounding box. LIfeViewer actually identifies it as 5x4, and that seems pretty standard. For spaceships we usually find the minimum bounding box. At least, I've been doing that for many years whenever new statistics are needed for an engineered spaceship like the Speed Demonoid (by running getminpopandbb.lua).

i see that I put in a vote for "minimum bounding box across all phases" in the Talk:Loafer discussion about spaceships, after calcyman said it was a "more natural" metric. Nobody seems to have voted for anything else. Maybe let's take that as the standard, since it has actually been in use for new engineered spaceships at least, for quite a while now?

[confocaloid]

[...]
LifeWiki has an unstandard, if that counts…

The bounding box of a moving object is often considered in only one phase, but may also refer to the bounding box that contains the object in all phases of its period.

Yes, I think that counts as observable evidence of existing ambiguity and lack of standard. For bounding boxes of spaceships, there are at least two possibilities (1 phase vs. all phases). BTW even if for example people choose "1 phase", there is still room for ambiguity. A spaceship might have two phases with two different bounding boxes with the smallest area. E.g. imagine a spaceship that has bounding box 10x6 in one phase, 12x5 in another phase, and never has a bounding box with smaller area in any other phase. Would it be 10x6, or 12x5, or "both", or "neither", or maybe simply "a 60-cell bounding box"? (This problem isn't specific to spaceships -- an oscillator's bounding box could also be ambiguous in this way.)

[...] Maybe let's take that as the standard, since it has actually been in use for new engineered spaceships at least, for quite a while now?

I think there should be a new discussion thread opened here in the LifeWiki Discussion subforum. This is an old topic, it's still unresolved, there's still recent (current) discussion on it, and there is both actual and potential disagreement.

I can imagine more than two possible ways to define bounding boxes for spaceships. I can also see some problems with the idea of defining a standard. It's not clear why one needs to know the bounding box of a spaceship -- why that information is considered useful? Is it actually useful (in comparison to e.g. describing numericaly the infinite envelope, continued forward and backward in time)? Maybe it would be a better idea to remove bounding boxes for spaceships from the infoboxes, as useless or nearly-useless data.

[confocaloid]

By the LifeWiki conventions for oscillators (include the entire oscillator in all phases), the bounding box of the blocker is 10-by-6, so the info should indeed be changed.

Is there anything in LifeWiki documentation that says that? [...]

The linked bounding box page tells how to measure oscillators on LifeWiki:

The bounding box of an oscillator is considered on LifeWiki to include the entire oscillator in all of its phases.

[dvgrn]

Is there anything in LifeWiki documentation that says that? [...]

The linked bounding box page tells how to measure oscillators on LifeWiki:

The bounding box of an oscillator is considered on LifeWiki to include the entire oscillator in all of its phases.

Ah, there it is -- thanks!

It's not clear why one needs to know the bounding box of a spaceship -- why that information is considered useful? Is it actually useful (as opposed to e.g. describing [numerically] the infinite envelope, continued forward and backward in time)? Maybe it would be a better idea to remove bounding boxes for spaceships from the infoboxes, as useless or nearly-useless data.

Yep, I'm often a little bit annoyed about having to calculate that number for engineered spaceships, just to have something to put in those fields. On the other hand, for the great majority of spaceships, getminpopandbb.lua very quickly gives an unambiguous set of values, and they can be handy for getting a general sense of the size of the spaceship.

E.g., it's not terribly useful to know that the Speed Demonoid is exactly 872867x1839173 and the 0hd Demonoid is exactly 55010x54964 -- but it's sometimes helpful to know that the Speed Demonoid is about 870Kx1840K, whereas the 0hd Demonoid is only about 55K square. Similar rough orderings happen a lot when we're looking at, e.g., 3c/7 spaceships -- flying spaghetti monster, Anura, Soba, and 232P7H3V0.

We can supply numbers in the infobox that are unambiguous and easy to calculate, so in my opinion we might as well just keep doing that -- and just document better what those numbers are.

If somebody wants to do something else, that's probably fine as long as it's consistent and doesn't start any arguments ... but minimum bounding box seems like the "path of least resistance" at the moment.

[confocaloid]

[...]
If somebody wants to do something else, that's probably fine as long as it's consistent and doesn't start any arguments ... but minimum bounding box seems like the "path of least resistance" at the moment.

I think the "path of least resistance" would be to continue to avoid having *any* standard for bounding boxes of spaceships in the LifeWiki. The usefulness of those values seems dubious.

As I said, since there are past and current discussions on this topic, with evidence of disagreement and without evidence of agreement, I suggest to start a new forum thread in the LifeWiki discussion subforum, for interested people to discuss whether or not LifeWiki actually needs a "standard for bounding boxes of spaceships", and what are possibilities for such a standard.

[dvgrn]

As I said, since there are past and current discussions on this topic, with evidence of disagreement and without evidence of agreement, I suggest to start a new forum thread in the LifeWiki discussion subforum, for interested people to discuss whether or not LifeWiki actually needs a "standard for bounding boxes of spaceships", and what are possibilities for such a standard.

If you're among those interested people, please feel free to start a new forum thread.

It's not clear to me what your "evidence of disagreement" is -- there was a friendly discussion on Talk:Loafer where some options were listed, but the "all phases" option for spaceships didn't have any strong advocates that I could see -- due to it being much harder to calculate and not even uniquely defined in all cases.

[confocaloid]

The new discussion thread (spaceship bounding boxes) is viewtopic.php?f=16&t=6575

The bounding boxes of oscillators Blocker and Eye of Sauron should be corrected, per preceding discussion / https://conwaylife.com/w/index.php?diff ... did=137052

The "numrules" value is no longer valid after an update in https://conwaylife.com/w/index.php?diff ... did=144224 -- see the talk page.

EDIT by dvgrn: Partly done -- Haycat2009 has fixed the bounding boxes. I'm not clear from the talk page what exactly should be done about the "numrules" problem, so I haven't tried to do anything there.

[rattlesnake]

339P7H1V0 has an error (the pattern doesn't show).

[dvgrn]

339P7H1V0 has an error (the pattern doesn't show).

That was easy to fix -- there was a trailing "<br/>" in the RLE:339p7h1v0 header.

However, it looks like that "<br/>" has been in the RLE since 2017, probably without causing any display issues until some recent build of LifeViewer (it's currently on Build 1149).

It might be worth having a good look around for other RLE data embedded in HTML that now suddenly doesn't display properly when a recent LifeViewer build is used.

I've checked b3s23life.blogspot.com, which is chock full of RLE patterns terminated by <br/>s on every line -- Build 1149 seems to be working fine there, so maybe something more subtle is going on.

(?)

[rowett]

339P7H1V0 has an error (the pattern doesn't show).

That was easy to fix -- there was a trailing "<br/>" in the RLE:339p7h1v0 header.

However, it looks like that "<br/>" has been in the RLE since 2017, probably without causing any display issues until some recent build of LifeViewer (it's currently on Build 1149).

This was a regression in LifeViewer. It's been fixed in Build 1150. It should now handle <br/> correctly as before.

[confocaloid]

The page Pipsquirter lacks discovery information and links to relevant forum posts (e.g. for engineered solutions).

[...]
The "numrules" value is no longer valid after an update in https://conwaylife.com/w/index.php?diff ... did=144224 -- see the talk page.

[hotdogPi]

The problem with updating numrules is that it would somehow be a decrease (not sure why), so I'm not sure if I can update it and have it still be counting the same way it used to.

[confocaloid]

The problem with updating numrules is that it would somehow be a decrease (not sure why), so I'm not sure if I can update it and have it still be counting the same way it used to.

Yes, I also noticed there is a decrease. Maybe there was some kind of cleanup on Catagolue?

[confocaloid]

https://conwaylife.com/w/index.php?diff ... did=150190
To link a category page within a page as a normal wiki link (without adding the page to the category), prefix the link name with a colon. In this case:

Code: Select all

If a [[:Category:Colour-changing_reflectors|colour-changing reflector]] is needed, [...]

More details:
https://www.mediawiki.org/wiki/Help:Categories
https://www.mediawiki.org/wiki/Help:Links

[Vort]

I think it worth to add x7 reflector/divider/multiplier to the list at Period multiplier page.

[confocaloid]

I think it worth to add x7 reflector/divider/multiplier to the list at Period multiplier page.

Can you please link to the source for the intended pattern? The description is unclear. (In particular it is unclear what is a x7 reflector. Spaceship reflectors emit one output spaceship for every incoming spaceship.)

I know about a x7 glider-consuming Herschel-producing pulse divider. It can be described with the shorthand "7G-to-H". It can be also extended to a (7+6n)G-to-H family of pulse dividers for n = 0, 1, 2, 3, ...
There are multiple other known pulse dividers (including nG-to-G, nG-to-H, nH-to-H and others). Some can be found in viewtopic.php?f=2&t=1097

I think collecting all known examples in a single wiki page is impractical. (There are too many to show on a single wiki page.)
It makes sense to show a few compact examples for an illustration (which is already done) and link to forum threads from the "External links" section (which is also already done).

When explaining these ideas and these devices, I believe it is important to distinguish between pulse dividers and period multiplication.

Period multiplication can be achieved in multiple ways, with "attach a pulse divider" being only one of existing possibilities. (There are also filters, modifying an engine with catalysts / sparkers, crossing streams emitted by glider guns, and so on.)

A pulse divider is a device that "counts" incoming pulses (which do not have to follow each other in an uniformly-spaced stream), and emits one pulse for every n incoming pulses, for some n > 1. Pulse dividers can be used to solve multiple different tasks, with "period multiplication" being only one of such tasks.

[...] semi/tremi/quadri-Snarks (as well as more recent discoveries) are actually pulse dividers. A pulse divider can also be used as a period multiplier (accepting an uniform input stream). However, a pulse divider doesn't require uniformly spaced input pulses to work. So in a certain sense, referring to pulse dividers as period multipliers "undersells" them: these devices can solve more problems.

The distinction between the two types of devices can be seen [...] in the case of engineered prime-period guns.
It's correct that prime periods are impossible to get with period multiplication (because multiplying a lower period will always result in a composite period).
However, prime periods can be obtained with pulse division (as already illustrated by the various examples posted by others).
[...]