apgsearch v1.0

For general discussion about Conway's Game of Life.
User avatar
calcyman
Posts: 2198
Joined: June 1st, 2009, 4:32 pm

Re: apgsearch v1.0

Post by calcyman » February 24th, 2015, 7:54 am

I've also got this error.
If you mean the unclosed HTML bold tag, I resolved that error over 24 hours ago (and you can see how old the screenshot is from the fact that there are now 164 committed hauls with just over 10^10 objects from 461 million soups!).
The B36/S125 C1 census listed the double version of the only known 2x2 wickstretcher as period 4, but it is still period 8, doesn't it??
The number after 'yl' does not claim to be the period. It's actually the minimum N such that the population of the entire pattern can be expressed as N interleaved linear functions. So, for example, the B3/S23 wickstretcher which grows a line of ants between a p5 oscillator and c/4 spaceship would be classified as yl20.

(Also, Dave, thanks for the auto-updating script.)
What do you do with ill crystallographers? Take them to the mono-clinic!

User avatar
dvgrn
Moderator
Posts: 6725
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: apgsearch v1.0

Post by dvgrn » February 24th, 2015, 8:36 am

I'm a little puzzled by the oversize objects reported in B36/S125. It looks as if apgsearch isn't successfully separating two widely separated same-direction xq8_2je4 spaceships... or am I misinterpreting something obvious here?

Sample soup reporting "ov":

Code: Select all

#C [[ THUMBNAIL AUTOSTART ZOOM 5.21 Y 33 STOP 600 ]]
x = 16, y = 16, rule = B36/S125
b5ob3o2bo$b2obo3bob3ob2o$3obo3b3obo$2b2o4b2obo2bo$obo2b3o2bo2b2o$5b2ob
2o5bo$o2bob2o2b4ob2o$2b2o3bobo4b2o$bo6bob2obo$b4obo4bo2bo$b2o2bob3o2bo
b2o$bo2b4o4b2o$ob4o7b3o$o2b4o3b2ob3o$3bo3bo7bo$bo2bobo5bo2bo!

David
Posts: 212
Joined: November 3rd, 2009, 2:47 am
Location: Daejeon, South Korea

Re: apgsearch v1.0

Post by David » February 24th, 2015, 8:54 am

calcyman wrote:
I've also got this error.
If you mean the unclosed HTML bold tag, I resolved that error over 24 hours ago (and you can see how old the screenshot is from the fact that there are now 164 committed hauls with just over 10^10 objects from 461 million soups!).
I meant, there isn't "Click here to commit them to the census". Do you mean I don't have authority??

flipper77
Posts: 197
Joined: October 24th, 2010, 3:25 am
Location: Spokane, WA

Re: apgsearch v1.0

Post by flipper77 » February 24th, 2015, 12:42 pm

velcrorex wrote:From the asymmetric life search I see that we're missing only one 10 cell still life (10.15) ...
Not anymore, all still lifes for the b3s23/C1 census from 4 - 10 bits has been filled in! Just 2 more before 11 bits is done(who knows how long that will be).

Also, auto-updates sounds like a good idea, but I'm perfectly fine with a simple prompt if that's what you're going to do. It's just that with an auto-update feature, like dvgrn said, I'd prefer this only at the start of a script instead of after every new haul.

User avatar
Scorbie
Posts: 1445
Joined: December 7th, 2013, 1:05 am

Re: apgsearch v1.0

Post by Scorbie » February 24th, 2015, 12:45 pm

calcyman wrote:Meanwhile, the actual b3s23/D4_+4 census has found a genuinely new (i.e. not featured in jslife) p30 shuttle hassler:http://catagolue.appspot.com/object/xp3 ... 0103/b3s23
Hehe... Thanks! I just wanted to fill in the unexplored symmetries. I inadvertently let the search too long and that found some interesting patterns.
I saw that pattern somewhere in the forum, I'm sure, but it didn't catch much interest... I think it was in the thread for your discoveries series, but I can't locate it... Just saying this for credit.

And it looks like there's also a new p4... or isn't it?

Code: Select all

