ConwayLife.com - A community for Conway's Game of Life and related cellular automata
Home  •  LifeWiki  •  Forums  •  Download Golly

Hacking apgsearch

For scripts to aid with computation or simulation in cellular automata.

Re: Hacking apgsearch

Postby 2718281828 » December 13th, 2018, 7:34 pm

I would like to run a soup that has (diagonally) next to the standard 16x16 box a block,e.g. as in:
x = 18, y = 18, rule = LifeHistory
2C$2C$2.A.A5.A.3A.A$3.A.A.2A2.3A.A$2.A2.A3.3A2.3A$2.3A2.A.A.2A.A.A$4.
2A.A.A3.4A$3.A.A.4A.3A.A$4.8A3.A$2.A5.A2.A.A.A.A$3.3A.A.2A3.A$3.A.A2.
2A3.3A.A$2.A3.A.5A.A.2A$4.4A.3A3.A.A$3.A.A.A2.4A.A.A$7.2A.A.A.A2.A$2.
A.A2.2A2.2A.2A.A$2.2A2.3A.4A.A.A!

But I struggle, with the bitworld format in apgsearch. I require some help on how I could initialise such a soup. Anyone a solution to it?
User avatar
2718281828
 
Posts: 716
Joined: August 8th, 2017, 5:38 pm

Re: Hacking apgsearch

Postby wwei23 » December 13th, 2018, 9:18 pm

2718281828 wrote:I would like to run a soup that has (diagonally) next to the standard 16x16 box a block,e.g. as in:
x = 18, y = 18, rule = LifeHistory
2C$2C$2.A.A5.A.3A.A$3.A.A.2A2.3A.A$2.A2.A3.3A2.3A$2.3A2.A.A.2A.A.A$4.
2A.A.A3.4A$3.A.A.4A.3A.A$4.8A3.A$2.A5.A2.A.A.A.A$3.3A.A.2A3.A$3.A.A2.
2A3.3A.A$2.A3.A.5A.A.2A$4.4A.3A3.A.A$3.A.A.A2.4A.A.A$7.2A.A.A.A2.A$2.
A.A2.2A2.2A.2A.A$2.2A2.3A.4A.A.A!

But I struggle, with the bitworld format in apgsearch. I require some help on how I could initialise such a soup. Anyone a solution to it?

Try the Golly script, it's a lot easier to make custon symmetries with.
User avatar
wwei23
 
Posts: 935
Joined: May 22nd, 2017, 6:14 pm
Location: The (Life?) Universe

Re: Hacking apgsearch

Postby wildmyron » December 14th, 2018, 5:27 am

2718281828 wrote:I would like to run a soup that has (diagonally) next to the standard 16x16 box a block,e.g. as in:
x = 18, y = 18, rule = LifeHistory
2C$2C$2.A.A5.A.3A.A$3.A.A.2A2.3A.A$2.A2.A3.3A2.3A$2.3A2.A.A.2A.A.A$4.
2A.A.A3.4A$3.A.A.4A.3A.A$4.8A3.A$2.A5.A2.A.A.A.A$3.3A.A.2A3.A$3.A.A2.
2A3.3A.A$2.A3.A.5A.A.2A$4.4A.3A3.A.A$3.A.A.A2.4A.A.A$7.2A.A.A.A2.A$2.
A.A2.2A2.2A.2A.A$2.2A2.3A.4A.A.A!

But I struggle, with the bitworld format in apgsearch. I require some help on how I could initialise such a soup. Anyone a solution to it?


