ConwayLife.com

muzik wrote:Inflated censuses aren't correctly bolded.

They're not official, in the sense that Catagolue doesn't understand them yet.

I assume that's the same reason why the soups returned on catagolue are still made of 1x1 blocks, rather than the specified inflation?

Saka_Test has 131,717,653,784 objects from only 14 hauls and 166,452 soups.

This rule has several xs0_0's, which is slightly concerning

B3/S23/iiii8x32 has precisely 1 soup to its name, right now.

(Can we please stop doing this? B3/S23 isn't even explosive, and iiii8x32 isn't THAT slow to search. There's no reason to not submit at least 10k soups per haul here, and (as with explosive rules) I question whether having a census generated from 1 soup is even useful. Certainly it's questionable whether it's representative.)

My fault, meant to type b37s23.

Another not-really oddity, all inflated symmetries with at least odd bilateral symmetry turn even bilateral.

This soup claims to contain an xq32_4eveea44e but doesn't.

https://catagolue.appspot.com/hashsoup/ ... 3678s34678

Either my computer is strange or there are little dashes on the left side of oscs like xp4_6f when viewed as "haul-thumbnails": https://catagolue.appspot.com/haul/b3-n ... 11d8340887

Saka wrote:Either my computer is strange or there are little dashes on the left side of oscs like xp4_6f when viewed as "haul-thumbnails": https://catagolue.appspot.com/haul/b3-n ... 11d8340887

Looks fine to me:

Apple Bottom wrote:
Looks fine to me:

[pic]

What I see:

These are getting reported as yl1 Also, ov_p0 Also, is this what happens when hauls are just being commited?

Saka wrote:These are getting reported as yl1

Code: Select all

x = 16, y = 16, rule = B2ci3an4ai5acin6acn78/S2ci3ain4a5acin6-ek78
2o3b2o2bo4b2o$2b2ob2ob2o3bobo$b2obobob3o2b3o$6o2b4obobo$3ob5ob3o$2b2o
2b2ob2o2bo$2b3o2bo7bo$o2b2ob4ob2ob2o$3o2b3o2b2ob2o$ob2ob3o2bob2obo$o2b
obob2obo2bobo$2b2ob2o2b2obob2o$5b2o3b3ob2o$obo4bob3o3bo$b2obo6bob3o$bo
2bobo2b4obo!

That's normal- apgsearch looks at the population plot and doesn't take into consideration the overall period.

Also, is this what happens when hauls are just being commited?

Yes, I have seen this happen before and it is completely normal.

Not sure about the ov_p0

Apple Bottom wrote:What kind of D4, I hear you ask? Judging by a sample sample soup it's actually C1 in disguise.

This might've been something else, but Catagolue didn't know how to render it.
Another semi-oddity:
Pseudo-objects have object pages.

calcyman wrote:Before someone tries to claim this as an oddity, census keys with more than 25 characters in the right-hand column of https://catagolue.appspot.com/census are displayed without a timestamp. This is deliberate, so that they don't consume too much horizontal space and break the beautiful columnar layout (as they did before).

Is this feature really necessary anymore, now that censuses with even longer names are now shortened with a ...?

Careful!! If it hasn't happened already, please, let's do something about it (potetially moving any earlier census to the correct name):

New hauls are submitted to the rules with the correct name, like census/b2cen3jkq4eiqrz5-jn6eik7e8s02n3anq4knqr5jy6ein7c

However, remember that with the Python version, they would get submitted to the S7-e and B7-c equivalent, always adding the minus when it's an equal number of neighbourhoods.
This will probably create, at some point, two parallel censuses for the same rule!!

My suggestion: moving all previous rules to their appropriate name. It should be feasible, right?

Rhombic wrote:However, remember that with the Python version, they would get submitted to the S7-e and B7-c equivalent, always adding the minus when it's an equal number of neighbourhoods.
This will probably create, at some point, two parallel censuses for the same rule!!

There's indeed a number of rules which have more than one Catagolue census to their name. (My favorite is Conway Life itself, where some jokester submitted results to B37-ce/S23 and B3aijnqrkyce/S2ainkce3aijnqrkyce.)

The list of rules investigated on Catagolue (on the wiki) groups these together, BTW. Not quite the same as having the respective censuses (censi?) merged, but at least this way you can easily see whether there are any duplicates, say if you're interested in a specific rule. Manually merging the textcensus'es if you intend to consume Catagolue's census data would be fairly trivial with this as well.

I'm getting apgsearch to do B1-ce2-cekain3cekainyqjr4-cekainyqjrtwz5-cekainyqjr6-cekain7-ce/S1-ce2cekain3cekainyqjr4-cekainyqjrtwz5-cekainyqjr6-cekain7-ce

EDIT: Dangit got abloaded as B3/S23...

Apple Bottom wrote:

Rhombic wrote:However, remember that with the Python version, they would get submitted to the S7-e and B7-c equivalent, always adding the minus when it's an equal number of neighbourhoods.
This will probably create, at some point, two parallel censuses for the same rule!!

There's indeed a number of rules which have more than one Catagolue census to their name. (My favorite is Conway Life itself, where some jokester submitted results to B37-ce/S23 and B3aijnqrkyce/S2ainkce3aijnqrkyce.)

Well yes, there's those, but in this case, the bulk of all the submitted Python versions uses the syntax where in the event of equality, the -(minus) is preferred. The current apgluxe writes it properly. In certain rules, this will cause rules to be separated into two pages, without any links to point that out. Ideally, they should be merged in the correct page.

i.e, in case I didn't explain myself correctly, the B37-ce/S23 is just a joke with a few soups. However, maaaany nt rules aren't a joke and the main bulk of their finds is in an incorrect syntax page.

Apple Bottom wrote:Another oddity: lists of symmetries for a given rule are limited to 40 symmetries.

Calcyman fixed this quickly, but apparently there is still a limit of 80 symmetry types, and b3s23 is not showing all symmetry types as a result again. (Other rules are unaffected; none even comes to close to 40 symmetry types, much less 80.)

EDIT: also, Catagolue thinks that "Saka_x+1-2x_TEST" is a backup census of "Saka_x+1", generated on "2x_TEST".

Apple Bottom wrote: EDIT: also, Catagolue thinks that "Saka_x+1-2x_TEST" is a backup census of "Saka_x+1", generated on "2x_TEST".

At that time I didnt understand the maths and stuff so I just messed around. I didnt know that putting a "-" would make Catagolue think it's a backup. I'll send you the script once I get on my computer.

Rhombic wrote:i.e, in case I didn't explain myself correctly, the B37-ce/S23 is just a joke with a few soups. However, maaaany nt rules aren't a joke and the main bulk of their finds is in an incorrect syntax page.

On a similar note, the symmetry 32x32 should probably be renamed to something like WW_32x32_TEST or something, in the event we get actual support for 32x32 soups.

Saka_Test has a 500 sever error as of me posting this.

Was it because of the '?' or the unicode snowman?

All patterns everywhere are showing as ?? for me.


EDIT: well that fixed itself pretty quickly.

Saka wrote:Saka_Test has a 500 sever error as of me posting this.

Was it because of the '?' or the unicode snowman?

It was the unicode snowman. Everything works properly now.

muzik wrote:All patterns everywhere are showing as ?? for me.

EDIT: well that fixed itself pretty quickly.

I was correcting the uncaught exception from Saka_Test, and made a mistake in the regex for recognising valid apgcodes.