ConwayLife.com

muzik wrote:Also, why do rules like b/s012345678 take absolutely AGES to search?

There is no evolution of any kind in that rule: no cells are born (no B conditions), and no cells die (all S conditions). I'm not sure that's particularly interesting.

That said I'm getting about 1000 soups/second there, so for me at least it's not that slow. (And do keep in mind that while there's no evolution, soups still have to separated into objects, and these objects classified and encoded. And most of the ones seen here will be unique, so caching won't help speed things up.)

I've asked this before, but what keeps it from using, let's say ruleloader, to classify the objects? This would allow for more non-totalistic searches, since 1.0 is too slow compared to 3.1.

Apple Bottom wrote:

muzik wrote:Also, why do rules like b/s012345678 take absolutely AGES to search?

There is no evolution of any kind in that rule: no cells are born (no B conditions), and no cells die (all S conditions). I'm not sure that's particularly interesting.

That said I'm getting about 1000 soups/second there, so for me at least it's not that slow. (And do keep in mind that while there's no evolution, soups still have to separated into objects, and these objects classified and encoded. And most of the ones seen here will be unique, so caching won't help speed things up.)

Can you upload a haul, just to see what happens?

muzik wrote:Can you upload a haul, just to see what happens?

What happen is just what you'd expect. Since every soup is either a distinct object or composed of several, even a 10k soup haul significantly exceeds Catagolue's 1 MiB haul size limit. And since Catagolue also currently enforces a lower limit of 10k soups, the rule simply ain't amenable to uploading to Catagolue at all.

Apple Bottom wrote:

muzik wrote:Can you upload a haul, just to see what happens?

What happen is just what you'd expect. Since every soup is either a distinct object or composed of several, even a 10k soup haul significantly exceeds Catagolue's 1 MiB haul size limit. And since Catagolue also currently enforces a lower limit of 10k soups, the rule simply ain't amenable to uploading to Catagolue at all.

Tried it, and those results happened.

Are there any rules which exhibit similar behaviour, but aren't going to create ginormous hauls?

muzik wrote:

Apple Bottom wrote:What happen is just what you'd expect. Since every soup is either a distinct object or composed of several, even a 10k soup haul significantly exceeds Catagolue's 1 MiB haul size limit. And since Catagolue also currently enforces a lower limit of 10k soups, the rule simply ain't amenable to uploading to Catagolue at all.

Tried it, and those results happened.

Are there any rules which exhibit similar behaviour, but aren't going to create ginormous hauls?

Depends on how stringently you interpret the word "similar". By its very nature any rule in which little to no evolution happens and where every or almost every soup yields a unique object is is going to have a large number of distinct objects, and therefore large hauls. In order for hauls to be smaller there have to be fewer distinct objects, which implies that either a) some soups must yield the same object, or b) some soups must fail to yield any objects (i.e. die down to nothing).

