apgsearch v3.1

[Apple Bottom]

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.)

[drc]

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.

[muzik]

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?

[Apple Bottom]

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.

[muzik]

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?

[Apple Bottom]

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!

[calcyman]

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.

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!

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).

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.

[Apple Bottom]

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!

[muzik]

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

calcyman pls

[drc]

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

calcyman pls

So does posting any short text on any object

[calcyman]

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

[muzik]

How about b3478/s5678?

[drc]

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:

Code: Select all

x = 16, y = 16, rule = B37/S23:T100,100
o2bob2o4b2o2bo$bo6b3ob2obo$b5o2bo2b2o2bo$o4b5o3bobo$b2o4b2ob6o$4b2ob3o
bob3o$2bo3b3o2b2obo$bob3obo6bo$bob3o3bo2b3o$2obob2o2bob4o$b3obo3bobob
3o$2obo2b2obobobo$b3o3b9o$o2bob2o2b2o$ob2o5b3ob2o$3obo2b3ob4o!

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

[muzik]

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

[drc]

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.

[drc]

This happened while searching b37s13567:

Code: Select all

ERROR: Pathological moving object produced by pseudoBangBang.
Initial population: 30
Supposed period: 8
8, 0, 1, 9, 0, 1, 12, 0, 1, 9, 1, 1, 10, 1, 1, 11, 1, 1, 12, 1, 1, 13, 1, 1, 8, 2, 1, 9, 2, 1, 10, 2, 1, 11, 2, 1, 12, 2, 1, 4, 3, 1, 7, 3, 1, 10, 3, 1, 11, 3, 1, 8, 4, 1, 9, 4, 1, 10, 4, 1, 11, 4, 1, 12, 4, 1, 9, 5, 1, 10, 5, 1, 11, 5, 1, 12, 5, 1, 13, 5, 1, 8, 6, 1, 9, 6, 1, 12, 6, 1,
8, 0, 2, 9, 0, 2, 10, 0, 2, 11, 0, 2, 12, 0, 2, 13, 0, 2, 14, 0, 2, 15, 0, 2, 16, 0, 2, 17, 0, 1, 8, 1, 2, 9, 1, 2, 10, 1, 2, 11, 1, 2, 12, 1, 2, 13, 1, 1, 14, 1, 1, 15, 1, 1, 16, 1, 1, 17, 1, 1, 18, 1, 1, 8, 2, 2, 9, 2, 2, 10, 2, 2, 11, 2, 2, 12, 2, 1, 13, 2, 1, 14, 2, 2, 15, 2, 1, 16, 2, 1, 17, 2, 1, 4, 3, 2, 7, 3, 2, 8, 3, 2, 9, 3, 2, 10, 3, 2, 11, 3, 2, 12, 3, 2, 13, 3, 1, 14, 3, 2, 15, 3, 1, 16, 3, 1, 8, 4, 2, 9, 4, 2, 10, 4, 2, 11, 4, 2, 12, 4, 1, 13, 4, 1, 14, 4, 2, 15, 4, 1, 16, 4, 1, 17, 4, 1, 8, 5, 2, 9, 5, 2, 10, 5, 2, 11, 5, 2, 12, 5, 2, 13, 5, 1, 14, 5, 1, 15, 5, 1, 16, 5, 1, 17, 5, 1, 18, 5, 1, 8, 6, 2, 9, 6, 2, 10, 6, 2, 11, 6, 2, 12, 6, 2, 13, 6, 2, 14, 6, 2, 15, 6, 2, 16, 6, 2, 17, 6, 1,

[drc]

Error codes

Code: Select all

Pathological object detected!!!
Chaotic-growth pattern detected: zz_EXPLOSIVE
Chaotic-growth pattern detected: zz_LINEAR
Chaotic-growth pattern detected: zz_REPLICATOR
Chaotic-growth pattern detected: zz_QUADRATIC

[muzik]

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

[drc]

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

[muzik]

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

[calcyman]

No.

[muzik]

Why not?

[drc]

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.

[muzik]

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

I clearly stated b3s23.

[M. I. Wright]

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