x = 31, y = 14, rule = B3/S23
3b2o2b2o$2b2o4b2o$bo8bo11b2o2b2o$o10bo9b2o4b2o$bobo4bobo9bo8bo$4b4o11b
o10bo$20bobo4bobo$23b4o$4b4o$bobo4bobo10bo6bo$o10bo9bobo2bobo$bo8bo9bo
bo4bobo$2b2o4b2o12bo4bo$3b2o2b2o!
http://catagolue.appspot.com/object/xp4 ... cf31/b3s23
EDIT: There's these similar variants in jslife, but I'm not sure why this p4 is not listed.

Code: Select all

x = 36, y = 21, rule = B3/S23
3$5b2o4b2o$4b2o2b2o2b2o$3bo10bo9b2o4b2o$2bo12bo7b2o2b2o2b2o$3bobo6bobo
7bo10bo$6b6o9bo12bo$22bobo6bobo$25b6o$6b6o$3bobo6bobo8bo8bo$2bo12bo7bo
bo4bobo$3bo10bo7bobo6bobo$4b2o2b2o2b2o10bo6bo$5b2o4b2o!
Best wishes to you, Scorbie

User avatar
calcyman
Posts: 2198
Joined: June 1st, 2009, 4:32 pm

Re: apgsearch v1.0

Post by calcyman » February 24th, 2015, 2:20 pm

I meant, there isn't "Click here to commit them to the census". Do you mean I don't have authority??
The commit is now performed automatically (across all censuses) by Catagolue at the times {00:00, 02:00, 04:00, ..., 22:00}, so there's no longer a need to allow people to perform manual commits. Moreover, it's actually helpful to remove this feature, since otherwise it is conceivable that concurrency issues could occur where a single soup is double-committed. (I *think* this has already happened once, since there was a period of time during which the main census purported to have -1 uncommitted hauls.)

We're now up to 12 * 10^9 objects in the main census.
It looks as if apgsearch isn't successfully separating two widely separated same-direction xq8_2je4 spaceships...
Correct: if two spaceships are sufficiently separated, they're too large to canonise so won't reach the pseudo_bangbang() routine (which is the only thing capable of separating them). Maybe I should modify canonise() to support larger objects (and just restrict the length of the resulting strings).

There's a similar issue here due to the large period involved (pseudo_bangbang() only deals with oscillators and low-period spaceships):

http://catagolue.appspot.com/census/b368s1258/C1/xq162

By the way, I haven't seen this pentadecathlon-based hassling mechanism before (and I'm currently away from a Golly-enabled computer so I can't check it against jslife). But it must surely be known, since it's appeared 229 times amongst the 31 million D4_+4 soups:

http://catagolue.appspot.com/object/xp1 ... 04r4/b3s23
What do you do with ill crystallographers? Take them to the mono-clinic!

User avatar
Freywa
Posts: 635
Joined: June 23rd, 2011, 3:20 am
Location: Singapore
Contact:

Re: apgsearch v1.0

Post by Freywa » February 24th, 2015, 5:04 pm

And… liftoff! One of Johnston's most recent censuses has the MWSS on MWSS:

Code: Select all

x = 16, y = 16, rule = B3/S23
bo3b2obob2o2b2o$b2obobobo3bobo$2o2b2o2bobo$obo6bobobo$5o3b5o$o3bo2bobo
b4o$o2bob2ob4obobo$4b5o3bo2bo$obobo4bobobobo$2b5ob2obo2bo$bob2ob2ob3o
3bo$3b2o2bo2b3o2bo$2bo6b2obobo$2o3b4o3b3o$o2bobo5bobo$o2b2obo5b2obo!
A feather in the cap, if that is correct.
Princess of Science, Parcly Taxel

User avatar
calcyman
Posts: 2198
Joined: June 1st, 2009, 4:32 pm

Re: apgsearch v1.0

Post by calcyman » February 24th, 2015, 5:17 pm

Indeed, after just under 13 * 10^9 objects:

http://catagolue.appspot.com/census/b3s23/C1/xq4

Dave Greene (who I think censused about 40 * 10^9 objects in apgsearch in the half-year before Catagolue was launched) has seen a couple of these MWSS-on-MWSS flotillae in the wild, and I saw a LWSS-on-HWSS rather early on. I imagine the page above will begin to fill up with more two-*WSS flotillae in the next couple of weeks.
What do you do with ill crystallographers? Take them to the mono-clinic!

User avatar
codeholic
Moderator
Posts: 1142
Joined: September 13th, 2011, 8:23 am
Location: Hamburg, Germany