That said of course rules can have a very long long tail. Day & Night is a good example of such a rule, but for the reasons discussed earlier in this thread perhaps we shouldn't search (or search for) such rules until Calcyman's had a chance to make Catalogue more robust and keep it from choking on rules with too many distinct (census'ed) objects.

EDIT: I noticed uncommitted Day & Night hauls are now getting committed. Does that mean that the site's fixed and Day & Night's fair game for souping again?

EDIT 2: and the C1 /textcensus for Day & Night's working again, too. Woohoo!

muzik: I suggest making your b3s23/C1 hauls larger, since at the moment they're failing the chi-squared test and therefore being rejected from the census:

https://catagolue.appspot.com/haul/b3s23/C1?committed=4

Larger hauls will avoid this problem (by the central limit theorem); I suggest a haul size of at least 10^6 soups.

Apple Bottom wrote:Day & Night is a good example of such a rule, but for the reasons discussed earlier in this thread perhaps we shouldn't search (or search for) such rules until Calcyman's had a chance to make Catalogue more robust and keep it from choking on rules with too many distinct (census'ed) objects.

It should be able to support arbitrarily complicated censuses now (subject to each tabulation being < 1 MB, which has always been the case -- anything above this limit is tacitly discarded). I've also replaced a List with an Iterable in the /textcensus code, so you can now download the entire Day&Night census (448k objects, 13.7 megabytes) without crashing the server. It takes 30 seconds, though, so I wouldn't recommend it!

drc wrote:I've asked this before, but what keeps it from using, let's say ruleloader, to classify the objects? This would allow for more non-totalistic searches, since 1.0 is too slow compared to 3.1.

What would I use for actually running the soups to completion? The script rule2asm.py can only generate vlife code for outer-totalistic rules, rather than arbitrary isotropic rules. And the main reason that 3.x is much faster than 1.x is the faster algorithm (vlife as opposed to RuleLoader).

Apple Bottom wrote:EDIT: I noticed uncommitted Day & Night hauls are now getting committed. Does that mean that the site's fixed and Day & Night's fair game for souping again?

Yes. It only loads a single tabulation at a time into memory, updates it, and pushes it back into the datastore.

calcyman wrote:muzik: I suggest making your b3s23/C1 hauls larger, since at the moment they're failing the chi-squared test and therefore being rejected from the census:

https://catagolue.appspot.com/haul/b3s23/C1?committed=4

You've got me curious now, what do the various values for "commited" mean? As far as I can tell now, 0 is "new", 1 is (possibly) "verified but uncommitted", 2 is "committed" and 4 is "rejected", but there's also others: b3s23/C1 has both 3 and 6, and Day & Night has 5.

10 shows the same hauls, BTW (so it looks like the site's only using the first digit), and supplying a string that does not begin with a digit causes an internal server error.

Yes. It only loads a single tabulation at a time into memory, updates it, and pushes it back into the datastore.

Sweet!

So, apparently, commenting "K" on xs12_rahr rickrolls you.

calcyman pls

muzik wrote:So, apparently, commenting "K" on xs12_rahr rickrolls you.

calcyman pls

So does posting any short text on any object

After some further modifications, Catagolue can now safely and reliably handle 100 hauls (each of size 8M soups) per hour in Day&Night.

How about b3478/s5678?

Can we have torus implementation? It would speed up HighLife, allow DryLife, and (maybe, I've tested and it lasts very long) even B2-k/S0, because every soup would eventually settle: Unfortunately, this would lessen spaceships.

Also, can we have apgsearch mode where it manually detect objects and remove them? It would be cool, and again, allow DryLife

drc wrote:Also, can we have apgsearch mode where it manually detect objects and remove them? It would be cool, and again, allow DryLife

And also lessen spaceships and some oscillators, rip copperhead and queen bee shuttle

muzik wrote: And also lessen spaceships and some oscillators, rip copperhead and queen bee shuttle

It wouldn't be used for life.

Also, apgsearch has slowed down for me, from 1500 ps to 400ps.

This happened while searching b37s13567:

Error codes

I don't get it, why are there yl linear growth patterns and zz linear growth patterns?

muzik wrote:I don't get it, why are there yl linear growth patterns and zz linear growth patterns?

zz is a different type, and it is used when non-periodic behaviour is detected

Do discoveries in the non-c1 symmetries of b3s23 count towards your list of discoveries?

No.

Why not?

Because for rules like Day and Night, you would have thousands, maybe even millions of discoveries.

Also, I have a problem. When I'm running prime95 (a mersenne prime search program that uses 50% of my cpu), APG slows down drastically, from 1600 a second to 600 a second. Why is this? I assume it has to do with memory, but I don't know how much APG takes. Prime95 uses 24MB though, and I have 4GB. I'm only using 1.6GB atm

Also I think on every object page it should show its C1 occurrences, as well as who discovered it.

drc wrote:Because for rules like Day and Night, you would have thousands, maybe even millions of discoveries.

I clearly stated b3s23.

They're not really "natural" discoveries in that case, since the symmetry makes it lots easier for, well, symmetrical patterns to emerge.