Page 2 of 15

Re: apgsearch v3.1

Posted: March 26th, 2016, 3:55 pm
by gameoflifeboy
calcyman wrote:I've added D4_+4, D4_+2 and D4_+1. There's no theoretical obstacle to adding the remaining symmetries; it's just rather a lot of work as each one must be done individually.
The first thing I'm going to search is b36s125/D4_+4, to see if this P1022 oscillator will turn up recognized this time.

Is there a way to update apgmera from the terminal without downloading the latest version yourself?

Re: apgsearch v3.1

Posted: March 26th, 2016, 5:17 pm
by calcyman
gameoflifeboy wrote:Is there a way to update apgmera from the terminal without downloading the latest version yourself?
Well if you downloaded it using:

Code: Select all

git clone https://gitlab.com/apgoucher/apgmera.git
then the correct command is:

Code: Select all

git pull
or alternatively:

Code: Select all

./recompile.sh --update
(The latter performs a git pull if the version number in the remote repository differs from the version number in your local copy, then does the usual stuff.)

Re: apgsearch v3.1

Posted: March 26th, 2016, 5:32 pm
by Apple Bottom
calcyman wrote:I've added D4_+4, D4_+2 and D4_+1. There's no theoretical obstacle to adding the remaining symmetries; it's just rather a lot of work as each one must be done individually.
Awesome work! I've just started an instance each for those symmetries. (Ah, if only I had a few more cores available, though -- between the five extra symmetries now supported by apgmera on one hoof and Day & Night on the other I don't have much I can throw at b3s23/C1 anymore!)
As for isotropic non-totalistic rules, that's currently impossible (since QuickLife can't run them, and QuickLife is used for classifying objects).
Right, I see. Some day, then!

Re: apgsearch v3.1

Posted: March 26th, 2016, 6:34 pm
by calcyman
C2_4, C2_2 and C2_1 have also been implemented, so we have 9 of the 16 original symmetries.

Re: apgsearch v3.1

Posted: March 26th, 2016, 10:13 pm
by thunk
Apple Bottom wrote:Awesome work! I've just started an instance each for those symmetries. (Ah, if only I had a few more cores available, though -- between the five extra symmetries now supported by apgmera on one hoof and Day & Night on the other I don't have much I can throw at b3s23/C1 anymore!)
I'm currently having much the same problem, except I've entirely ditched any thought of Day and Night or C1 searches...

well, that, and not being a cartoon ungulate.

Re: apgsearch v3.1

Posted: March 27th, 2016, 12:44 pm
by calcyman
calcyman wrote:C2_4, C2_2 and C2_1 have also been implemented, so we have 9 of the 16 original symmetries.
Make that 11 of 16; version 3.2 includes the remaining cyclic symmetries C4_1 and C4_4. These are accomplished using the wonderful Hacker's Delight bitwise transpose code mentioned in the StackOverflow answer http://stackoverflow.com/a/6932331/5130486.

Re: apgsearch v3.1

Posted: March 27th, 2016, 2:15 pm
by fluffykitty
What are the remaining symmetries?

Re: apgsearch v3.1

Posted: March 27th, 2016, 2:53 pm
by Apple Bottom
fluffykitty wrote:What are the remaining symmetries?
D2_x, D4_x1, D4_x4, D8_1 and D8_4.

(Oh, and 8x32, which I reckon is not strictly a symmetry, and 25% aka 25pct and 75% aka 75pct, which are rather obscure to begin with.)

Re: apgsearch v3.1

Posted: March 27th, 2016, 8:05 pm
by calcyman
Apple Bottom wrote:
fluffykitty wrote:What are the remaining symmetries?
D2_x, D4_x1, D4_x4, D8_1 and D8_4.
I've now implemented D2_x, D8_1 and D8_4 (in version 3.21), so that just leaves D4_x1 and D4_x4 (which I'm not particularly looking forward to doing...).

Re: apgsearch v3.1