Re: apgsearch v1.0

Post by codeholic » February 24th, 2015, 5:21 pm

I wish there was a possibility to search for objects that contain a certain subpattern, e. g.

Code: Select all

.....
..**.
...*.
?**..
So one could find catalysts.
Ivan Fomichev

User avatar
velcrorex
Posts: 339
Joined: November 1st, 2009, 1:33 pm

Re: apgsearch v1.0

Post by velcrorex » February 24th, 2015, 5:55 pm

We now have seen all of the 10 cell still lifes in the asymmetric search. How long before 11 is complete?
-Josh Ball.

User avatar
Andrew
Moderator
Posts: 771
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia
Contact:

Re: apgsearch v1.0

Post by Andrew » February 24th, 2015, 6:43 pm

dvgrn wrote:This script seems to be able to find and update itself wherever I put it on my Windows 7 laptop. Can somebody check and see if this is equally reliable on other OSes?
Your script works fine on my Mac. It's also quite possible (on Mac at least) to execute a Golly script from another using the open command:

Code: Select all

import golly as g
g.note("calling bricklayer.py...")
g.open(g.getdir("app") + "Scripts/Python/bricklayer.py")

User avatar
calcyman
Posts: 2198
Joined: June 1st, 2009, 4:32 pm

Re: apgsearch v1.0

Post by calcyman » February 24th, 2015, 6:50 pm

codeholic wrote:I wish there was a possibility to search for objects that contain a certain subpattern, e. g. So one could find catalysts.
Certainly.

I'll make the tabulations available as machine-readable text files, and then write a Golly Python script you can run to grep a tabulation of apgcodes for a particular subpattern (in a completely brute-force manner, because why not?).
We now have seen all of the 10 cell still lifes in the asymmetric search. How long before 11 is complete?
They have a frequency of 1.47 * 10^-11 and 2.94 * 10^-11 according to Okransinski's census. Now given that the max of these two exponential random variables is itself an exponential random variable with parameter ~ 1.0 * 10^-11, we can expect to wait another 10^11 objects before they both appear.

Given that in the last 24 hours we had about 7 * 10^9 new objects in the census (beating the previous three days combined!), the expected time is a fortnight assuming people continue searching at the current rate.
What do you do with ill crystallographers? Take them to the mono-clinic!

User avatar
Andrew
Moderator
Posts: 771
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia
Contact:

Re: apgsearch v1.0

Post by Andrew » February 24th, 2015, 6:57 pm

Congratulations on the Catagolue Adam! (Or should that be Ash?) I'm already suffering from Soup Search Syndrome.

Minor typo in the apgsearch script: line 10 is missing "as" after "such".

A few ideas...

It might be nice to see a count of the number of unique objects per rule, and maybe a table of the 10 most recent new objects (along with their discovery dates). Also, a table of the 10 highest scoring soups might be fun.

David
Posts: 212
Joined: November 3rd, 2009, 2:47 am
Location: Daejeon, South Korea

Re: apgsearch v1.0

Post by David » February 25th, 2015, 1:34 am

I think not all of the pentadecathlon variations in the catalogue are singular objects. Because some of them are 2 pentadecathlons that don't "meet" at any phase.
Call me "Dannyu NDos" in Forum. Call me "Park Shinhwan"(박신환) in Wiki.

User avatar
gameoflifeboy
Posts: 474
Joined: January 15th, 2015, 2:08 am

Re: apgsearch v1.0

Post by gameoflifeboy » February 25th, 2015, 1:41 am

David wrote:I think not all of the pentadecathlon variations in the catalogue are singular objects. Because some of them are 2 pentadecathlons that don't "meet" at any phase.
The reason they are considered as one object is this:

Take this pattern in 0123/02348:

Code: Select all

x = 6, y = 7, rule = B02348/S0123
5bo3$2obo$3o$o$3bo!
Now it is a period 272 oscillator, but if you place two opposite each other so their histories overlap, even though they never touch, it becomes P136:

Code: Select all

x = 11, y = 21, rule = B02348/S0123
2bo$5bo$3b3o$2bob2o3$o8$10bo3$5b2obo$5b3o$5bo$8bo!
So this should definately be considered separate from two p272 oscillators, because it has a smaller period.

That is why, when two oscillators' histories overlap, they are considered as one.