Here is a patch to apgmera which will allow you to search soups with an additional block on the diagonal and submit hauls to Catagolue. There are certainly better ways to do this with the tools in lifelib for more complex modifications of the soups (e.g. searching for alternate stabilisations of known puffer engines) but for simply adding a block this is sufficient.
diff --git a/includes/hashsoup2.h b/includes/hashsoup2.h
index fb07b1f..8e23645 100644
--- a/includes/hashsoup2.h
+++ b/includes/hashsoup2.h
@@ -112,6 +112,15 @@ bitworld hashsoup_inner(std::string prehash, std::string symmetry) {
     bw.world[std::pair<int32_t, int32_t>(0, 1)] = d;
     bw.world[std::pair<int32_t, int32_t>(1, 1)] = c;

+    if (symmetry == "C1_Dblock_Test") {
+        bw.setcell(16, 16, 1);
+        bw.setcell(16, 17, 1);
+        bw.setcell(17, 16, 1);
+        bw.setcell(17, 17, 1);
+        return bw;
+    }
+
+
     if ((symmetry == "C1") || (symmetry == "D2_x")) { return bw; }

     bitworld dbw;
diff --git a/main.cpp b/main.cpp
index d32a8db..a4a70df 100755
--- a/main.cpp
+++ b/main.cpp
@@ -98,6 +98,7 @@ int main (int argc, char *argv[]) {

     // Disable verification by default if running on a HPC;
     // otherwise verify three hauls per uploaded haul:
+    verifications = 0; // Avoid verification with this modified client (it should be pretty safe though)
     if (verifications < 0) {
         verifications = (parallelisation <= 4) ? 3 : 0;
     }
diff --git a/mkparams.py b/mkparams.py
index 931b3c7..8c6208a 100644
--- a/mkparams.py
+++ b/mkparams.py
@@ -20,7 +20,8 @@ def main():
         validsyms = ["1x256", "2x128", "4x64", "8x32", "C1"]
     else:
         validsyms = ["1x256", "2x128", "4x64", "8x32", "C1", "C2_4", "C2_2", "C2_1", "C4_4", "C4_1",
-                 "D2_+2", "D2_+1", "D2_x", "D4_+4", "D4_+2", "D4_+1", "D4_x4", "D4_x1", "D8_4", "D8_1"]
+                 "D2_+2", "D2_+1", "D2_x", "D4_+4", "D4_+2", "D4_+1", "D4_x4", "D4_x1", "D8_4", "D8_1",
+                 "C1_Dblock_Test"]

     redsym = symmetry
     while ((len(redsym) > 0) and (redsym[0] == 'i')):

You can see the results of a test haul I submitted here. You will of course need to modify the sample soups to reproduce the census reported objects. The coordinates in the bitworld plane correspond directly to those in Golly when importing the soup's rle into Golly from the clipboard, so you should position a block at (16,16) to recreate the soup.

If you are interested in more complex modifications of the soup then a few functions which may be helpful are:
  • apg2vec() or rle2vec() to convert a pattern to a bitworld vector
  • shift_bitworld() to move this pattern around on the plane
  • bitworld.printrepr() to show the contents of a bitworld plane on the console (use in a test app, not in apgmera)
  • the bitworld type overloads +=, -=, ^=, and &= so that you can easily combine the soup with other patterns

This post is the result of a learning curve for me, so anyone (calcyman ;)) more knowledgeable please correct any bad advice provided here.
The latest version of the 5S Project contains over 150,000 spaceships. Tabulated pages up to period 160 are available on the LifeWiki.
wildmyron
 
Posts: 1166
Joined: August 9th, 2013, 12:45 am

Re: Hacking apgsearch

Postby wildmyron » May 17th, 2019, 2:08 am

Not really a hack, and not particularly useful at the moment, but I'm posting this here for reference.