Posted: March 27th, 2016, 9:15 pm
by thunk
I've now implemented D2_x, D8_1 and D8_4 (in version 3.21), so that just leaves D4_x1 and D4_x4 (which I'm not particularly looking forward to doing...).
Good luck!
One note is that the "rare oscillator" messages are a bit overwhelming, especially in some symmetries. Doubly especially in D8_4, where octagon II is very common.

Re: apgsearch v3.1

Posted: March 27th, 2016, 9:53 pm
by fluffykitty
Solution: Only alert on 1/10/100/10^k occurrences. It would also give a rough estimate of how many there are.

Re: apgsearch v3.1

Posted: March 28th, 2016, 8:55 am
by Apple Bottom
thunk wrote:One note is that the "rare oscillator" messages are a bit overwhelming, especially in some symmetries. Doubly especially in D8_4, where octagon II is very common.
Here's (yet) another patch, against vanilla 3.21 this time, adding a -q <#> flag to control how quiet apgmera is.

Code: Select all

diff -ru apgmera-ae92/main.cpp quiet-ae92/main.cpp
--- apgmera-ae92/main.cpp       2016-03-28 02:02:11.000000000 +0200
+++ quiet-ae92/main.cpp 2016-03-28 14:49:07.988221100 +0200
@@ -25,6 +25,8 @@

 #define APG_VERSION "v3.21"

+int quietLevel = 0;
+
 /*
  * Produce a new seed based on the original seed, current time and PID:
  */
@@ -1516,30 +1518,32 @@
             }

             // Mention object in terminal:
