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: 685
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 57,000 spaceships. Tabulated pages up to period 160 are available on the LifeWiki.
wildmyron
 
Posts: 1119
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 34 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 57,000 spaceships. Tabulated pages up to period 160 are available on the LifeWiki.
wildmyron
 
Posts: 1119
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: 543
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 57,000 spaceships. Tabulated pages up to period 160 are available on the LifeWiki.
wildmyron
 
Posts: 1119
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: 685
Joined: August 8th, 2017, 5:38 pm

Previous

Return to Scripts

Who is online

Users browsing this forum: No registered users and 1 guest