There might be another reason, but this one is the most obvious to me.

EDIT: Seems like the two oscillators actually do affect each other slightly, but you get the idea.
Last edited by gameoflifeboy on February 26th, 2015, 4:53 pm, edited 1 time in total.

User avatar
dvgrn
Moderator
Posts: 6725
Joined: May 17th, 2009, 11:00 pm
Location: Madison, WI
Contact:

Re: apgsearch v1.0

Post by dvgrn » February 25th, 2015, 3:50 pm

Andrew wrote:
dvgrn wrote:This script seems to be able to find and update itself wherever I put it on my Windows 7 laptop. Can somebody check and see if this is equally reliable on other OSes?
Your script works fine on my Mac. It's also quite possible (on Mac at least) to execute a Golly script from another using the open command...
Hmm, no problem on Windows either, now that I try it -- even if the script is calling itself. The usual dangers of infinite regress are lurking, of course, but that's easy to avoid. It's even possible to execute more script commands after the open() command completes (though apgsearch wouldn't want to do anything but g.exit() after the open() command, I would assume).

Now I don't remember what the difficulty was with calls between Python scripts. (?)

Anyway, that means that an auto-updating apgsearch wouldn't actually even need any input from the user -- the script can replace itself and restart, completely invisibly. Might be polite to ask the user for permission to update, though...!

EDIT: Another nice idea that seems equally easy to implement is to ask how many CPUs the user wants to run apgsearch on, along the same lines as this script but even simpler because Golly instances don't have to be assigned different index numbers. If the number of CPUs requested is greater than 1, then apgsearch can

0) write the user's other search choices to a file, say apgsearch-start.txt
1) make a copy of the apgsearch script called "golly-start.py" in Golly's app directory -- first checking to see if golly-start.py already exists, and giving an error message if so. (Moving an existing golly-start.py out of the way seems presumptuous somehow, even if it's theoretically only temporary...)
2) execute N-1 new copies of Golly, maybe with a few seconds' delay between them, and
3) delete golly-start.py and apgsearch-start.txt again.

If the script is adjusted to read its input from apgsearch-start.txt if it exists, that will auto-start as many copies of apgsearch as the user requests.

wildmyron
Posts: 1398
Joined: August 9th, 2013, 12:45 am

Re: apgsearch v1.0

Post by wildmyron » February 26th, 2015, 5:09 am

calcyman wrote:
It looks as if apgsearch isn't successfully separating two widely separated same-direction xq8_2je4 spaceships...
Correct: if two spaceships are sufficiently separated, they're too large to canonise so won't reach the pseudo_bangbang() routine (which is the only thing capable of separating them). Maybe I should modify canonise() to support larger objects (and just restrict the length of the resulting strings).

There's a similar issue here due to the large period involved (pseudo_bangbang() only deals with oscillators and low-period spaceships):

http://catagolue.appspot.com/census/b368s1258/C1/xq162
There seems to be a bit more than that going on:
In the first instance, those two spaceships are only treated as a single object because one of the 100 soups in which they are processed is detected as having infinite growth (or not stabilising for some other reason). Then during census(), the rear ship runs into the history envelope of the front ship during the APG_CoalesceObjects run. The resulting pattern is too large to be canonised - as mentioned - and no attempt is made to separate them.

However, even if the pattern is canonised, pseudo_bangbang only process still life and oscillators. Moving patterns are processed separately:

Code: Select all

# Code extract from enter_unid(...)
            # Separate into pure components:
            if (moving):
                g.setrule("APG_CoalesceObjects_" + self.rg.alphanumeric)
                g.setbase(2)
                g.setstep(3)
                g.step()
            else:
                pseudo_bangbang(self.rg.alphanumeric)
... and only if the period of the pattern is <= 9.

Code: Select all

# Code extract from teenager(...)
                elif ((unidname[0] == 'x') & ((unidname[1] == 's') | (unidname[1] == 'p'))):
                    self.enter_unid(unidname, soupid, False)
                else:
                    if ((unidname[0] == 'x') & (unidname[1] == 'q') & (unidname[3] == '_')):
                        # Separates low-period (<= 9) non-standard spaceships in medium proximity:
                        self.enter_unid(unidname, soupid, True)
                    else:
                        self.incobject(unidname, 1)
                        self.awardpoints2(soupid, unidname)
