Catagolue Oddities

[BlinkerSpawn]

What's this?
https://catagolue.appspot.com/object/xs ... y511/b3s23

Hmm yes it's missing the top right quarter

Improper pseudo-SL separation, it appears.
I'm thinking maybe we shouldn't separate pseudo-SLs with larger than, say, a 10x10 bounding box, because this has happened before as well...

[Apple Bottom]

What's this?
https://catagolue.appspot.com/object/xs ... y511/b3s23

Looks like an improperly separated pseudo-still life; this should be (as best as I can tell) one copy fo xs48_ckjhe0ehjkczcai2s0s2iaczw11x11 and three copies of xs25_g8861v0ccz11dd11. (A fourth one was presumably separated already.)

[muzik]

(A fourth one was presumably separated already.)

Indeed:

Code: Select all

x = 31, y = 31, rule = B3/S23
bboboboobbooobooobooobboobobobb$
booobboobobbobbbbbobboboobbooob$
oooboboobbooooooooooobboobobooo$
bobooobbobbbobbbbbobbbobbooobob$
oboobbbooooobooboobooooobbboobo$
bbbobboobbooobbbbbooobboobbobbb$
ooobbobobbbooboooboobbbobobbooo$
ooobooobobobobbbbbobobobooobooo$
bbboobbobooboboboboboobobboobbb$
bobbobbbobobbooooobbobobbbobbob$
oboboobooobbobobobobboooboobobo$
obobooobbbbbbobbbobbbbbbooobobo$
ooooboooobobobooobobobooooboooo$
bbobobbbbobobobbbobobobbbbobobb$
obobobobooobobobobobooobobobobo$
obobbbobbobbobbbbbobbobbobbbobo$
obobobobooobobobobobooobobobobo$
bbobobbbbobobobbbobobobbbbobobb$
ooooboooobobobooobobobooooboooo$
obobooobbbbbbobbbobbbbbbooobobo$
oboboobooobbobobobobboooboobobo$
bobbobbbobobbooooobbobobbbobbob$
bbboobbobooboboboboboobobboobbb$
ooobooobobobobbbbbobobobooobooo$
ooobbobobbbooboooboobbbobobbooo$
bbbobboobbooobbbbbooobboobbobbb$
oboobbbooooobooboobooooobbboobo$
bobooobbobbbobbbbbobbbobbooobob$
oooboboobbooooooooooobboobobooo$
booobboobobbobbbbbobboboobbooob$
bboboboobbooobooobooobboobobobb!

[toroidalet]

