apgsearch v2.2

For general discussion about Conway's Game of Life.
User avatar
The Turtle
Posts: 102
Joined: May 6th, 2015, 8:14 pm
Location: Chicago, Illinois

Re: apgsearch v2.2

Post by The Turtle » August 1st, 2015, 8:29 am

Yay! 5 trillion objects!
(1 trillion objects in just 6 days!)

Nick work, calcyman!
Only two things are constant: change and the speed of light.

User avatar
gmc_nxtman
Posts: 1150
Joined: May 26th, 2015, 7:20 pm

Re: apgsearch v2.2

Post by gmc_nxtman » August 1st, 2015, 6:33 pm

Wow! A trillion object increase in a mere fraction of the time Catagolue has existed! Impressive! I'd say we'll get to 1 * 10^13 in not a ridiculously unreasonable time, unless some crazy event causes the "soup farms" to stop running. Seriously amazing.

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

Re: apgsearch v2.2

Post by calcyman » August 1st, 2015, 6:47 pm

Thanks!

So we should manage about 30 * 10^12 objects by the end of the year, projecting the current rate of soup production. It also depends how many cores Tom Rokicki decides to throw at the project when the weather is cooler, and whether we manage to get people interested on Slashdot etc.
What do you do with ill crystallographers? Take them to the mono-clinic!

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

Re: apgsearch v2.2

Post by Scorbie » August 1st, 2015, 6:55 pm

I'm a little worried whether the Catagolue site would be able to cope with all the traffic... Is everything fine up there?

User avatar
gmc_nxtman
Posts: 1150
Joined: May 26th, 2015, 7:20 pm

Re: apgsearch v2.2

Post by gmc_nxtman » August 1st, 2015, 7:05 pm

I seem to be getting unreasonable low traction on the pie chart. I have 1m soups per haul, and am running 18 quad-parallelised instances of the search, for a few days now.

User avatar
biggiemac
Posts: 515
Joined: September 17th, 2014, 12:21 am
Location: California, USA

Re: apgsearch v2.2

Post by biggiemac » August 1st, 2015, 11:54 pm

I wouldn't be shocked if your instances haven't yet posted successfully. I don't see any hauls from you in the recent haul list, while I'd expect quad-parallelized 1m soup hauls to complete probably 2-3 times every 15 minute window (leading to an utter deluge of gmc_ntxman soups if 18 instances are running)

In the event your key was typed improperly, add whatever followed the -k flag to catagolue as an additional payosha key and once a new haul completes, all of the accumulated results will post.

If your internet connection has been spotty, once it's back all the results will post (that led to me posting four 362-million soup hauls once, despite specifying ~1m soups per haul)

I have seen a few verifications by you, so I don't know what is actually happening with your soups. Do you have access to their terminal output?
Physics: sophistication from simplicity.

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

Re: apgsearch v2.2

Post by calcyman » August 2nd, 2015, 6:44 am

Are you sure your instances are actually running?

In particular, they terminate when you close the terminal, unless you either use nohup or disown. Example syntax for disown is below:

Code: Select all

./apgnano -k yourkey -p 4 &
disown -a
Note the ampersand at the end of the first command to make it a background process (so it no longer swallows stdin). Then 'disown -a' will ensure that your currently-running background processes are removed from the job queue, so they won't receive a hangup signal when you close the terminal.

