Q&A for ptbsearch

[Scorbie]

I think survive doesn't work if you only use rock catalysts. Take any perturbation and put only rocks in the catalyst file... survive outputs nothing.

[chris_c]

I think survive doesn't work if you only use rock catalysts. Take any perturbation and put only rocks in the catalyst file... survive outputs nothing.

That's true. It's because the activation condition in survive is when the total number of cells in all perturbers is reduced. See here. Probably it needs two separate conditions to deal with rocks: one to check when the reaction is one cell away from any perturber, and another to check for restoration. I realised this issue when you mentioned it earlier but I didn't manage to think of a satisfying way to write the code. Certainly I don't think it can be a one line fix.

[Scorbie]

I realised this issue when you mentioned it earlier but I didn't manage to think of a satisfying way to write the code. Certainly I don't think it can be a one line fix.

Thanks for considering that. The original post seemed hard to spot with all that catalysts there so I moved it in a more spottable location. Anyway I think we could skip this for the moment as the possibilities for a catalysis to consist of only rocks is pretty rare, I think.

[gmc_nxtman]

Hello. I've been wanting to run ptbsearch for a while now, and when I compile it, I get this really simple error:

Code: Select all

Last login: Mon Aug 17 17:08:45 on ttys001
GalensSlverBook:ptbsearch galenmcholbi$ make
make: *** No rule to make target `genmain.o', needed by `gen'.  Stop.

[chris_c]

Hello. I've been wanting to run ptbsearch for a while now, and when I compile it, I get this really simple error:

Code: Select all

Last login: Mon Aug 17 17:08:45 on ttys001
GalensSlverBook:ptbsearch galenmcholbi$ make
make: *** No rule to make target `genmain.o', needed by `gen'.  Stop.

Yes there is quite a bit of junk in the Makefile of the original ptbsearch. There is a stripped down version of the Makefile in my ptbsearch branch here.

[gmc_nxtman]

Hello. I've been wanting to run ptbsearch for a while now, and when I compile it, I get this really simple error:

Code: Select all

Last login: Mon Aug 17 17:08:45 on ttys001
GalensSlverBook:ptbsearch galenmcholbi$ make
make: *** No rule to make target `genmain.o', needed by `gen'.  Stop.

Yes there is quite a bit of junk in the Makefile of the original ptbsearch. There is a stripped down version of the Makefile in my ptbsearch branch here.

That seemed to have worked. Now I get this error (I need malloc.h)

Code: Select all

GalensSlverBook:ptbsearch galenmcholbi$ make
gcc -O3   -c -o ptb2.o ptb2.c
ptb2.c:4:10: fatal error: 'malloc.h' file not found
#include <malloc.h>
         ^
1 error generated.
make: *** [ptb2.o] Error 1
GalensSlverBook:ptbsearch galenmcholbi$ 

Removing this line gets me this error:

Code: Select all

Last login: Tue Aug 18 08:11:59 on ttys001
GalensSlverBook:ptbsearch galenmcholbi$ make
gcc -O3   -c -o ptb2.o ptb2.c
ptb2.c:12:20: error: redefinition of 'exp' as different kind of symbol
LifeList nb1, nb2, exp, orig;
                   ^