This
(in case you were wondering, it labels

Code: Select all

x = 6, y = 2, rule = B2n34tw8/S23
obob2o$2ob2o!

as the highlife p10, despite the fact that it rotates rather than flips

[Apple Bottom]

This
(in case you were wondering, it labels

Code: Select all

x = 6, y = 2, rule = B2n34tw8/S23
obob2o$2ob2o!

as the highlife p10, despite the fact that it rotates rather than flips

"Nicknames" are based on apgcodes, so objects with the same code receive the same nickname.

The fact that the same apgcode can in turn encode different objects in different rules is well-known -- see for example xp2_2a54 (the clock), which has several pseudo-variants.

[praosylen]

A number of non-totalistic rules containing "v" instead of the correct "n" have been searched, suggesting that someone has been using an older version of my hacked apgsearch. Here's the update to fix: http://conwaylife.com/forums/viewtopic. ... 227#p27227

[AbhpzTa]

Slightly longer name (e.g. B2-ain3ai/S2-a3) ("2-ain" is longer than "2cek")

Same rules, different names: B3/S2-i34q and tlife

[GUYTU6J]

Now I am surfing on the Internet in China.Both http://catagolue.appsp0t.com/home and https://catagolue.appspot.com/home is not available on my computer,probably because the GFW

[drc]

How come textcensuses (censi? censes? census'?) aren't sorted by commonness? See here.

[calcyman]

How come textcensuses (censi? censes? census'?) aren't sorted by commonness? See here.

Use /textcensus/b3s23/C1/sorted to sort by frequency. I made this decision a while ago so as to reduce server-side CPU and memory usage.

[Apple Bottom]

Not all that high on the oddness scale, but I'm unable to wrap my head around it: although scorbiclife contributed a haul to B348/S4 way back in February 2015, the pie chart for that rule is, right now, only showing me and C. Wang. What gives?

[BlinkerSpawn]

Not all that high on the oddness scale, but I'm unable to wrap my head around it: although scorbiclife contributed a haul to B348/S4 way back in February 2015, the pie chart for that rule is, right now, only showing me and C. Wang. What gives?

The root for that haul is missing an "m_" flag that the other hauls have.
This appears to interfere with whatever script generates the pie chart although individual census pages and individual object pages recognize the existence of the haul. The pie chart's percentages would be perfect if the haul from scorbiclife is treated as nonexistent, but for example xp6_7o2zo7g1z1 has two sample soups; one from scorbiclife's haul and one from a different hone.
EDIT: Unrelated, but the odd separation issues people have seen appear to be caused by apgsearch only removing the first extraneous object whenever the pseudo-SL-separation script is called.

[gameoflifeboy]

Not all that high on the oddness scale, but I'm unable to wrap my head around it: although scorbiclife contributed a haul to B348/S4 way back in February 2015, the pie chart for that rule is, right now, only showing me and C. Wang. What gives?

The root for that haul is missing an "m_" flag that the other hauls have.
This appears to interfere with whatever script generates the pie chart although individual census pages and individual object pages recognize the existence of the haul. The pie chart's percentages would be perfect if the haul from scorbiclife is treated as nonexistent, but for example xp6_7o2zo7g1z1 has two sample soups; one from scorbiclife's haul and one from a different hone.

I don't think so. The pie chart feature got added in 2015-02-27, over a year before apgmera got released. On the other hand, the haul was submitted on 2015-02-26. I remember that when the pie chart was released, it didn't count already existing hauls.

There are a few other cases of this, where a rule has been barely touched since the beginning of Catagolue. For example, Adam submitted hauls to b36s23/D4_+1 on 2015-02-21, but he is not shown on the pie chart, while the others are.

[Apple Bottom]

The root for that haul is missing an "m_" flag that the other hauls have.

Ah, apgsearch 1.x hauls have no prefix; that's normal and expected. A prefix ("n_", probably for "new") got added for apgnano, presumably to allow for easy identification of apgnano-generated data in case a bug tainting said data was found. The "m_" ("mera") prefix similarly indicates hauls apgmera-generated data.

This appears to interfere with whatever script generates the pie chart although individual census pages and individual object pages recognize the existence of the haul. The pie chart's percentages would be perfect if the haul from scorbiclife is treated as nonexistent, but for example xp6_7o2zo7g1z1 has two sample soups; one from scorbiclife's haul and one from a different hone.
EDIT: Unrelated, but the odd separation issues people have seen appear to be caused by apgsearch only removing the first extraneous object whenever the pseudo-SL-separation script is called.[/quote]

I don't think so. The pie chart feature got added in 2015-02-27, over a year before apgmera got released. On the other hand, the haul was submitted on 2015-02-26. I remember that when the pie chart was released, it didn't count already existing hauls.

There are a few other cases of this, where a rule has been barely touched since the beginning of Catagolue. For example, Adam submitted hauls to b36s23/D4_+1 on 2015-02-21, but he is not shown on the pie chart, while the others are.

That would be the problem then, most likely.

It makes sense when you think about it -- for well-searched rulesyms like B3/S23/C1, it wouldn't be economical to regenerate the pie chart data all the time, not to mention that information on older hauls isn't even necessarily available anymore.

[Apple Bottom]

• Apparently linear growths can contain minus signs.

Although that yl in B38/S23 otherwise remains the sole example, several such patterns have since been seen in Re: B2e3ai4arw5678/S3-an4ar5i678 (thread here):

Code: Select all

yl10_1_-2_cfbd905560ae405f4a73d0406a9ab7fd
yl10_1_-18_f2e04a84372125c359fbfb56596c0612
yl10_1_-2_7193d666ba18f7286123e404e9fdc05a
yl10_1_-2_c60fd8e1adccbd3e96b6bca4e9be3011
yl10_1_-2_e927c456374f09dd8436beca2ca5bbd5
yl170_1_-34_d9af19bc0eda08e30813cb09754fbc4d
yl30_1_-6_a097d07a2980383b354059fa18166728
yl30_1_-6_041af48387f737c4d9c4403d97e67cc9
yl30_1_-6_b4e10c490f822402a880fe2b3a6a1c37
yl30_1_-6_e3e8a2adb6ea4f9d571b78eca88d5aff
yl30_1_-6_f0bda65b143e7b3f7e6f2de886477a55
yl40_1_-8_1e6ea72094f9cb9dd26c508da5f1d1e9
yl5_1_-1_12035d34d6e244c1487a76e33ad6d8cc
yl70_1_-14_00e228b0c55b06cbe991d3bfa53a8fad
yl70_1_-14_5b02466ae1ef1cf13dec9098229c017a
yl90_1_-18_5456ac10da3adea154bcbc9aa5d48d3b
yl5_1_-8_54f945bd2da4a5996694af58dd12f82f

yl10_1_-2_cfbd905560ae405f4a73d0406a9ab7fd is the most common of these, having occurred (right now) 24 times.

[toroidalet]

Haul has a PATHOLOGICAL with 1 occurrence but 2 soups.

[Apple Bottom]

Haul has a PATHOLOGICAL with 1 occurrence but 2 soups.

That happens fairly often, it seems -- the number of PATHOLOGICALs in B2e3ai4arw5678/S3-an4ar5i678/C1 has long been one less than the number of sample soups, too. (However, since the number of sample soups now exceeds 500, Catagolue isn't listing them all, so it's not obvious anymore that this is indeed the case.)

[toroidalet]

8x32 soups should be 8x32 in length, but Catagolue records them as 16x32 (The lower 8 rows are blank)

[Rhombic]

Huge bug, xq2_153 listed as both xq2 and xq4(glider)
https://catagolue.appspot.com/census/b3 ... 7-e/C1/xq4

[drc]

Huge bug, xq2_153 listed as both xq2 and xq4(glider)
https://catagolue.appspot.com/census/b3 ... 7-e/C1/xq4

Woah, that's scary. It doesn't happen for other p2/p4 counterfeit gliders though, for some reason.

[drc]

This haul, submitted by muzik, contains several still lifes that are just the soup itself partitioned into objects, dots, and smaller groups of cells. It was committed, making the still life list look massive, when before it was just several 20-cell-and-under still lifes.

9a3slIK.png (7.78 KiB) Viewed 534 times

slb15gA.png (15.86 KiB) Viewed 534 times

I feel like this could shed some light on the error checking that catagolue does, and maybe some extra checks could be done?

Also, to clarify, this rule isn't anything like B/S012345678 where this type of behaviour could be understandable. Plus, the object pages don't work:

gtyLK9q.png (21.3 KiB) Viewed 534 times

EDIT: I'm certain this was a bug in the script and not actual malicious intent, since things like this happen to be pretty common judging by the 44 other replies in this thread.

[muzik]

Well that's perfectly normal behaviour and not concerning at all.

EDIT: oh yay, seems like that was the most recent haul, and nothing has been uploaded since, and it is not certaintly not sticking up to its schedule...

[Apple Bottom]

Another oddity: Catagolue keeps on getting new non-totalistic rules with "v" neighbor alignment; recent examples include b2cvs and b2c3ae4ai56cs2-kv3-eqv4.

As far as I recall, "v" used to denote the "n" neighborhood; it was briefly used when Catagolue started census'ing non-totalistic rules, used in e.g. b2iv3s123a. But it's long been obsolete, and I'm surprised to see it being used still for new submissions.

[drc]

It seems to be mainly wwei23 using the 'v' version.

[Apple Bottom]

It seems to be mainly wwei23 using the 'v' version.

In these two cases, yes. I don't have the time right now to check the rest, but here's a list of all rules I know to have been looked at that have a "v":

Code: Select all

b2-a3s2-akv
b2ei3ajkr4-cjrvy5-eiqvy6-ak7-e8s1-c2ak3-acjkr4jrvy5-acjkr6ak7-c
b2ei3ajkr4-cjrvy5-eiqvy6-ak7-es1-c2ak3-acjkr4jrvy5-acjkr6ak7-c
b2i34cik7s23-a4cikv7
b2iv3s123a
b34ajs2-a35v
b35-v6cs2-i34q
b35v7-es23
b35vs23-a
b35ys2-i34qv
b3-e468s2-ck4ekvy6-v
b3s1-e2-cv3
b3s2-i34v

For b2c3ae4ai56cs2-kv3-eqv4 at least, the "regular" version of that rule, using the "n", also exists on Catagolue: b2c3ae4ai56cs2-kn3-enq4.