I think extending canonise to deal with larger objects is a good idea. I'm sure it can be done in a backward compatible way by allowing multiple "yX" sequences to represent regions of empty cells larger than 39x5 - in the same way that sequential "z" sequences are allowed.

However, I don't think this is necessary to solve this issue. If enter_unid() is allowed to attempt to process oversize objects, then patterns such as this one will be correctly resolved - just not cached. Any truly inseperable oversize objects can just be skipped by enter_unid(). I suppose this might also require modification to process_unid() so that patterns aren't added to superunid as well as being handled by enter_unid().

Additionally, the limit on period to less than 10 in attempting to separate spaceships has always seemed arbitrary to me - a result of the APG_CoalesceObjects rule being run for 8 gen. Seeing as the period is known, can it be passed to enter_unid() and used to determine how long to run the rule for? If I'm not mistaken the rule need only be run for p-1 gen to guarantee that any inseperable pattern remains connected

In a few instances, this would result in closely spaced spaceships in other rules being separated where currently they aren't. e.g. the c/7 glider in B36/S245. For some phases of the following closely spaced pairs, the two gliders remain separated for 7 gen, but not for 8. Even more remain separate if the rule is only run for 6 gen.

Code: Select all

x = 69, y = 99, rule = APG_CoalesceObjects_B36S245
2.2A7.4A7.2A7.2A8.A2.A8.A9.A$.4A6.A.2A6.3A6.2A.2A7.A.A7.A.A7.2A$.2A8.
2A7.2A.A6.A12.A7.A9.3A$2.A8.2A7.3A8.A9.2A9.A$31.A2$2.A9.A29.2A7.2A7.A
2.A$.A.A7.2A8.2A7.4A7.3A6.2A.2A6.A.A$A9.3A7.4A6.A.2A6.2A.A6.A11.A$.A
18.2A8.2A8.3A8.A8.2A$21.A8.2A19.A20$.2A7.4A8.2A7.2A7.A2.A8.A9.A$4A6.A
.2A7.3A6.2A.2A6.A.A7.A.A7.2A$2A8.2A8.2A.A6.A11.A7.A9.3A$.A8.2A8.3A8.A
8.2A9.A$31.A2$2.A9.A29.2A7.2A7.A2.A$.A.A7.2A9.2A7.4A6.3A6.2A.2A6.A.A$
A9.3A8.4A6.A.2A5.2A.A6.A11.A$.A19.2A8.2A7.3A8.A8.2A$22.A8.2A18.A20$.
2A7.4A8.2A7.2A7.A2.A8.A9.A$4A6.A.2A7.3A6.2A.2A6.A.A7.A.A7.2A$2A8.2A8.
2A.A6.A11.A7.A9.3A$.A8.2A8.3A8.A8.2A9.A$31.A$5.A9.A29.2A6.2A7.A2.A$4.
A.A7.2A9.2A7.4A6.3A5.2A.2A6.A.A$3.A9.3A8.4A6.A.2A5.2A.A5.A11.A$4.A19.
2A8.2A7.3A7.A8.2A$25.A8.2A17.A21$.2A7.4A8.2A7.2A7.A2.A9.A9.A$4A6.A.2A
7.3A6.2A.2A6.A.A8.A.A7.2A$2A8.2A8.2A.A6.A11.A8.A9.3A$.A8.2A8.3A8.A8.
2A10.A$6.A9.A14.A14.2A8.2A7.A2.A$5.A.A7.2A9.2A7.4A6.3A7.2A.2A6.A.A$4.
A9.3A8.4A6.A.2A5.2A.A7.A11.A$5.A19.2A8.2A7.3A9.A8.2A$26.A8.2A19.A!
For those following along, none of this affects Life as gliders are removed by the custom IdentifyGliders and RemoveGliders rules. Non-interacting *WSSes are separated by custom code in countxwsses()
The latest version of the 5S Project contains over 226,000 spaceships. There is also a GitHub mirror of the collection. Tabulated pages up to period 160 (out of date) are available on the LifeWiki.

flipper77
Posts: 197
Joined: October 24th, 2010, 3:25 am
Location: Spokane, WA

Re: apgsearch v1.0

Post by flipper77 » February 26th, 2015, 11:44 am

As for the auto-update idea, prompting the user only at the scripts startup would be the best way to go about that.