ptb2.c:12:20: note: previous definition is here
ptb2.c:20:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
main(int argc, char *argv[]) {
^
ptb2.c:29:15: error: non-void function 'main' should return a value
      [-Wreturn-type]
  if (argc<3) return;
              ^
1 warning and 2 errors generated.
make: *** [ptb2.o] Error 1
GalensSlverBook:ptbsearch galenmcholbi$ 

The same thing happens if I replace the line with #include <stdlib.h>.

[chris_c]

That seemed to have worked. Now I get this error...

I am aware of codeholic's attempts to get ptbsearch to compile on Mac here.

And of Scorbie's attempts to get ptbsearch to compile on MinGW here.

Hopefully those can be useful for you. Unfortunately I have been too lazy to incorporate this stuff into my branch which I believe has some nice bugfixes.

[Scorbie]

And of Scorbie's attempts to get ptbsearch to compile on MinGW here.

Actually, I changed my c compiler to TDM-GCC (a branch of MinGW, I think) and it compiles fine with your source, so I'm not too sure if the errors are compiler-specific. But I'm glad to help if anyone has problems.

[Scorbie]

About the Gourmet Catalyst:

There are two different forms of the Gourmet catalyst. One is the "canonical" form, known from long ago, and the other form that came out from Bellman searches now and then, I think.

Code: Select all

#C Left: "canonical" form, Right: new form
#C [[ THUMBNAIL VIEWONLY ]]
x = 15, y = 11, rule = B3/S23
10b2o$o9bobo$3o9bo$3bo8b2o$2bobo9bo$2b2o8b2o$12bo$2b2o9bo$2bo7b3o$obo
7bo$2o!

The catalysts' active sites are aligned at the same height. As you can see the original form has more clearance at the top and the new form has more clearance at the bottom.

Most of the time, the two catalysts are interchangable. Here are the two working in action:

Code: Select all

x = 32, y = 20, rule = B3/S23
8b2o6b2o$8bo7bo$2b3o4b3ob2obo$2b3o6bobobo$3o2b2o7bo4b3o$5b2o$4b3o$4bo
17b2o3b2o$4bo16bo2bo2b2o$8bo13bobo$7bobo5b3o5bo$3b2o2bo2bo6bo12b2o$3b
2o3b2o5b3o8b2obobo$26b2obo$30bo$10b3o4bo8b2ob2o$16bobobo6bobo$14b3ob2o
bo5bobo$13bo7bo6bo$13b2o6b2o!

Code: Select all

x = 33, y = 86, rule = B3/S23
b2o$2bo$2bob2ob2obo6bo$3bobobob2o5bobo$4bo12bo10$29b2o$29bobo$31bo$31b
2o5$19b3o$10b2o8bo$11bo6b3o$8b3o$8bo4$26b2o$26bobo$28bo$28b2o19$2o6b2o
$o7bo$b3ob2obo8bo$3bobobo8bobo$4bo12bo10$29b2o$29bobo$31bo$31b2o5$19b
3o$10b2o8bo$11bo6b3o$8b3o$8bo4$26b2o$26bobo$28bo$28b2o!

But recently there was a discovery that works with only one of the two:

Code: Select all

x = 63, y = 33, rule = B3/S23
3b2o$3bo48b2o$4b3o45bo$6bo46b3o$2o53bo$obo$2bo46bo$2b2o4bo40b3o$4bo2b
3o42bo4bo$2b2o3bob2o40bobo2b3o$2bo48b2o3bob2o$3bo$3o48b2o$o50bo$49bobo
$49b2o7$bo$b2o9bo37bo$2b2o7bobo36b2o9bo$2bo8bobo37b2o7bobo$bo10bo38bo
8bobo$50bo10bo2$3b2o$3b2o7b2o38b2o$12b2o38b2o7b2o$61b2o!

Which made me wonder which form to use... There may be some cases where only the "canonical" form works. (If you look at the gourmet you would see that the blinker and the new form are a tight fit.)

Anyway, both forms can be dimerized quite tight:

Code: Select all

#C [[ THUMBNAIL VIEWONLY ]]
x = 20, y = 9, rule = B3/S23
3b2o10b2o$2bo2bo8bo2bo$2bobobo8bobo$b2ob2o8b2ob2o$13bo5bo$b2ob2o8b2ob
2o$obobo10bobo$bo2bo10bo2bo$2b2o12b2o!

[chris_c]

I hacked some options for 180 degree rotational symmetry into ptbsearch. The basic idea is that you specify coordinates (x,y) that the cell (0,0) will map to under a 180 rotation. The input pattern and the rotation of the input pattern are overlaid on top of each other to create a 180 degree symmetric pattern to start from. Similarly, whenever a catalyst is added, so is the 180 degree rotated verison. The branch is here, and the only commit so far in the branch is here.

As a quick example we can try to reproduce the p18 honey farm hassler. In the file pre_hf.rle I put a honey farm predecessor in state 3 LifeHistory (corresponds to 'a' in old style ptbsearch encoding):

Code: Select all

x = 3, y = 4, rule = LifeHistory
.2C$.C2$3C!

Next I trim my catalysts file so that any catalyst that is a 180 degree rotation of another is removed. There would be redundancy otherwise. I save this as halfptb.list and I just use eaters and blocks:

Code: Select all

...*!.***!*!zz!
*!***!...*!..zz!
**!.*!.*.z!..*z!
..**!..*!z.*!z*!
z*!z*!
zz!**!

Next I run ptbsearch. Note that I have removed transparency and minimum interaction time from the list of options. In the p18 honey farm hassler, if the upper left cell of the pre-hf on the left was at (0,0) then the corresponding point for the pre-hf on the right would be (15,5) so I call ptb2 as follows:

Code: Select all

ptb2 pre_hf.rle halfptb.list 18 2 4 15 5 > output.col

18 is max generation, 2 means we use 3 catalysts, 4 is the min generation, 15 and 5 are the coords for the rotation.

You can now view the results with

Code: Select all

makematrix.pl < output.col > output.life

and view the output in Golly. Hopefully the p18 is in there somewhere.

Also I have hacked the 'survive' program so that it only outputs patterns that last a long time without being damaged or becoming p2. So alternatively you could run:

Code: Select all

survive a < output.col > output2.col

and now hopefully the p18 should be the only thing output.

I have played around with this program, using plenty of different values for the x and y coordinates but the only vaguely interesting thing I found so far is a trivial variant of the p18 honey farm hassler where the right hand side has been shifted down by 1 cell. The minimum population is bigger (some sparks die off more slowly) but the bounding box is smaller:

Code: Select all

x = 30, y = 17, rule = B3/S23
3bo22bo$3b3o18b3o$6bo16bo$5b2o16b2o$28b2o$8b2o3bo14bo$8bo4bo12bobo$26b
2o$7b3o10b3o$2b2o$bobo12bo4bo$bo14bo3b2o$2o$5b2o16b2o$6bo16bo$3b3o18b
3o$3bo22bo!

If I get lucky something more notable might appear in the future.

[codeholic]

Well done! Actually you made 2 great additions: first, rotations and second, filtering out results where catalysts are activated periodically. (If I'm not mistaked, in the original version only those solutions were found where catalysts were not activated anymore.)

I found the skewed variant you mentioned when I experimented with this reaction using gencols: viewtopic.php?p=16203#p16203

[Scorbie]

Here's runptb.py for automation of running ptb2 in various offset params:
(Prints current process to stderr)
EDIT2: I'm illiterate in perl. Could anybody add the "displaying process " thingy in ptblist.pl?
EDIT: There was a subtle typo in there so use the new version if you copied the script before this warning!

Code: Select all

#!/usr/bin/env python
# Usage: runptb.py [patfile.rle] [catfile.list] [maxgen] [numcats-1]
#               [mingen] [mini] [minj] [maxi] [maxj] ( redirection...)
#
# This runs ptb2 with offset in [0..maxi]x[0..maxj]-[0..mini]x[0..minj]
# and puts the results into stdout

import os
import sys
from subprocess import call

patfile = sys.argv[1]
catfile = sys.argv[2]
maxgen = sys.argv[3]
numcats = sys.argv[4]
mingen = sys.argv[5]
mini = int(sys.argv[6])
minj = int(sys.argv[7])
maxi = int(sys.argv[8])
maxj = int(sys.argv[9])

cnt = 1
totalcnt = (maxi+1)*(maxj+1) - mini*minj

for i in xrange(maxi+1):
    for j in xrange(maxj+1):
        if i < mini and j < minj: continue

        sys.stderr.write('=========={}/{}==========\n'.format(cnt, totalcnt))
        cnt += 1
        outputname = '.'.join([str(i), str(j), 'col'])
        p = call(['ptb2', patfile, catfile, maxgen, numcats, mingen,\
                  str(i), str(j)])

EDIT3: Could you elaborate this part using the example in the explanation?

As I wrote, I tried to find a half of p18 hassler.

If you added two eaters to a honeyfarm and that didn't come out, I think this is a serious bug... Exactly what params did you run the search with?

I checked it out and it is because of the low survival time of the catalysts when only half of the oscillator is present. (...) The second eater reacts at generation 7 but without the third eater it would be killed at generation 19. Therefore the value of 15 on this line needs to be 11 or lower to get the first two eater placements.

This doesn't mean that for a pattern to be accepted, the whole thing should survive for 15 gens, does it?

[chris_c]

The second eater reacts at generation 7 but without the third eater it would be killed at generation 19. Therefore the value of 15 on this line needs to be 11 or lower to get the first two eater placements.

This doesn't mean that for a pattern to be accepted, the whole thing should survive for 15 gens, does it?

Ptbsearch adds the catalysts in order from earliest activation time to latest. The second eater in the p18 hassler is added to the pattern at generation 7 here:

Code: Select all

x = 12, y = 13, rule = B3/S23
3bo$3b3o$6bo$5bo$5bo3bo$10bo$5bo5bo$5bo5bo$5bo5bo$2b2o2bo3bo$bobo3b3o$
bo$2o!

But now, as some kind of optimisation, ptbsearch runs just this pattern without any future catalysts being added for 15 generations to check if the thing still lives. In fact, when the above pattern is run for 12 generations or more the catalysts die and so this branch of the search tree is ended. That's why I said the number in the call to 'survives' needs to be 11 or less for this example to work.

[Scorbie]

Ah, thanks. That might explain why codeholic could not find the semi-snark! (Which, by the way, is what started this thread.)

Wow, come to think of it, this is significant. This means using ptblist.pl can be (and is often) more accurate than running ptb2 at once as ptblist checks for survival for 10 gens. AND ptblist is way faster.

[Scorbie]

Results to a sample search I made: Having pulsars or PDs is fine for me, but could you reckon why the first and fourth ones got selected? EDIT: Ahh, the reaction hasn't stablized for long and one of the herschel's gliders shoot down the catalyst block. Good to know.

Code: Select all

x = 263, y = 29, rule = B3/S23
12b2o66bo9bo77b2o80b2o$12bo8b2o57b3o5b3o77bo71b2o8bo$21b2o60bo3bo152b
2o$11b3o68b2o3b2o78b3o79b3o$6b2o154b2o9b2o80b2o$5bobo153bobo9bobo79bob
o$5bo155bo13bo81bo$4b2o79b2o73b2o13b2o80b2o$85bo$17b2o225b2o$17bo66b3o
158bo$15bobo227bobo$15b2o143b2o13b2o69b2o$9b3o149bo13bo75b3o$2o159bobo
9bobo85b2o$2o8bo151b2o9b2o77bo8b2o$9b2o156b3o81b2o2$84b3o81bo$167b2o$
85bo$84b2o4$82b2o3b2o$83bo3bo$80b3o5b3o$80bo9bo!

[Scorbie]

WOW. A seemingly new p22.

Code: Select all

x = 22, y = 18, rule = B3/S23
o$3o$3bo17bo$2b2o15b3o$18bo$7bobo8b2o$9bo2$7b2o5bo$7bo5b2o2$12bo$2b2o
8bobo$3bo$3o15b2o$o17bo$19b3o$21bo!

[chris_c]

WOW. A seemingly new p22.

Cool! That one is easily found with:

Code: Select all

ptb2 pre_hf.rle halfptb.list 18 1 5 7 7

But I think I only ran with max-gen as high as 15. Ooops!

[Scorbie]

I was trying to find honey theives with these params:
prehf2.rle

Code: Select all

#C [[ THUMBNAIL VIEWONLY ]]
x = 5, y = 5, rule = B3/S23
2bo$bobo$2ob2o$bobo$2bo!

Code: Select all

ptb2 prehf2.rle halfptb.list 30 1 1 4 4 

When I ran survive I got nothing, when I was expecting to get at least:

Code: Select all

x = 15, y = 15, rule = B3/S23
2bo11bo$2b3o7b3o$5bo5bo$4b2o5b2o2$7bo$6bobo$5b2ob2o$6bobo$7bo2$2b2o5b
2o$3bo5bo$3o7b3o$o11bo!

[Sokwe]

WOW. A seemingly new p22.

Awesome! A suggestion for future searches: start with the following glider-releasing reaction to possibly get a new gun:

Code: Select all

x = 12, y = 9, rule = B3/S23
10b2o$10bo$2b3o3bobo$bo3bo2b2o$o5bo$o5bo$o5bo$bo3bo$2b3o!

[Scorbie]

WOW. A seemingly new p22.

Awesome! A suggestion for future searches: start with the following glider-releasing reaction to possibly get a new gun:

Code: Select all

x = 12, y = 9, rule = B3/S23
10b2o$10bo$2b3o3bobo$bo3bo2b2o$o5bo$o5bo$o5bo$bo3bo$2b3o!

Great Idea! Thanks for the suggestion.

I've changed ptblist.pl to output the progress ("index of current pattern"/"# of all patterns")

Code: Select all

#!/usr/bin/env perl

# Get number of lines
open TEMP, $ARGV[0];
1 while(<TEMP>);
my $all = $.;
close TEMP;

# Main loop of ptb2
open PATLIST, $ARGV[0];
while (<PATLIST>) 
{
    @flds = split(" ");

    if(scalar(@flds) < 2){
        $gen0 = 18;
    }else{
        $gen0 = $flds[1];
    }
    
    if(scalar(@flds)< 4){
        $gen1 = $ARGV[2];
    }elsif($ARGV[2] < $flds[4]){
        $gen1 = $ARGV[2];
    }else{
        $gen1 = $flds[4];
    }
    
    $pat = $flds[0];
    $pat =~ s/!/.\n/g;

    open OUTPAT, "> temp";
    print OUTPAT $pat;
    close OUTPAT;

    print STDERR "==========$./$all==========\n";
    system("ptb2 temp $ARGV[1] $gen1 0 $gen0 1");

}
close PATLIST;
unlink "temp"

And there's ptblist2.pl which is invoked with the same params as ptb2. This means you could adjust # of catalysts to be added, and # of transparent ones among them, if necessary.

Code: Select all

#!/usr/bin/env perl

# Get number of lines
open TEMP, $ARGV[0];
1 while(<TEMP>);
my $all = $.;
close TEMP;

# Main loop of ptb2
open PATLIST, $ARGV[0];
while (<PATLIST>) 
{
    @flds = split(" ");

    if(scalar(@flds) < 2){
        $gen0 = 18;
    }else{
        $gen0 = $flds[1];
    }
    
    if(scalar(@flds)< 4){
        $gen1 = $ARGV[2];
    }elsif($ARGV[2] < $flds[4]){
        $gen1 = $ARGV[2];
    }else{
        $gen1 = $flds[4];
    }
    
    $pat = $flds[0];
    $pat =~ s/!/.\n/g;

    open OUTPAT, "> temp";
    print OUTPAT $pat;
    close OUTPAT;

    print STDERR "==========$./$all==========\n";
    system("ptb2 temp $ARGV[1] $gen1 $ARGV[3] $gen0 $ARGV[5]");

}
close PATLIST;
unlink "temp"

[chris_c]

I was trying to find honey theives with these params...

The eaters in Honey Thieves are "dirty" at generation 14 and "dirty" again at generation 20. They are only "restored" (which means fully intact and no active region surrounding) for the 5 generations 15, 16, 17, 18, 19. I hope that if you change the number here to 5 or less then it will work. In fact it might make sense to get rid of this "if" statement entirely: if we are not interested in transparent catalysts then as long as the catalysts have not been killed we should be happy to output the pattern.

[Scorbie]

I was trying to find honey theives with these params...

The eaters in Honey Thieves are "dirty" at generation 14 and "dirty" again at generation 20. They are only "restored" (which means fully intact and no active region surrounding) for the 5 generations 15, 16, 17, 18, 19. I hope that if you change the number here to 5 or less then it will work. In fact it might make sense to get rid of this "if" statement entirely: if we are not interested in transparent catalysts then as long as the catalysts have not been killed we should be happy to output the pattern.

Thanks for the fast reply. I was amazed to see how well you know about the bits and bits of code in ptbsearch. Anyway that patch worked nicely, which rediscovered honey theives and a known p8:

Code: Select all

x = 175, y = 17, rule = B3/S23
o11bo81bo67bo11bo$3o7b3o79b3o67b3o7b3o$3bo5bo81bo73bo5bo$2b2o5b2o69b2o
9b2o71b2o5b2o$81bo$7bo73bobo83bo$6bobo73b2o5bo76bobo$5b2ob2o78bobo74b
2ob2o$6bobo78b2ob2o74bobo$7bo80bobo76bo$89bo5b2o$4b2o5b2o82bobo64b2o5b
2o$5bo5bo85bo65bo5bo$2b3o7b3o71b2o9b2o61b3o7b3o$2bo11bo72bo72bo11bo$
84b3o$84bo!

So I guess it's working pretty nice.

[codeholic]

WOW. A seemingly new p22.

An extensible p22.

Code: Select all

x = 64, y = 33, rule = B3/S23
42bo$42b3o$45bo17bo$44b2o15b3o$60bo$28bo20bobo8b2o$28b3o20bo$31bo$30b
2o17b2o5bo$49bo5b2o$14bo20bobo$14b3o20bo16bo$17bo36bobo$16b2o17b2o5bo$
35bo5b2o17b2o$o20bobo36bo$3o20bo16bo20b3o$3bo36bobo20bo$2b2o17b2o5bo$
21bo5b2o17b2o$7bobo36bo$9bo16bo20b3o$26bobo20bo$7b2o5bo$7bo5b2o17b2o$
32bo$12bo20b3o$2b2o8bobo20bo$3bo$3o15b2o$o17bo$19b3o$21bo!

[codeholic]

Scorbie's introduction to ptbsearch: viewtopic.php?p=23900#p23900

[Scorbie]

@Chris
1)I made a pull request to your repo. Enhanced ptblist.pl and added some catalysts. (Part of them may be unnecessary) For others, it can be viewed on http://www.github.com/Scorbie/ptbsearch
2)survive crashes on one of the inputs I used, but I'm not sure what the problem is. To make things harder, it works when compiled with -g. (Both -g and -O3 -g works)
This

The input file is here:
https://drive.google.com/file/d/0B057ay ... sp=sharing
and survive crashes on

Code: Select all

survive a < g6211