ConwayLife.com

calcyman wrote:1. I have no idea. A haul can't exceed one megabyte in size, though.

Is there a way to have larger hauls committed manually, or submit them in chunks? I was investigating a rather productive rule (B45S1234/D8_1), and when I ended the search after ~400k soups the haul had already ballooned to about 3.5 MiB. (I could've sworn I asked for 100,000 soups - and yes, I edited the script to change the minimum first -, but maybe I mistyped. Hooves, wouldn't ya know.)

It would be a shame to see this haul go to waste.

Could someone explain how the rules used in the censusing process work? I figured out CoalesceObjects, ClassifyObjects, and ExpungeObjects, but the rest (in particular ContagiousLife) are confusing to me.

A for awesome wrote:Could someone explain how the rules used in the censusing process work? I figured out CoalesceObjects, ClassifyObjects, and ExpungeObjects, but the rest (in particular ContagiousLife) are confusing to me.

From what I can tell, ContagiousLife is used to separate objects from each other, but not in such a way that an unstable object remains. (e.g. a block on table will be registered as a block on table rather than as a table and block separately, as the table alone is not stable)

I'm sure I'm just missing the bleedin' obvious, but I'm puzzled: this haul counts 1 PATHOLOGICAL object, but offers two (different) sample soups.

Shouldn't it be reporting 2 PATHOLOGICALs?

Apple Bottom wrote:I'm sure I'm just missing the bleedin' obvious, but I'm puzzled: this haul counts 1 PATHOLOGICAL object, but offers two (different) sample soups.

Shouldn't it be reporting 2 PATHOLOGICALs?

Not sure what you mean, but I think that the same PATHOLOGICAL occured in two soups, but the strangest thing that it said 1 occurrence but displays 2 soups from the haul, I don't know what's going on though.¯\_(ツ)_/¯

I think apgsearch does not distinguish between pathological objects. Even if you find two soups producing pathological objects A and B, it can't further label it with an apgcode, I think. And I think it's the same for the zz_LINEAR and zz_REPLICATOR objects, isn't it? Even if there are more than one replicator in a rule, apgsearch would not distinguish them.
A side effect of this is that on Catagolue, PATHOLOGICAL contains pathological objects with all rules.

Scorbie is right - each soup with an unidentifiable pattern is scored separately with no attempt to compare them. I suspect apgsearch could report more pathological patterns than soups (though I haven't double checked to see if this is the case) but it shouldn't report more sample soups than the number of pathological patterns found. Strangely enough, most of the other 1000000 soup hauls don't have any soups detected as pathological, but this one has seven sample soups for a total of 5.

All y'all raise good points, and I do apologize for the confusion.

What I meant was this: if a pathological object occurred twice, for two different soups, why is the total number of pathological objects reported by apgsearch one, rather than two?

This also happened in other hauls for this rule. This one counts one occurrence of a pathological object, but reports four sample soups. This one counts five occurrences but reports eight sample soups. And so on.

I can understand there not being a sample soup for every occurrence of an object, but if there's more soups than occurrences, then my hunch is that apgsearch isn't counting properly. But that can't really be, now can it? So what's going on here?

Whenever I enter a rule, it seems to revert to B3/S23
Edit: Closing and restarting fixes it, but still annoying.

Never mind, still happening. Shame

drc wrote:Whenever I enter a rule, it seems to revert to B3/S23.

When you run apgsearch it sometimes first does some work verifying some soups in B3/S23. Then after a short time it will start the work you asked it to. This could be what you're seeing.

I'm posting this here since there's no dedicated Catagolue thread (there isn't, is there?), and since it's not specifically about apg* 2.x or 3.x.

Certain links don't work and cause internal server errors, e.g. this haul link: https://catagolue.appspot.com/haul/b2-a ... e644c3ce9b

My uneducated guess is that the server code's running into a resource limit of some kind, and that this is due to the large number of high-period (xq40) spaceship flotillas in this rule that have to be rendered as animated SVGs.

Behold, one of the cringiest questions ever, from someone who's supposed to be good with computers:

How do I run this?


I've downloaded the latest version of Python and the apgsearch py file, and I have golly, but when I try to double click on the apgsearch py file it shows a black box for a fraction of a second before just vanishing for no reason.

muzik wrote:Behold, one of the cringiest questions ever, from someone who's supposed to be good with computers:

How do I run this?


I've downloaded the latest version of Python and the apgsearch py file, and I have golly, but when I try to double click on the apgsearch py file it shows a black box for a fraction of a second before just vanishing for no reason.

Add apgsearch.py to Golly's Scripts folder, then double-click the file from within Golly, instead of your file explorer.

Kazyan wrote:Add apgsearch.py to Golly's Scripts folder, then double-click the file from within Golly, instead of your file explorer.

When I do this, and click on it, it just gives a dialog box "Could not load the Python library" and asks me to type in the file adress for python27.dll and even when I do, the same box just comes up again.

Tried both with python27.dll at the end and not.


Where exactly should the file be located? When I searched for it, I found it in system32, but I'm not sure if that's the correct file. Is there a way to generate one?

Just to say: I do indeed have both Python and Golly installed, and Python works pretty normally as I remember it. Golly also works pretty much perfectly (I have more experience with the mobile version and as such use it more) so there shouldn't really be this problem.

The most common problem when trying to run Python scripts in Golly occurs when the user has installed different bittages of Python and Golly. Can you ensure they're either both 64-bit or both 32-bit?

-

drc wrote:Did you update catagolue, because I just suddenly discovered about 15 objects today...

Yes, I want to be able to make Catagolue delete old b3s23/C1 hauls, but retain the ones that contain the first few instances of interesting objects. As a minor side-effect, all of the 'discoveries' sections have expanded.

calcyman wrote:The most common problem when trying to run Python scripts in Golly occurs when the user has installed different bittages of Python and Golly. Can you ensure they're either both 64-bit or both 32-bit?

OH now I see. looks like I'm running 32 bit golly.

Where can I get the 64 bit version?

EDIT: Found it, let's see how this goes

EDIT2: YUY! It works! Just uploaded my pathetically small first haul for regular life. Now to test out some more rules.

EDIT3: Currently peppering B3/S12 with small hauls. Seems to be working fairly well. But how do you search non-Life like rules such as B2in3/S123a?

muzik wrote:But how do you search non-Life like rules such as B2in3/S123a?

Download an 'i' version of apgsearch here:

viewtopic.php?f=9&t=1480&start=50

calcyman wrote:The most common problem when trying to run Python scripts in Golly occurs when the user has installed different bittages of Python and Golly. Can you ensure they're either both 64-bit or both 32-bit?

Ah, now, this is a much more helpful answer than what I was going to say, which was 'get a sorcerer to fix it and then never touch it again', as per my own experiences in making Python play nice with Golly.

Kazyan wrote:I was going to say, which was 'get a sorcerer to fix it and then never touch it again', as per my own experiences in making Python play nice with Golly.

LOL. Who was the sorceror? Or am I getting it wrong?

calcyman wrote:Yes, I want to be able to make Catagolue delete old b3s23/C1 hauls, but retain the ones that contain the first few instances of interesting objects. As a minor side-effect, all of the 'discoveries' sections have expanded.

Clicking on your slice on the b3s23/C1 pie chart now raises an internal server error -- I've got a hunch that this is no coincidence, and that the site's is instead exceeding its maximum per-request execution time.

Looks like my apgsearch glitched out and submitted a mutant Siamese twin haul:




I mean, not that that's a major problem or anything, just kinda interesting