(If you're running 18 quad-parallelised instances, please set -n to be at least 10^7 on most of the instances for the reason biggiemac described.)
Scorbie wrote:I'm a little worried whether the Catagolue site would be able to cope with all the traffic... Is everything fine up there?
Yes, it's able to dequeue up to 400 hauls per hour, and enqueue unboundedly many. So it can handle over 10 times the current traffic without the queue of uncommitted hauls growing.
What do you do with ill crystallographers? Take them to the mono-clinic!

User avatar
simsim314
Posts: 1823
Joined: February 10th, 2014, 1:27 pm

Re: apgsearch v2.2

Post by simsim314 » August 2nd, 2015, 8:08 am

I've just noticed yl144 and yl384 statistics is not present inside haul statistics in v2.2 see here for example.

User avatar
Billabob
Posts: 158
Joined: April 2nd, 2015, 5:28 pm

Re: apgsearch v2.2

Post by Billabob » August 2nd, 2015, 8:56 am

simsim314 wrote:I've just noticed yl144 and yl384 statistics is not present inside haul statistics in v2.2 see here for example.
In that haul, the 11-snake appeared more than the 9-snake!

EDIT: Just to say -- the 11-snake appeared 21 times, with the 9-snake appearing only 4 times. Is this normal?
▄▀
▀▀▀

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

Re: apgsearch v2.2

Post by calcyman » August 2nd, 2015, 10:22 am

simsim314 wrote:I've just noticed yl144 and yl384 statistics is not present inside haul statistics in v2.2 see here for example.
Oops. Upgrade to v2.3 immediately.

I'll fudge the switch-engine statistics to their actual values as soon as everyone has switched to the current version.
What do you do with ill crystallographers? Take them to the mono-clinic!

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

Re: apgsearch v2.2

Post by dvgrn » August 2nd, 2015, 11:13 am

Billabob wrote:In that haul, the 11-snake appeared more than the 9-snake!

EDIT: Just to say -- the 11-snake appeared 21 times, with the 9-snake appearing only 4 times. Is this normal?
Yup. But only because the "11-snake" (xs11_3586246) is seriously misnamed -- probably by tradition, I haven't tried to dig up whether it's in Flammenkamp's or Okrasinski's named objects -- and appears to have several common pathways to synthesis. BG or R plus a couple of sparks will settle down nicely into xs11_3586246.

The very^4 long snake (xs11_xg853zca1) would indeed be very unlikely to outnumber 9-snakes / very very long snakes which are over 500 times more common on average.

User avatar
gmc_nxtman
Posts: 1150
Joined: May 26th, 2015, 7:20 pm

Re: apgsearch v2.2

Post by gmc_nxtman » August 2nd, 2015, 11:30 am

Would it be possible to modify apgnano so as to generate a random glider collision instead of a random soup?

User avatar
biggiemac
Posts: 515
Joined: September 17th, 2014, 12:21 am
Location: California, USA

Re: apgsearch v2.2

Post by biggiemac » August 2nd, 2015, 1:26 pm

calcyman wrote:
simsim314 wrote:I've just noticed yl144 and yl384 statistics is not present inside haul statistics in v2.2 see here for example.
Oops. Upgrade to v2.3 immediately.

I'll fudge the switch-engine statistics to their actual values as soon as everyone has switched to the current version.
Upgraded. Nice find, simsim. I'm curious, in the timespan back when only v1.x instances were allowed to verify v2.x, was the verification process not strong enough to observe the dearth of SE? Or is 0 SE in 10M soups still within fully "reasonable" guidelines?
calcyman wrote:
dvgrn wrote:One more question while I'm off on this irrelevant tangent: have apgsearch 1.x and 2.x been shown to produce identical results on a few randomly-chosen multi-million-soup runs?
They don't, because they run infinite-growth patterns for different durations. But they're both equally correct.
Thought this was a bit of odd foreshadowing. I am curious what the difference would be though. To what extent does the puffer output get counted as objects? I know the Long inverted double claw in D4_x4 was counted many times due to being the output of a SE pair. Would the number of xs14_i5q453z11 counts per occurrence of that SE pair increase or decrease if processed by v2.x?
Physics: sophistication from simplicity.

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

Re: apgsearch v2.2

Post by dvgrn » August 2nd, 2015, 4:10 pm

gmc_nxtman wrote:Would it be possible to modify apgnano so as to generate a random glider collision instead of a random soup?
Have you seen simsim314's experiment along these lines? As a Python script it seemed to work quite well.

It may take some work to get Adam to consider accepting such things as initial soups for Catagolue, though. At the very least, the glider positions would have to be generated somehow from an SHA-256 hash, to remove the temptation to cheat and send in disguised loafer syntheses and suchlike. And then how do you ensure that the gliders will all hit each other? Delete any that will miss, maybe?

User avatar
gmc_nxtman
Posts: 1150
Joined: May 26th, 2015, 7:20 pm

Re: apgsearch v2.2

Post by gmc_nxtman » August 2nd, 2015, 4:17 pm

dvgrn wrote: And then how do you ensure that the gliders will all hit each other? Delete any that will miss, maybe?
I think it shouldn't be too hard to write a custom rule, in which one could draw gliders with state 1 cells, they would send out a "ping" cell, and only if it hit the target would it send a signal back. If the signal came back it would "validate" the glider as part of the collision. Otherwise it would try another glider. If anything is unclear, feel free to ask...

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

Re: apgsearch v2.2

Post by calcyman » August 2nd, 2015, 5:00 pm

I'm curious, in the timespan back when only v1.x instances were allowed to verify v2.x, was the verification process not strong enough to observe the dearth of SE?
Well, the hauls had unusually large chi-square values (causing many to be rejected), but I presumed that was just from running switch-engines for varying amounts of time (so generating different quantities of blocks) and just increased the chi-square threshold to compensate (thereby decreasing the security). I realise that disabling automatic security precautions was precisely what caused the Chernobyl incident, and all I can do is apologise:

https://www.youtube.com/watch?v=8iN6-Oev6Po
What do you do with ill crystallographers? Take them to the mono-clinic!

User avatar
gmc_nxtman
Posts: 1150
Joined: May 26th, 2015, 7:20 pm

Re: apgsearch v2.2

Post by gmc_nxtman » August 2nd, 2015, 5:16 pm

Given that the newer version of the search is much faster, when would you think we'll begin to start seeing nonstandard spaceships/flotillas of them? My guesses are

•Puffer 2*
•x66
•Schick engine
•Coe ship
•Loafer*
•Pushalong 1
•Big A
•Some other weird puffer*
•Triple flotilla
•OWSS flotilla
•Sidecar

Notes:

*Loafers may have already occured in soups, but are not censused due to the fact that loafers are slow(c/7!). Perhaps many loafers will have to occur before one manages to escape its soup free of destruction. Due to its slow speed something could sneak up behind it(!)
*I am a bit surprised that puffer 2 hasn't occured naturally. It just has to have two LWSS, and a b-heptomino at the right place and the right time. Then again, "stuff at the right place at the right time" could be trivially said about all the other possible natural candidates.
*In a lot of other life-like close variants of life (like b38/s23 for example) have highly natural puffers, like the two-herschel puffer in one of the EightLife variants and B37/S23 with the twin r's puffer. I can't see why this is so uncommon in regular GOL.
Last edited by gmc_nxtman on August 2nd, 2015, 6:26 pm, edited 1 time in total.

User avatar
simsim314
Posts: 1823
Joined: February 10th, 2014, 1:27 pm

Re: apgsearch v2.2

Post by simsim314 » August 2nd, 2015, 5:34 pm

dvgrn wrote: At the very least, the glider positions would have to be generated somehow from an SHA-256 hash...and then how do you ensure that the gliders will all hit each other?
Well I addressed both of the problems in my script. First of all SHA-256 is nothing else but random number generator. Calcymen takes the 32 bit number and put it in the soup state in 32x32 tile. I would suggest to take 5 bits and use +/- 16 for glider y, another 2 bits for glider internal state, and another bit to add extra distance between the glider and previous one.

To ensure gliders will collide you just need to take enough of them - 4-6 glider in each direction is usually enough, and to ensure the glider salvo is not colliding with itself you need to make sure each glider has its own X location, while making sure there are at least two cells by X axis differentiating the two gliders.

Yes it does not cover all the glider salvo options, but ensures consistent random glider salvo, with enough options.

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

Re: apgsearch v2.2

Post by dvgrn » August 2nd, 2015, 6:15 pm

gmc_nxtman wrote:Given that the newer version of the search is much faster, when would you think we'll begin to start seeing nonstandard spaceships/flotillas of them? My guesses are

•Puffer 2*
•x66
•Schick engine
•Coe ship
•Loafer*
•Pushalong 1
•Big A
•Some other weird puffer
My official prediction is that before any of these appear, we'll see the first appearance of a natural *WSS-on-*WSS-on-*WSS. Those really aren't too terribly unlikely.

Probably I should just say "around the same time" -- a Puffer 2, and maybe some of the others, should really be about as common as a triple *WSS. But an official prediction will make it much more satisfying if I actually happen to be right.

A thought occurred to me about the production of slow things like loafers. It seems as if soups would be more likely to generate slow spaceships if there was relatively more edge and less middle. If these are particularly interesting objects, might it be worth setting up initial soups that are something like 7x36 or 6x42 or 5x50, or even 4x64?

The very tenuous statistical thread that I have to hang this supposition on, is that Catagolue reports that 8x32 soups make glider-producing switch engines (a large slow object) at the rate of 3.55 per million soups, where 16x16 soups emit only 2.19 of them per million. The block-laying variety has a similarly improved ratio -- 10 per million at 8x32, 6 per million at 16x16.

Obviously an experiment like Achim Flammenkamp's, running a toroidal universe that starts out packed with junk, returned far fewer interesting edge-of-the-void objects than either 8x32 or 16x16 soups. If interesting new objects is a goal, why not move as far as possible in the direction of encouraging them to show up?

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

Re: apgsearch v2.2

Post by dvgrn » August 2nd, 2015, 6:33 pm

simsim314 wrote:First of all SHA-256 is nothing else but random number generator. Calcymen takes the 32 bit number and put it in the soup state in 32x32 tile. I would suggest to take 5 bits and use +/- 16 for glider y, another 2 bits for glider internal state, and another bit to add extra distance between the glider and previous one.
Well, it's a 16x16 tile, except for some of the symmetrical options in the old apgsearch. And as the name implies, the output is 256 bits, so it's trivial to arrange them into 16x16 or 8x32 blocks.

But that's more or less just a superstition -- it's not as if we couldn't generate more than 256 bits of equally pseudo-random information, starting with the same seed. If you run out of bits, you could hash the SHA-256 hash again, for example, and repeat as long as you needed more randomness.

That would allow a version of apgnano to start with, say, a 7x343 rectangle with a 30% chance that each cell is ON. The 50% ON implied by just using the raw SHA-256 output is kind of overkill -- the density always drops steeply due to overcrowding in the first few ticks.

I kind of suspect that a significant fraction of raw SHA-256 soups are uninteresting due to catastrophic die-off before T=5. And I also suspect that this fraction of time wasted on censusing unproductive soups could be reduced by picking the right initial density. Will have to do some experiments to prove my case, I guess -- or at least look up the old experiments from a couple of decades ago.
gmc_nxtman wrote:I think it shouldn't be too hard to write a custom rule, in which one could draw gliders with state 1 cells, they would send out a "ping" cell, and only if it hit the target would it send a signal back. If the signal came back it would "validate" the glider as part of the collision. Otherwise it would try another glider.
I've always liked the idea of starting with gliders -- as few as possible while still guaranteeing, say, less than one in a billion chance of having different seeds generate the exact same starting configuration, inside a year's worth of runtime or so. If you start with gliders, you instantly guarantee that whatever you find will have a glider synthesis.

Another perfectly workable method of ensuring "clean" initial glider collisions with no leftovers, would be to remember each glider's trajectory, check whether there's still a glider at the appropriate position in the final ash, and subtract it from the census if so. Probably not the fastest possible method, but it's definitely easy. Or just run a few thousand ticks, test, and re-run after removing the probably-irrelevant gliders.

(They'd only be probably irrelevant because Heisenburp reactions and lucky reconstructions would show up occasionally, no doubt -- but not enough to measurably affect census statistics, I wouldn't think.)

Is there a particular argument for having apgnano support glider-collisioin soups, though? -- besides the obvious reason of wanting to search more and faster. Just running simsim314's code seems like it would be a good place to start.

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

Re: apgsearch v2.2

Post by calcyman » August 2nd, 2015, 6:38 pm

dvgrn wrote: The very tenuous statistical thread that I have to hang this supposition on, is that Catagolue reports that 8x32 soups make glider-producing switch engines (a large slow object) at the rate of 3.55 per million soups, where 16x16 soups emit only 2.19 of them per million. The block-laying variety has a similarly improved ratio -- 10 per million at 8x32, 6 per million at 16x16.
!!!

That's because v2.x didn't report switch-engines until the v2.3 patch, so the switch-engine statistics for 16-by-16 are massively inaccurate. In reality, there's a negligible difference in frequency (per object) of switch-engines between 16-by-16 and 8-by-32.

As I mentioned, I'll fix the b3s23/C1 switch-engine statistics as soon as people migrate to v2.3.
What do you do with ill crystallographers? Take them to the mono-clinic!

User avatar
simsim314
Posts: 1823
Joined: February 10th, 2014, 1:27 pm

Re: apgsearch v2.2

Post by simsim314 » August 2nd, 2015, 7:19 pm

dvgrn wrote:Is there a particular argument for having apgnano support glider-collisioin soups, though?
The argument is obvious: you start from natural pattern, and at the least each object you find you get some synthesis for it - maybe not the best, but you start from ugly and messy synth instead of a random soup, so you can trace each "smoke" to its natural origins (in soup you might trace the smoke to the original unnatural soup, happens a lot for symmetrical soups).
dvgrn wrote:Just running simsim314's code seems like it would be a good place to start.
My code is in python, and it works only for SLs and some oscillators, so there is a very good incentive to work with c++ apgnano that works with any type of objects and faster.

Another incentive is that having it all in one place is better - calcyman has built very nice online database, collecting stats from many people. I think adding glider soups to apgnano is much simpler task, than making another online infrastructure.

User avatar
praosylen
Posts: 2443
Joined: September 13th, 2014, 5:36 pm
Location: Pembina University, Home of the Gliders
Contact:

Re: apgsearch v2.2

Post by praosylen » August 2nd, 2015, 8:54 pm

An idea: If the random glider collision idea is implemented, have it report the hauls as a different "symmetry" (as was done with 8x32). That way, the results could coexist with the random soup search but not interfere with some of the finer statistical points.
former username: A for Awesome
praosylen#5847 (Discord)

The only decision I made was made
of flowers, to jump universes to one of springtime in
a land of former winter, where no invisible walls stood,
or could stand for more than a few hours at most...

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

Re: apgsearch v2.2

Post by dvgrn » August 3rd, 2015, 12:36 am

calcyman wrote:!!!

That's because v2.x didn't report switch-engines until the v2.3 patch, so the switch-engine statistics for 16-by-16 are massively inaccurate. In reality, there's a negligible difference in frequency (per object) of switch-engines between 16-by-16 and 8-by-32.
Darn. That's too bad. It would have been nice if increasing the surface area made that big of a difference.

I should have thought of that explanation, of course. Wishful thinking is a very powerful theoretical force, as recent events have demonstrated...!

Several of the recent checkin summaries have been highly entertaining, actually. Seems like apgsearch/Catagolue have gotten to a level of complexity where it's really hard to keep all the silly-with-hindsight bugs out. Just need to have everybody on the lookout for signs of trouble whenever a new version comes out.

My favorite summary is "I'm a massive idiot -- perhaps I should give up coding and try a different career?" But no, just for the record, I think everyone will agree that you're doing just fine. Among other things, you seem to have a sanity-preserving tendency to implement only the feature requests you feel like implementing... which helps feature creep stay at a manageable level. It's a bit painful for people like me with exciting vague ideas for improvement, who are not doing any of the actual coding, but that's just the way it goes.

User avatar
Billabob
Posts: 158
Joined: April 2nd, 2015, 5:28 pm

Re: apgsearch v2.2

Post by Billabob » August 3rd, 2015, 5:25 am

gmc_nxtman wrote:Given that the newer version of the search is much faster, when would you think we'll begin to start seeing nonstandard spaceships/flotillas of them? My guesses are

•Puffer 2*
•x66
•Schick engine
•Coe ship
•Loafer*
•Pushalong 1
•Big A
•Some other weird puffer*
•Triple flotilla
•OWSS flotilla
•Sidecar
Is it too generous to estimate that one of these will occur before the four rarest 2-*WSS flotillae each reach 2 occurences? (Specifically a "Triple Flotilla"; the standard MWSS-on-MWSS (number) is reasonably common, maybe even common enough to appear with another *WSS next to it.)

EDIT: Attempted to make a link, but failed terribly. Luckily there's a thread that can help. Where did I go wrong?
▄▀
▀▀▀

Post Reply