I recently submitted a number of hauls to Catagolue with symmetry stdin_WM_4G. These hauls included the results of apgsearch processing a small subset of 4G collisions which were generated by a variation of chris_c's popseq.c. There were a few modifications I made to do this:

  • Modify popseq.c to remove the input pattern and output RLE for all collisions instead of evolving them.
  • Fix LifeAPI.h to not leak a LifeString for every call to PrintRLE().
  • Bypass the methuselah detection (which in combination with the 1024 minimum generations that all soups are run for resulted in a LOT of messless soups being reported.
The modified code is in a file named 4Gcolls.cpp (with an updated version of LifeAPI.h) which is attached to this post. The procedure to run the search which generated the results is as follows (but please don't run this verbatim as it will just duplicate the existing results):
# Given commands assume 4Gcolls.cpp is in a directory named popseq alongside the apgmera directory
cd popseq
g++ -O3 -o 4Gcolls 4Gcolls.cpp
cd ../apgmera
./recompile.sh --symmetry stdin_WM_4G
mv apgluxe apgluxe_4g
../popseq/4Gcolls | ./apgluxe_4g -t 0 -L 0 -n 3000000 -k <key>

The choice for the haul size is a bit arbitrary - I tried to balance number of hauls against rare objects only having one sample soup per haul. The census also includes a second set of collisions with one of the gliders coming from a different direction. The other census I created was stdin_WM_sl+4G. This was intended to capture the results of 4G collisions adjacent to a still life object, but I accidentally submitted one set of 4G collisions without the SL object present during testing. I haven't proceeded further with this idea yet.

This experiment was inspired by simeks' 4G collision search. I think it would be worth replicating that, but there are a few issues to consider:

  • I initially tried generating 4G collisions with lifelib, but manipulating pattern2 (or upattern) objects has significantly poorer performance compared to LifeAPI (or presumably GoLGrid). A much better alternative would be to make a custom hashsoup function for apgsearch which generates collisions using the bitworld type (similar to the modification above).
  • More than one sample soup would automatically be submitted with a modified hashsoup function, but should soups be submitted as soupid's (which Catagolue wouldn't know how to recreate) or as RLEs in the same way as the stdin symmetry does (but without using stdin).
  • apgsearch doesn't distinguish between a 4G collision which synthesises a single object and one which evolves into a big mess in which the object appears several thousand gen later (along with a large amount of ash). Finding the 4G gems amongst the rest of the results is tedious, kudos to Ian07, Goldtiger, and anyone else who sifted through those results to find them. Any serious project along these lines should have some way of distinguishing the soups which produce objects that currently require > 4G to synthesise, optionally along with a small number of other ash objects. Perhaps a pseudo-object like the methuselah, messless, and megasized categorizations could be used.
Attachments
4Gcolls.zip
(9.19 KiB) Downloaded 62 times
Last edited by wildmyron on June 5th, 2019, 10:23 am, edited 3 times in total.
The latest version of the 5S Project contains over 150,000 spaceships. Tabulated pages up to period 160 are available on the LifeWiki.
wildmyron
 
Posts: 1166
Joined: August 9th, 2013, 12:45 am

Re: Hacking apgsearch

Postby Freywa » May 17th, 2019, 2:21 am

The modified code is in a file named 4Gcolls.cpp (with an updated version of LifeAPI.h) which is attached to this post.

There's no attachment!
Princess of Science, Parcly Taxel
User avatar
Freywa
 
Posts: 556
Joined: June 23rd, 2011, 3:20 am
Location: Singapore

Re: Hacking apgsearch

Postby wildmyron » May 17th, 2019, 2:25 am

Freywa wrote:
The modified code is in a file named 4Gcolls.cpp (with an updated version of LifeAPI.h) which is attached to this post.

There's no attachment!

Oops, now rectified. I spent so long writing the post I forgot to attach it!
The latest version of the 5S Project contains over 150,000 spaceships. Tabulated pages up to period 160 are available on the LifeWiki.
wildmyron
 
Posts: 1166
Joined: August 9th, 2013, 12:45 am

Re: Hacking apgsearch

Postby 2718281828 » May 17th, 2019, 5:57 pm

wildmyron wrote:apgsearch doesn't distinguish between a 4G collision which synthesises a single object and one which evolves into a big mess in which the object appears several thousand gen later (along with a large amount of ash). Finding the 4G gems amongst the rest of the results is tedious, kudos to Ian07, Goldtiger, and anyone else who sifted through those results to find them. Any serious project along these lines should have some way of distinguishing the soups which produce objects that currently require > 4G to synthesise, optionally along with a small number of other ash objects. Perhaps a pseudo-object like the methuselah, messless, and megasized categorizations could be used.


Yes, there are many useless long-lasting and large 3G collisions, where it seems useless to investigate all collisions.
I think for getting all relevant 4G collisions we should take all collisions with evolving 3G pattern that have a population below 120 and a bounding box below 30x50 [Something like this]. We can take those characteristics (pop bound and bounding box bound) from the upper bounds of meshless pattern.

Something related: Did someone investigate all 2G+2G collisions? It should be computationally doable.
User avatar
2718281828
 
Posts: 716
Joined: August 8th, 2017, 5:38 pm

Re: Hacking apgsearch

Postby GUYTU6J » July 8th, 2019, 5:15 am

dvgrn wrote:
GUYTU6J wrote:A small question: how to search for a monoengine/one-engine cordership?


A fairly efficient way to search for them is to simply run the lastest apgsearch on C1 soups. If there's one out there that can be found by dropping random objects near a switch engine, well, Catagolue might well stumble on it eventually, since it has recorded hundreds of millions of switch engines already.

If you want the search to go faster, you can use the stdin symmetry and some custom coding to make sure that every initial soup includes a switch engine.

How to make such symmetry?
Welcome to share your ideas about
etymology of names!
User avatar
GUYTU6J
 
Posts: 510
Joined: August 5th, 2016, 10:27 am
Location: outside Plain of Life

Re: Hacking apgsearch

Postby wildmyron » July 8th, 2019, 6:46 am

GUYTU6J wrote:
dvgrn wrote:If you want the search to go faster, you can use the stdin symmetry and some custom coding to make sure that every initial soup includes a switch engine.

How to make such symmetry?

You don't have to make such a symmetry - you just compile apgsearch with a symmetry that includes the string "stdin", e.g.
./recompile.sh --rule b3s23 --symmetry stdin_GUYTU6J_SE

and then write a small program which generates random soups along with a switch engine as RLE and sends it to stdout. Run with something like:
SE_soup_gen.py | apgluxe -t 0 -L 0 -n 1000000 -k <your_key>


Alternatively, you can modify the hashsoup function in lifelib to add a switch engine to every soup - similar to the C1_Dblock_test symmetry I posted earlier in the thread. See viewtopic.php?p=66471#p66471

The tradeoff is that the stdin symmetry will probably be slower and will have less soups per object (because only one sample soup per object is recorded in the census) but Catagolue won't be able to provide valid soup RLEs for the custom hashsoup symmetry.
The latest version of the 5S Project contains over 150,000 spaceships. Tabulated pages up to period 160 are available on the LifeWiki.
wildmyron
 
Posts: 1166
Joined: August 9th, 2013, 12:45 am

Re: Hacking apgsearch

Postby GUYTU6J » July 8th, 2019, 8:28 am

wildmyron wrote:Alternatively, you can modify the hashsoup function in lifelib to add a switch engine to every soup - similar to the C1_Dblock_test symmetry I posted earlier in the thread. See viewtopic.php?p=66471#p66471

Is this similar to what codeholic did in the first page of the thread?
By the way, how to modify my apgluxe so that it doesn't notify me about every BLSE or GPSE?
Welcome to share your ideas about
etymology of names!
User avatar
GUYTU6J
 
Posts: 510
Joined: August 5th, 2016, 10:27 am
Location: outside Plain of Life

Re: Hacking apgsearch

Postby Ian07 » July 8th, 2019, 8:50 am

GUYTU6J wrote:By the way, how to modify my apgluxe so that it doesn't notify me about every BLSE or GPSE?

apgluxe automatically stops notifying you after the tenth instance of a specific object in a haul, but if you still find this annoying, go into includes/searcher.h and change this line of code, which is currently line 206 as of v5.09:

if (census[apgcode] > 10) { continue; }


I'd recommend changing this to 1 so that you still get notified about the really rare objects while still receiving minimal notifications for everything else.
Ian07
 
Posts: 243
Joined: September 22nd, 2018, 8:48 am

Re: Hacking apgsearch

Postby wildmyron » July 8th, 2019, 9:39 am

GUYTU6J wrote:
wildmyron wrote:Alternatively, you can modify the hashsoup function in lifelib to add a switch engine to every soup - similar to the C1_Dblock_test symmetry I posted earlier in the thread. See http://www.conwaylife.com/forums/viewto ... 471#p66471

Is this similar to what codeholic did in the first page of the thread?

Indeed, however that modification was to the original Python version, so my comments are perhaps not as relevant. The frequent switch engines will also slow down your search, but probably not so drastic as to be intolerably slow. If you do want to survey a large number of SE soups though, then you may want to tune the stabilisation parameters.
The latest version of the 5S Project contains over 150,000 spaceships. Tabulated pages up to period 160 are available on the LifeWiki.
wildmyron
 
Posts: 1166
Joined: August 9th, 2013, 12:45 am

Previous

Return to Scripts

Who is online

Users browsing this forum: No registered users and 3 guests