+            if(!quietLevel) {
             #ifdef STANDARD_LIFE
-            if ((apgcode[0] == 'x') && (apgcode[1] == 'p')) {
-                if ((apgcode[2] != '2') || (apgcode[3] != '_')) {
-                    if (apgcode.compare("xp3_co9nas0san9oczgoldlo0oldlogz1047210127401") != 0 && apgcode.compare("xp15_4r4z4r4") != 0) {
-                        // Interesting oscillator:
-                        std::cout << "Rare oscillator detected: \033[1;31m" << apgcode << "\033[0m" << std::endl;
+                if ((apgcode[0] == 'x') && (apgcode[1] == 'p')) {
+                    if ((apgcode[2] != '2') || (apgcode[3] != '_')) {
+                        if (apgcode.compare("xp3_co9nas0san9oczgoldlo0oldlogz1047210127401") != 0 && apgcode.compare("xp15_4r4z4r4") != 0) {
+                            // Interesting oscillator:
+                            std::cout << "Rare oscillator detected: \033[1;31m" << apgcode << "\033[0m" << std::endl;
+                        }
                     }
+                } else if ((apgcode[0] == 'x') && (apgcode[1] == 'q')) {
+                    if (apgcode.compare("xq4_153") != 0 && apgcode.compare("xq4_6frc") != 0 && apgcode.compare("xq4_27dee6") != 0 && apgcode.compare("xq4_27deee6") != 0) {
+                        std::cout << "Rare spaceship detected: \033[1;34m" << apgcode << "\033[0m" << std::endl;
+                    }
+                } else if ((apgcode[0] == 'y') && (apgcode[1] == 'l')) {
+                    std::cout << "Linear-growth pattern detected: \033[1;32m" << apgcode << "\033[0m" << std::endl;
+                } else if ((apgcode[0] == 'z') && (apgcode[1] == 'z')) {
+                    std::cout << "Chaotic-growth pattern detected: \033[1;32m" << apgcode << "\033[0m" << std::endl;
                 }
-            } else if ((apgcode[0] == 'x') && (apgcode[1] == 'q')) {
-                if (apgcode.compare("xq4_153") != 0 && apgcode.compare("xq4_6frc") != 0 && apgcode.compare("xq4_27dee6") != 0 && apgcode.compare("xq4_27deee6") != 0) {
-                    std::cout << "Rare spaceship detected: \033[1;34m" << apgcode << "\033[0m" << std::endl;
-                }
-            } else if ((apgcode[0] == 'y') && (apgcode[1] == 'l')) {
-                std::cout << "Linear-growth pattern detected: \033[1;32m" << apgcode << "\033[0m" << std::endl;
-            } else if ((apgcode[0] == 'z') && (apgcode[1] == 'z')) {
-                std::cout << "Chaotic-growth pattern detected: \033[1;32m" << apgcode << "\033[0m" << std::endl;
-            }
             #else
-            if ((apgcode[0] == 'y') && (apgcode[1] == 'l')) {
-                std::cout << "Linear-growth pattern detected: \033[1;32m" << apgcode << "\033[0m" << std::endl;
-            } else if ((apgcode[0] == 'z') && (apgcode[1] == 'z')) {
-                std::cout << "Chaotic-growth pattern detected: \033[1;32m" << apgcode << "\033[0m" << std::endl;
-            }
+                if ((apgcode[0] == 'y') && (apgcode[1] == 'l')) {
+                    std::cout << "Linear-growth pattern detected: \033[1;32m" << apgcode << "\033[0m" << std::endl;
+                } else if ((apgcode[0] == 'z') && (apgcode[1] == 'z')) {
+                    std::cout << "Chaotic-growth pattern detected: \033[1;32m" << apgcode << "\033[0m" << std::endl;
+                }
             #endif
+            }
         }

         return false;
@@ -1864,7 +1868,8 @@
         if (i % 10000 == 0) {
             clock_t end = clock();

-            std::cout << i << " soups completed (" << (int) (10000.0 / ((double) (end-start) / CLOCKS_PER_SEC)) << " soups per second)." << std::endl;
+            if(!(quietLevel > 1))
+                std::cout << i << " soups completed (" << (int) (10000.0 / ((double) (end-start) / CLOCKS_PER_SEC)) << " soups per second)." << std::endl;

             start = clock();
         }
@@ -1946,6 +1951,8 @@
             verifications = atoi(argv[i+1]);
         } else if (strcmp(argv[i], "-L") == 0) {
             local_log = atoi(argv[i+1]);
+        } else if (strcmp(argv[i], "-q") == 0) {
+            quietLevel = atoi(argv[i+1]);
         } else if (strcmp(argv[i], "-t") == 0) {
             testing = true;
         } else if (strcmp(argv[i], "-p") == 0) {
Right now there's three levels:
  • 0: as before (default)
  • 1: status messages printed, messages for rare objects are suppressed
  • 2: both status messages and messages for rare objects are suppressed
Use it e.g. like so:

Code: Select all

$ ./apgmera <your_usual_options> -q 1

Re: apgsearch v3.1

Posted: March 28th, 2016, 6:38 pm
by thunk
This soup from v3.21 gets inexplicably classified as zz_REPLICATOR:

Code: Select all

x = 31, y = 31, rule = B3/S23
bbobbbbbbboobobbboboobbbbbbbobb$
bboboboooobbbbooobbbboooobobobb$
oobbbooobobbbbbbbbbbbobooobbboo$
bbboboooobbobbobobbobboooobobbb$
bobbobbbobbobooboobobbobbbobbob$
bbooboboobbooooooooobbooboboobb$
booobbbbooobbobbbobbooobbbbooob$
booobobobbbobbbobbbobbbobobooob$
boboooobbobobbbbbbbobobboooobob$
boobbbobooobbbbobbbbooobobbboob$
obbbbbobbobobbobobbobobbobbbbbo$
obbooobooboobooboobooboobooobbo$
bbbbbobbbbbbooooooobbbbbbobbbbb$
obbbooobbbboobbobboobbbbooobbbo$
bobooobbbbooobooobooobbbbooobob$
bobbbobobobbooobooobbobobobbbob$
bobooobbbbooobooobooobbbbooobob$
obbbooobbbboobbobboobbbbooobbbo$
bbbbbobbbbbbooooooobbbbbbobbbbb$
obbooobooboobooboobooboobooobbo$
obbbbbobbobobbobobbobobbobbbbbo$
boobbbobooobbbbobbbbooobobbboob$
boboooobbobobbbbbbbobobboooobob$
booobobobbbobbbobbbobbbobobooob$
booobbbbooobbobbbobbooobbbbooob$
bbooboboobbooooooooobbooboboobb$
bobbobbbobbobooboobobbobbbobbob$
bbboboooobbobbobobbobboooobobbb$
oobbbooobobbbbbbbbbbbobooobbboo$
bboboboooobbbbooobbbboooobobobb$
bbobbbbbbboobobbboboobbbbbbbobb!
It's just four arks.

EDIT: This one too, in D4_x4 (v 3.22 has implemented the remaining two symmetries):

Code: Select all

x = 32, y = 32, rule = B3/S23
bbooboooobobbobbbbbobbbbboobbbbb$
boobobbbobbbbbbbbbbobooboobobbob$
oobboooooobbboobbboooobobbboobbb$
obboobobobbbooooobbboobbobbboobb$
booooobobbobbbooooobooboooooboob$
obobooboobobbbooobobbboobboobbbo$
oboobbooboooobbobboobboooobobboo$
oboboooboobbobobooooboooboboobob$
oooobobooooobobbbobbbboooooobobb$
bbobbbooobbooooooobobbboooobbbob$
obbbooobobbooboboooobbbbobboooob$
bbbbbboboooboobooboobbbbbbbooobb$
bbbobbooboooobbooobooooboobbbooo$
oboobbbboobobooboboboobboooobobb$
bbooooboboobboobboboboooobbobbbb$
bbboooobboboobboobooooobobooobbb$
bbboooboboooooboobboobobboooobbb$
bbbbobboooobobobboobbooboboooobb$
bboboooobboobobobooboboobbbboobo$
ooobbbooboooobooobbooooboobbobbb$
bbooobbbbbbboobooboobooobobbbbbb$
boooobbobbbbooooboboobbobooobbbo$
bobbboooobbbobooooooobbooobbbobb$
bboboooooobbbbobbboboooooboboooo$
bobooboboooboooobobobboobooobobo$
oobboboooobboobbobbooooboobboobo$
obbboobboobbbobooobbbobooboobobo$
booboooooboobooooobbbobbobooooob$
bboobbbobboobbbooooobbboboboobbo$
bbboobbboboooobbboobbboooooobboo$
bobbobooboobobbbbbbbbbbobbboboob$
bbbbboobbbbbobbbbbobbobooooboobb!

Re: apgsearch v3.1

Posted: March 29th, 2016, 12:05 pm
by calcyman
thunk wrote:This soup from v3.21 gets inexplicably classified as zz_REPLICATOR:
Thanks for the bug report. I've rectified it in v3.23 by accounting for the fact that powerlyse() receives a copy of the object at generation 5380, rather than at generation 0. Also, powerlyse() is faster since I've reduced the number of generations.

Re: apgsearch v3.1

Posted: March 29th, 2016, 2:54 pm
by Apple Bottom
calcyman wrote:
thunk wrote:This soup from v3.21 gets inexplicably classified as zz_REPLICATOR:
Thanks for the bug report. I've rectified it in v3.23 by accounting for the fact that powerlyse() receives a copy of the object at generation 5380, rather than at generation 0. Also, powerlyse() is faster since I've reduced the number of generations.
Something's wrong. I've just updated to 3.23, and my b3s23/C1 searchers started hitting zz_REPLICATOR patterns almost immediately.

The following hauls are affected (the third does not have any zz_REPLICATOR patterns, but was submitted using 3.23 and is thus still a priori suspect):
I've gone back to 3.22 for now.

EDIT: looks like all the problematic hauls were rejected during peer review, except for the one that didn't have those supposed zz_REPLICATORs, so the census data itself remains untainted. Whew!

Re: apgsearch v3.1

Posted: March 30th, 2016, 2:10 am
by calcyman
Resolved in v3.24. Moreover, Catagolue now rejects all v3.23 hauls.

Re: apgsearch v3.1

Posted: March 30th, 2016, 3:04 pm
by drc
More spam on ZZ_LINEAR. It seems to be the primary target

Re: apgsearch v3.1

Posted: March 30th, 2016, 3:35 pm
by thunk
drc wrote:More spam on ZZ_LINEAR. It seems to be the primary target
There seems to be three kinds of zz_LINEAR objects.

The first, mainly occurring in D8, happens when four switch engine pairs fire gliders back into the origin, eventually making a mess that persists for millions of generations until a reaction involving a block or a boat-bit, forms to suppress the incoming gliders.

The second occurs when there is an unusually-high period switch engine pair, such as a yl4608 that occurred once in c1. linearlyse() can't seem to handle periods higher than 4000, so it puts such a pattern into the zz_LINEAR bin without manual intervention.

The third seems to be this switch engine pair with period 1536, which apgmera hates for some reason:

Code: Select all

x = 16, y = 16, rule = B3/S23
2bobobobob2o3bo$3bob2ob2o2b3o$obob4o2bo4bo$bo2bo2bo2b2ob3o$ob2o2b2obob
2o2bo$b2o2b2ob2o2b2obo$3ob2obo2bo2bobo$2b3ob2obo$2o3bo2b2o3bo$bo2b2ob
2o5bo$ob2o2bo3bo2bobo$o2b2o6b3obo$bo2b2o5bobobo$bobob2obob3o$bobo5bo4b
o$ob5o3b3o2bo!
That's the only one that can really be considered spam.

Re: apgsearch v3.1

Posted: March 30th, 2016, 4:17 pm
by drc
@thunk

I meant the comments

Re: apgsearch v3.1

Posted: March 31st, 2016, 7:16 am
by Apple Bottom
calcyman wrote:Resolved in v3.24. Moreover, Catagolue now rejects all v3.23 hauls.
Tangentially related -- there's still a fair number of replicators being reported (zz_REPLICATOR/b3s23 counts 43 sample soups right now, all from the last two or three days). I reckon these are due to people still running older apgmera versions (≤3.22), but it's hard to say for sure as haul pages (say, this, just to use the latest) don't say what version was used to submit the haul in question.

So I was thinking, could that be changed? "This haul was submitted by ${USER} on ${DATE} at ${TIME} using ${VERSION}", or something along those lines.

Re: apgsearch v3.1

Posted: April 1st, 2016, 5:20 am
by isaacg
Is there a way to send a partially completed group of soups to catagolue, or to pause and pick up where you left off?

Re: apgsearch v3.1

Posted: April 5th, 2016, 1:47 am
by Scorbie
The census in this page seems a bit strange...
https://catagolue.appspot.com/census/b3s23/D2_+2/xq4

Re: apgsearch v3.1

Posted: April 5th, 2016, 1:51 am
by thunk
Scorbie wrote:The census in this page seems a bit strange...
https://catagolue.appspot.com/census/b3s23/D2_+2/xq4
Seems perfectly fine to me. MWSS on MWSS 1 is the most common spaceship combination in C1, so it would still make sense for it to occur as often as there even if it is wrongly-symmetric.

Re: apgsearch v3.1

Posted: April 5th, 2016, 1:54 am
by Scorbie
thunk wrote:
Scorbie wrote:The census in this page seems a bit strange...
https://catagolue.appspot.com/census/b3s23/D2_+2/xq4
Seems perfectly fine to me. MWSS on MWSS 1 is the most common spaceship combination in C1, so it would still make sense for it to occur as often as there even if it is wrongly-symmetric.
I should have been clearer... There are a LOT of lwss mwss and hwss but there are only 6 occurrences of M on M and no H on H.

Edit:: Oh pardon. That seems okay, after looking through the tabulations of C1 soups...

Re: apgsearch v3.1

Posted: April 5th, 2016, 10:13 am
by muzik
There should technically be a different thread for the Catagolue site, unless that isn't really needed for some reason.

Anyway, suggestion: I think there should be a "central" page which documents all discoveries in a certain rule across all symmetries.