I've been checking out the main census a lot, and I've noticed some objects have (at least to me) an excessive number of sample soups stored, check out pentadecathlon and loop, they both have around 500 of them, and there are some more objects out there with the same problem. Perhaps a better limit should be imposed based on total number of occurrences or an absolute limit, though I'm aware there's already a limit on really common objects, considering they have either no samples, or only a handful.

User avatar
gameoflifeboy
Posts: 474
Joined: January 15th, 2015, 2:08 am

Re: apgsearch v1.0

Post by gameoflifeboy » February 26th, 2015, 2:42 pm

Wow, one billion soups already!

Is there a way to see a list of all hauls for a particular rule and symmetry, not just the latest? Or at least a way to see all the hauls that produce a particular object?

User avatar
calcyman
Posts: 2198
Joined: June 1st, 2009, 4:32 pm

Re: apgsearch v1.0

Post by calcyman » February 26th, 2015, 9:05 pm

I've noticed some objects have (at least to me) an excessive number of sample soups stored
The limit is `only add sample soups for objects which have occurred fewer than 200 times so far in the census'. As a corollary, there's an absolute upper bound of 200 * 16 = 3200 sample soups that could possibly appear on an object page (because each rule can only have up to 16 censuses, one for each symmetry), so the Catagolue won't fill up with millions of random soups producing pentadecathla.

This approach has a few advantages (apart from being really simple from a coding perspective):
  • Common objects such as blocks and blinkers don't have sample soups, because they're uninteresting.
  • If an object is really common under a particular symmetry type (say, unices occur lots in diagonally-symmetric soups), a greater emphasis would be on sample soups from other symmetry types.
To iterate the second point, imposing a global census-independent limit of (say) 500 soups would be almost instantly filled up by boring diagonally-symmetric soups, and subsequently wouldn't collect any asymmetric soups.
Is there a way to see a list of all hauls for a particular rule and symmetry, not just the latest?
This is being implemented, along with a leaderboard showing which contributors are most prolific.
Wow, one billion soups already!
1.19 * 10^9 soups now, and 26 * 10^9 objects.
What do you do with ill crystallographers? Take them to the mono-clinic!

wildmyron
Posts: 1398
Joined: August 9th, 2013, 12:45 am

Re: apgsearch v1.0

Post by wildmyron » February 26th, 2015, 10:20 pm

calcyman wrote:
I've noticed some objects have (at least to me) an excessive number of sample soups stored
The limit is `only add sample soups for objects which have occurred fewer than 200 times so far in the census'. As a corollary, there's an absolute upper bound of 200 * 16 = 3200 sample soups that could possibly appear on an object page (because each rule can only have up to 16 censuses, one for each symmetry), so the Catagolue won't fill up with millions of random soups producing pentadecathla.

This approach has a few advantages (apart from being really simple from a coding perspective):
  • Common objects such as blocks and blinkers don't have sample soups, because they're uninteresting.
  • If an object is really common under a particular symmetry type (say, unices occur lots in diagonally-symmetric soups), a greater emphasis would be on sample soups from other symmetry types.
An unfortunate side effect of this is that blocks, blinkers, beehives and gliders in other rules where they might not be so common won't have any sample soups - except where they appear as pseudo objects. I don't know if there are explicit examples where this is true, so it may not be an issue.

Also, the linear growth pattern in B368/S245 has no sample soups.
http://catagolue.appspot.com/object/yl1 ... 5/b368s245
The latest version of the 5S Project contains over 226,000 spaceships. There is also a GitHub mirror of the collection. Tabulated pages up to period 160 (out of date) are available on the LifeWiki.

User avatar
Andrew
Moderator
Posts: 771
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia
Contact:

Re: apgsearch v1.0

Post by Andrew » February 27th, 2015, 7:44 am

Possibly a soup that results in unlimited novelty!? I've run it for over 12 million gens and the inner "X" shows no sign of stabilizing, although I guess it might if eaters are somehow created in the path of the incoming gliders.

EDIT: Not unlimited novelty. At some point before the 8 billionth gen the incoming gliders are deflected by a block then collide and destroy themselves.

Code: Select all

..***.**.*..********..*.**.***..
..*..**...*.*......*.*...**..*..
***.....**..*..**..*..**.....***
*....*****...*.**.*...*****....*
*...*..*.*..**....**..*.*..*...*
.*.*.*..**...*.**.*...**..*.*.*.
**.*......*..******..*......*.**
*..**...**.***....***.**...**..*
..**.*.****.***..***.****.*.**..
*.****.***...*.**.*...***.****.*
.*....*.*...*......*...*.*....*.
.......*.....*....*.....*.......
***.*..**.*.**.**.**.*.**..*.***
*..*******.**********.*******..*
*.....*.*....*....*....*.*.....*
*.**.**..*..**....**..*..**.**.*
*.**.**..*..**....**..*..**.**.*
*.....*.*....*....*....*.*.....*
*..*******.**********.*******..*
***.*..**.*.**.**.**.*.**..*.***
.......*.....*....*.....*.......
.*....*.*...*......*...*.*....*.
*.****.***...*.**.*...***.****.*
..**.*.****.***..***.****.*.**..
*..**...**.***....***.**...**..*
**.*......*..******..*......*.**
.*.*.*..**...*.**.*...**..*.*.*.
*...*..*.*..**....**..*.*..*...*
*....*****...*.**.*...*****....*
***.....**..*..**..*..**.....***
..*..**...*.*......*.*...**..*..
..***.**.*..********..*.**.***..
The soup is the 2nd sample linked from here:
http://catagolue.appspot.com/object/zz_LINEAR/b3s23.
The 1st soup results in a different pattern, so be careful to check all occurrences of a zz object.

User avatar
calcyman
Posts: 2198
Joined: June 1st, 2009, 4:32 pm

Re: apgsearch v1.0

Post by calcyman » February 27th, 2015, 8:59 am

Also, the linear growth pattern in B368/S245 has no sample soups.
Because it's way too common to be deemed interesting.
Possibly a soup that results in unlimited novelty!?
Haha, a very nice discovery!
At some point before the 8 billionth gen the incoming gliders are deflected by a block then collide and destroy themselves.
You mean that this reaction is created?

Code: Select all

x = 10, y = 9, rule = B3/S23
bo6bo$2bo4bo$3o4b3o5$4b2o$4b2o!
I suppose that would be more probable than the emergence of an eater.
What do you do with ill crystallographers? Take them to the mono-clinic!

User avatar
Andrew
Moderator
Posts: 771
Joined: June 2nd, 2009, 2:08 am
Location: Melbourne, Australia
Contact:

Re: apgsearch v1.0

Post by Andrew » February 27th, 2015, 3:57 pm

calcyman wrote:You mean that this reaction is created?
Yep, that's it.

User avatar
calcyman
Posts: 2198
Joined: June 1st, 2009, 4:32 pm

Re: apgsearch v1.0

Post by calcyman » February 27th, 2015, 6:51 pm

Just to announce that Catagolue is almost exactly a week old, and the b3s23/C1 census is plodding along at a rate of roughly 2^32 objects per day. At the current rate, Catagolue will overtake Okrasinski's census around the time of the Trinity May Ball (that is to say, in mid-June).

Here are a couple of interesting finds in non-standard rules:

http://catagolue.appspot.com/object/xp3 ... 6/b367s245 consists of a p168 shuttle which repeatedly converts a p2 into a p4 and back again.
http://catagolue.appspot.com/object/yl5 ... 5d6/b36s23 is a dirty c/6 puffer which appeared from a HighLife soup.

In other Catagolue news, we now have a pie chart to display which contributors have submitted the most objects (since the time of adding the leaderboard, after which I strategically submitted a couple of 12.5-million-soup hauls to give myself a head start!) for a particular census:

http://catagolue.appspot.com/census/b3s23/C1

Basically this is for consistency with TOLLCASS, which included a similar league table (admittedly across all rules, but for scalability I prefer treating separate censuses completely independently). I've heard rumours (or should that be 'rumors', since this is happening in the US?) that Dave Greene might be procuring large amounts of computing power reasonably soon, so it would be interesting to see how the b3s23/C1 pie chart changes over time. It appears that Andrew has defected to b3s23/D8_+4 (hence how he found the almost-unlimited novelty generator).

Also, /hashsoup now includes the appropriate rulestring so that you can copy and paste soups into Golly without having to manually set the rule.
What do you do with ill crystallographers? Take them to the mono-clinic!

Post Reply