apgsearch: a high-performance soup searcher
Re: apgsearch: a high-performance soup searcher
@calcyman
Thank you for writing this program, it is fascinating to see the results coming out of it and I am amazed at the performance you've managed to achieve.
Have you considered scoring other soup results rather than just patterns produced, e.g.: interesting objects with no, or minimal, ash score higher, or soups which die out completely. Actually, do you have any idea of the frequency with which that occurs?
Thank you for writing this program, it is fascinating to see the results coming out of it and I am amazed at the performance you've managed to achieve.
Have you considered scoring other soup results rather than just patterns produced, e.g.: interesting objects with no, or minimal, ash score higher, or soups which die out completely. Actually, do you have any idea of the frequency with which that occurs?
The 5S project (Smallest Spaceships Supporting Specific Speeds) is now maintained by AforAmpere. The latest collection is hosted on GitHub and contains well over 1,000,000 spaceships.
Semi-active here - recovering from a severe case of LWTDS.
Semi-active here - recovering from a severe case of LWTDS.
Re: apgsearch: a high-performance soup searcher
Thanks for making this awesome project. I've been playing around with as many non-explosive rules as I can find. I have been getting an error (here) which only seems to happen when using the rule B3468/S0378. It seems to run fine for a little bit, but within a minute, often sooner, the error will pop up. Any ideas?
-Josh Ball.
Re: apgsearch: a high-performance soup searcher
I've been having way too much fun with the latest version. Here's a small note that might be useful to other soup-explorers:
Around line 2166 of the current script is the following code:
If you re-enable this commented-out line and get rid of the hard-coded zero, you can run a search for a given seed, starting from any soup number N that you want. Mind you, this will write over any remaining HTML report file for that seed on your system, and the statistics will be different this time around because they'll be missing the census data for the first N-1 soups. But if you just want to quickly retrieve a high-scoring soup, it should work fine.
For example, my highest score for a soup so far is 35, for a combined MWSS+LWSS+spark coil found in a 40-million-soup run over the weekend. It wasn't really particularly interesting -- before apgsearch it would have been jaw-droppingly amazing, but not so much this week! -- so I didn't make a copy at the time. The top-scoring soup RLEs are written to a temporary directory, so it's a little harder to get hold of them again after you close Golly.
With the above code change, I typed in seed = 40M, number of soups = 100, rule = B3/S23, and initial position = 35752487, and got a fresh link to the soup in question right away, without having to re-search the 35 million soups before it:
Around line 2166 of the current script is the following code:
Code: Select all
# initpos = int(g.getstring("Initial position: ", "0"))
initpos=0
For example, my highest score for a soup so far is 35, for a combined MWSS+LWSS+spark coil found in a 40-million-soup run over the weekend. It wasn't really particularly interesting -- before apgsearch it would have been jaw-droppingly amazing, but not so much this week! -- so I didn't make a copy at the time. The top-scoring soup RLEs are written to a temporary directory, so it's a little harder to get hold of them again after you close Golly.
With the above code change, I typed in seed = 40M, number of soups = 100, rule = B3/S23, and initial position = 35752487, and got a fresh link to the soup in question right away, without having to re-search the 35 million soups before it:
Code: Select all
#C 40M35752487
x = 16, y = 16, rule = B3/S23
b4obo3bob2obo$bob4o6b2o$obo2b3obo2bob2o$2o2bobob5ob2o$o2b3ob2ob4o$2o2b
11o$o2bobo2b5ob2o$o2b2obobobo2bo$o7b2obobo$bobo5bo4bo$o4b2o2bobob3o$2b
3obo5b2o$obobob2o5bo$2ob5o3bobobo$2bob2obobo2b2obo$o2b3obob2obob2o!
Re: apgsearch: a high-performance soup searcher
Thanks. It's unsurprising that this bug has gone unnoticed for so long -- it only affects the second instance of a particular phase and orientation of a spaceship with period >= 10 which fits within a 7-by-7 box!Josh Ball wrote:I have been getting an error (here) which only seems to happen when using the rule B3468/S0378. It seems to run fine for a little bit, but within a minute, often sooner, the error will pop up. Any ideas?
Again, this can be fixed by adding a few lines.
What do you do with ill crystallographers? Take them to the mono-clinic!
Re: apgsearch: a high-performance soup searcher
If you just want the soup from the soup string, I put hashsoup() in a separate script because I wanted to be able to do the same thing. Beware the trailing space if you copy from golly's html viewer.dvgrn wrote:For example, my highest score for a soup so far is 35, for a combined MWSS+LWSS+spark coil found in a 40-million-soup run over the weekend. It wasn't really particularly interesting -- before apgsearch it would have been jaw-droppingly amazing, but not so much this week! -- so I didn't make a copy at the time. The top-scoring soup RLEs are written to a temporary directory, so it's a little harder to get hold of them again after you close Golly.
Code: Select all
# hashsoup.py Convert soup string to 16x16 soup
# Extracted from apgsearch.py v0.4, By Adam P. Goucher
#
# Modified by Arie Paap
# Sept. 2014
import golly as g
import hashlib
# from apgsearch import hashsoup
# Takes approximately 350 microseconds to construct a 16-by-16 soup based
# on a SHA-256 cryptographic hash in the obvious way.
def hashsoup(instring):
s = hashlib.sha256(instring).digest()
thesoup = []
for j in xrange(32):
t = ord(s[j])
for k in xrange(8):
if (t & (1 << (7 - k))):
thesoup.append(k + 8*(j % 2))
thesoup.append(int(j / 2))
g.putcells(thesoup, -8, -8)
# Input the soup string:
g.new("")
soupstring = g.getstring("Enter the soup string?")
g.setname(soupstring)
hashsoup(soupstring)
Code: Select all
# decodeCanon.py Create pattern from canonical representation
# An alphanumeric representation used in apgsearch by Adam P. Goucher
#
# By Arie Paap
# Sept. 2014
#
# ord2() from apgsearch, by Adam P. Goucher
import golly as g
def decodeCanon(canonPatt):
chars = "0123456789abcdefghijklmnopqrstuvwxyz"
ox = 0
x = 0
y = 0
clist = []
ii = 0
while ii < len(canonPatt):
c = canonPatt[ii]
if (c == 'y'):
ii += 1
x += 4 + ord2(canonPatt[ii])
elif (c == 'x'):
x += 3
elif (c == 'w'):
x += 2
elif (c == '0'):
x += 1
elif (c == 'z'):
x = ox
y += 5
else:
u = ord2(c)
v = 1
for jj in xrange(0,5):
if (u & v):
clist += [x, y+jj]
v = v << 1
x += 1
ii += 1
return clist
# Converts a base-36 case-insensitive alphanumeric character into a
# numerical value.
def ord2(char):
x = ord(char)
if ((x >= 48) & (x < 58)):
return x - 48
if ((x >= 65) & (x < 91)):
return x - 55
if ((x >= 97) & (x < 123)):
return x - 87
return -1
canonPatt = g.getstring('Enter canonical representation')
canonPatt = canonPatt.strip().lower()
canonPatt = canonPatt.split('_')[-1]
if not canonPatt:
g.exit('Pattern is empty')
patt = decodeCanon(canonPatt)
g.putcells(patt)
Last edited by wildmyron on October 9th, 2014, 12:11 am, edited 2 times in total.
The 5S project (Smallest Spaceships Supporting Specific Speeds) is now maintained by AforAmpere. The latest collection is hosted on GitHub and contains well over 1,000,000 spaceships.
Semi-active here - recovering from a severe case of LWTDS.
Semi-active here - recovering from a severe case of LWTDS.
Re: apgsearch: a high-performance soup searcher
Excellent idea.If you just want the soup from the soup string, I put hashsoup() in a separate script because I wanted to be able to do the same thing.
Great! I have the standalone script which performs the inverse operation!I also wanted to decode the canonical representation of objects. This script decodes the representation [...]
The representations of linear-growth patterns are sadly non-invertible (I can't think of a meaningful way to canonise wickstretchers, for example), although you can consult the 'first occurrence' column of the table to find a soup that produces a particular linear-growth pattern.The linear growth patterns have a different representation, I haven't delved into linearlyse() yet to work out what it does.
I don't, but it shouldn't be too difficult to implement (quick hack: create a quasi-object called DIEHARD, and then call incobject whenever a soup has zero population).[...] or soups which die out completely. Actually, do you have any idea of the frequency with which that occurs?
What do you do with ill crystallographers? Take them to the mono-clinic!
- praosylen
- Posts: 2443
- Joined: September 13th, 2014, 5:36 pm
- Location: Pembina University, Home of the Gliders
- Contact:
Re: apgsearch: a high-performance soup searcher
What are these "Twit" and "Prodigal sign" objects that keep appearing in the census? I have never heard these terms used before, and I haven't had the time to check what they are?
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...
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...
Re: apgsearch: a high-performance soup searcher
I updated decodeCanon.py to fix a stupid typo, remove a debugging statement and to use ord2() from apgsearch instead of using a dict, which was probably a bit silly.
In another thread you mentioned the p4 and p7 spaceships in B36/S245. I had also run a search there and several non-interacting pairs of p7 spaceships showed up. Is there any chance for pseudo_bangbang() to be able to separate them, or would something specific like countxwsses() be needed?
Also, could you add the rule used and the soup string from firstsoup to the progress file? I think this would make it possible to recreate the html census report at a later time - but additional information may also be required. If you're working on a central database to collect results, this would become redundant though.
Edited to add:
In B367/S245 two non-interacting p168 oscillators are detected as a single object. They maintain a separation distance of two cells at all times (or I'm mistaken), so I hope that they have a better chance of being correctly separated than the pairs of p7 spaceship above.
In B36/S0245 using seed "2014-09-18T15:53:57.851000_wm", in soup number "144768" a pathological object is detected, but the ash is in fact quite mundane. The sanity check at the end of linearlyse is included in my apgsearch but it is this a related issue? Soup rle:
I implemented your quick hack. The result for B3/S23 is that 1 in ~500 16x16 soups die out - less often than the lwss appears and about the same frequency at which the long barge appears.calcyman wrote:I don't, but it shouldn't be too difficult to implement (quick hack: create a quasi-object called DIEHARD, and then call incobject whenever a soup has zero population).[...] or soups which die out completely. Actually, do you have any idea of the frequency with which that occurs?
In another thread you mentioned the p4 and p7 spaceships in B36/S245. I had also run a search there and several non-interacting pairs of p7 spaceships showed up. Is there any chance for pseudo_bangbang() to be able to separate them, or would something specific like countxwsses() be needed?
Code: Select all
x = 26, y = 28, rule = B36/S245
21bo$22bo$19bobo$20bo2$23b3o$23b2o$23bo$12bo$12bo$13bo$9b2ob2o$11b2o3$
13b3o$13b2o$13bo$3bo$3bo$4bo$2ob2o$2b2o3$3b3o$3b2o$3bo!
Edited to add:
In B367/S245 two non-interacting p168 oscillators are detected as a single object. They maintain a separation distance of two cells at all times (or I'm mistaken), so I hope that they have a better chance of being correctly separated than the pairs of p7 spaceship above.
Code: Select all
x = 29, y = 7, rule = B367/S245
25b4o$3o21bo3bo$2b2o20bo3bo$3bo21b4o$3bo$2b2o$3o!
Code: Select all
x = 16, y = 16, rule = B36/S0245
bo5b3ob3obo$2o6bo4b3o$b2o2bobobo4b2o$b2o8bo3bo$o3bobo3b2o$2bob2o3b3obo
bo$o2b2o3bobobobo$b4o2bob3ob3o$3bo7b2ob2o$2bo2b2o2bob2ob2o$bo7b2ob3o$
2bo4b4o3bo$2bob2o5b2o2bo$3b4o7bo$bobobobob2o2b3o$obo3bobob6o!
The 5S project (Smallest Spaceships Supporting Specific Speeds) is now maintained by AforAmpere. The latest collection is hosted on GitHub and contains well over 1,000,000 spaceships.
Semi-active here - recovering from a severe case of LWTDS.
Semi-active here - recovering from a severe case of LWTDS.
Re: apgsearch: a high-performance soup searcher
countxwsses() would probably be needed, although you could conceivably employ the strategy I'm about to mention for separating non-interacting overlapping oscillators.In another thread you mentioned the p4 and p7 spaceships in B36/S245. I had also run a search there and several non-interacting pairs of p7 spaceships showed up. Is there any chance for pseudo_bangbang() to be able to separate them, or would something specific like countxwsses() be needed?
Yes, I'm counting oscillators whose rotors overlap to constitute the same object. One reason for this is that otherwise, it would be possible for (say) a pseudo-object consisting of two reflectorless rotating oscillators to have an overall period of 40, but for each of its components to have period 80. And I'm not sure what this should be counted as.In B367/S245 two non-interacting p168 oscillators are detected as a single object. They maintain a separation distance of two cells at all times (or I'm mistaken), so I hope that they have a better chance of being correctly separated than the pairs of p7 spaceship above.
In theory, using a three-dimensional array (x, y, t) we could distinguish between objects that do not causally affect each other, despite occupying the same space at different times. But Golly doesn't support 3D rules (yet?) so I would have to resort to implementing this manually (which would be awkwardly slow).
Urgh. I have no idea why this is happening; is that oscillator somehow responsible? In particular, does that oscillator appear elsewhere in the census? (It *might* be an ExpungeObjects problem, which tries to expunge monominos.)In B36/S0245 using seed "2014-09-18T15:53:57.851000_wm", in soup number "144768" a pathological object is detected, but the ash is in fact quite mundane. The sanity check at the end of linearlyse is included in my apgsearch but it is this a related issue? Soup rle:
What do you do with ill crystallographers? Take them to the mono-clinic!
Re: apgsearch: a high-performance soup searcher
In 2x2 there's a similar thing goes on where it marks a certain oscillator as 'pathological'. For either of the objects below, it sometimes splits off the 6-cell bit (the 3 dominoes) as a pathological, but sometimes the whole oscillator gets counted correctly.calcyman wrote:Urgh. I have no idea why this is happening; is that oscillator somehow responsible? In particular, does that oscillator appear elsewhere in the census? (It *might* be an ExpungeObjects problem, which tries to expunge monominos.)In B36/S0245 using seed "2014-09-18T15:53:57.851000_wm", in soup number "144768" a pathological object is detected, but the ash is in fact quite mundane. The sanity check at the end of linearlyse is included in my apgsearch but it is this a related issue? Soup rle:
Code: Select all
x = 23, y = 4, rule = B36/S125
obo12bobob4o$obo12bobob4o$2bob4o9bo$b2ob4o8b2o!
I think "twit" is short for tub with tail, but I'm not sure about the other one...A for awesome wrote:What are these "Twit" and "Prodigal sign" objects that keep appearing in the census? I have never heard these terms used before, and I haven't had the time to check what they are?
Re: apgsearch: a high-performance soup searcher
@calcyman
Thanks for the explanation about nearby objects. I can see the difficulties and in some cases the ambiguity of object description and identification.
There seem two be two problems:
* this soup - 2014-09-18T15:53:57.851000_wm144757 - decays to an oscillator, a few dots, and a p7 spaceship. stabilise(3) returns 12 when run on this soup. When census() is run for the 100 soups including this one and 2014-09-18T15:53:57.851000_wm144768 HandlePlumes is run for one step and ClassifyObjects is rerun
* The result of running CoalesceObjects and ClassifyObjects on the problem oscillator is Running APG_HandlePlumes on this object results in
One of the always off cells detected by CoalesceObjects is now lost, and the neighbouring dot is subsequently expunged.
* From here on the object detection tries to deal with a non-periodic object and fails - determining it to be PATHOLOGICAL
Thanks for the explanation about nearby objects. I can see the difficulties and in some cases the ambiguity of object description and identification.
It does appear elsewhere, but not as often. I think Lewis' issue in 2x2 is the same.calcyman wrote:Urgh. I have no idea why this is happening; is that oscillator somehow responsible? In particular, does that oscillator appear elsewhere in the census? (It *might* be an ExpungeObjects problem, which tries to expunge monominos.)In B36/S0245 using seed "2014-09-18T15:53:57.851000_wm", in soup number "144768" a pathological object is detected, but the ash is in fact quite mundane. The sanity check at the end of linearlyse is included in my apgsearch but it is this a related issue? Soup rle:
There seem two be two problems:
* this soup - 2014-09-18T15:53:57.851000_wm144757 - decays to an oscillator, a few dots, and a p7 spaceship. stabilise(3) returns 12 when run on this soup. When census() is run for the 100 soups including this one and 2014-09-18T15:53:57.851000_wm144768 HandlePlumes is run for one step and ClassifyObjects is rerun
* The result of running CoalesceObjects and ClassifyObjects on the problem oscillator is
Code: Select all
x = 5, y = 5, rule = APG_ClassifyObjects_B36S0245
4.I$.2IJ$.J2I$.2JI$I!
Code: Select all
x = 5, y = 5, rule = APG_HandlePlumes
4.A$.2AB$.B2A$2.BA$A!
* From here on the object detection tries to deal with a non-periodic object and fails - determining it to be PATHOLOGICAL
The 5S project (Smallest Spaceships Supporting Specific Speeds) is now maintained by AforAmpere. The latest collection is hosted on GitHub and contains well over 1,000,000 spaceships.
Semi-active here - recovering from a severe case of LWTDS.
Semi-active here - recovering from a severe case of LWTDS.
- Extrementhusiast
- Posts: 1966
- Joined: June 16th, 2009, 11:24 pm
- Location: USA
Re: apgsearch: a high-performance soup searcher
How well would the apgsearch method work on a rule like sansdomino_s13?
I Like My Heisenburps! (and others)
Re: apgsearch: a high-performance soup searcher
My impression is that it would work really well after some adaptation. There are several places where semi-totalistic rules and rule notation are assumed. In particular, the auxillary rules and various tests that check which rule is being used. Some work would be required to generate the auxillary rules and also account for assumptions about the rule string (such as the test for glider existence). You could either create custom rules for APG_CoalesceObjects, APG_ClassifyObjects, and APG_ContagiousLife; or modify the rule generator to be able to handle rules which are not semi-totalistic. My impression is that APG_ClassifyObjects would require the most work to adapt, but I haven't thought through the details. I have been thinking about similar adaptations for multi-state rules, but I suspect that's even more complicated.Extrementhusiast wrote:How well would the apgsearch method work on a rule like sansdomino_s13?
One thing to remember is that apgsearch is highly optimised for the ash left behind by B3/S23 - small still lifes, low period oscillators, and gliders. It also has some special case logic for dealing with multiple xWSSs and a few other assumptions built in. If the rule you're interested in searching is significantly different then you don't need these optimisations. SansDomino_S13 however, has sufficiently similar behaviour that you would want to keep the benefit of those optimisations. Searches there might also benefit from an adapted IdentifyGliders rule which would need to be similarly special cased as in the current version.
The 5S project (Smallest Spaceships Supporting Specific Speeds) is now maintained by AforAmpere. The latest collection is hosted on GitHub and contains well over 1,000,000 spaceships.
Semi-active here - recovering from a severe case of LWTDS.
Semi-active here - recovering from a severe case of LWTDS.
Re: apgsearch: a high-performance soup searcher
Do you see an easy way to adapt the script so that it would read patterns from a file, rather than generating random soups? I tried it, but it appeared not that trivial to me.
Another question that bothers me, how to get all the patterns that evolve a particular object?
Another question that bothers me, how to get all the patterns that evolve a particular object?
Ivan Fomichev
Re: apgsearch: a high-performance soup searcher
Quick hack: replace hashsoup(instring) with something like:codeholic wrote:Do you see an easy way to adapt the script so that it would read patterns from a file, rather than generating random soups? I tried it, but it appeared not that trivial to me.
Code: Select all
def hashsoup(instring):
d = os.path.dirname(g.getdir("patterns"))
f = os.path.join(d, instring + ".rle")
g.open(f)
Code: Select all
sqrtspp = 1
A better solution would be to factor the stabilisation, censusing and object recognition code into a library and write separate utilities which utilise the library to do a range of tasks.
I've thought about doing that too. I guess you could adapt the awardpoints functions (if you only want uncommon objects) to add each (object, soup) pair to a list, and then write them out to the progress file in save_progress()codeholic wrote:Another question that bothers me, how to get all the patterns that evolve a particular object?
The 5S project (Smallest Spaceships Supporting Specific Speeds) is now maintained by AforAmpere. The latest collection is hosted on GitHub and contains well over 1,000,000 spaceships.
Semi-active here - recovering from a severe case of LWTDS.
Semi-active here - recovering from a severe case of LWTDS.
- praosylen
- Posts: 2443
- Joined: September 13th, 2014, 5:36 pm
- Location: Pembina University, Home of the Gliders
- Contact:
Re: apgsearch: a high-performance soup searcher
I just noticed that clocks do not appear to get scored. Is there any way to correct this?
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...
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...
Re: apgsearch: a high-performance soup searcher
I guess the idea was that clocks are just a little too common to need a nonzero score:A for awesome wrote:I just noticed that clocks do not appear to get scored. Is there any way to correct this?
Code: Select all
"xp2_2a54": ("clock", 0),
You can increase the score for any particular object in the same table -- or name uncommon objects you're especially interested in (I've added "xq7_3nw17862z6952": ("loafer",51) !). If your edited score is high enough, your top fifty will include all the soups with your pattern of interest... or at least fifty of them.codeholic wrote:Another question that bothers me, how to get all the patterns that evolve a particular object?
It looks as if you can extend the top-50 list to top-100 or more by changing one line:
Code: Select all
for soupnum, score in ilist[:50]:
Re: apgsearch: a high-performance soup searcher
Here's a hacked version of the apgsearch script that implements something along these lines. The firstoccur dictionary is changed to 'alloccur', which keeps a list of soupids for each object not on the common objects list. I didn't change anything in the progress file, though, just made more links to more patterns in the temp directory.wildmyron wrote:I've thought about doing that too. I guess you could adapt the awardpoints functions (if you only want uncommon objects) to add each (object, soup) pair to a list, and then write them out to the progress file in save_progress()codeholic wrote:Another question that bothers me, how to get all the patterns that evolve a particular object?
For really long runs this might make the dictionary a little bloated, and even just really long seed strings will make the HTML table a little ugly, but it seems to work okay otherwise. It should not be mistaken for a competent solution to the problem. If you really want first-occurrence-only links for common objects as well, there's some commented-out code that will probably work.
- praosylen
- Posts: 2443
- Joined: September 13th, 2014, 5:36 pm
- Location: Pembina University, Home of the Gliders
- Contact:
Re: apgsearch: a high-performance soup searcher
Why is this? Pentadecathlons get a score of 15, and they're more common! Even pulsars and LWSS's have nonzero scores, and the clock is many times rarer than them.dvgrn wrote:I guess the idea was that clocks are just a little too common to need a nonzero score.A for awesome wrote:I just noticed that clocks do not appear to get scored. Is there any way to correct this?
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...
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...
Re: apgsearch: a high-performance soup searcher
Out of this list I'll be betting on the Sidecar or Coe ship. The Loafer is certainly small and "natural-mechanism" enough that it probably can be born naturally with a good frequency — but it's also sufficiently slow that its odds of surviving until census aren't that good. A stray R-pentomino can catch up with one from up to 24 cells away, and dodging gliders is also a risk.calcyman wrote:I would guess somewhere between 10^11 and 10^13 soups.Lewis wrote:...which made me think, how long until we start seeing soups which produce the c/7 loafer etc. in Life?
Unless there's a small reasonably-high-period spaceship out there (analogous to the loafer, but hitherto-undiscovered), it's likely to be one of the following five things:Also, anyone got any guesses as to what the next 'natural' spaceship (after glider, *WSS and combinations of 2 interaction *WSSs) will be?
- Loafer;
- Sidecar on HWSS;
- p16 Coe engine on LWSS;
- p12 Schick engine on two LWSSes;
- That small unnamed c/3 spaceship with no known synthesis.
At the other extreme, the Schick engine has excellent getaway odds, but any natural example would probably have to be formed pristine from chaos rather than being "organically synthesized" to any extent.
Something like a 2c/5 ship with a house engine or a small c/4 ship with a tetromino engine, with a small longer-period tail, also seem like fairly likely candidates for Surprizing Things That Might Turn Up, though. After all, we still have no proof on what might be the 5th smallest spaceship, either.
Re: apgsearch: a high-performance soup searcher
After getting Python to work on my laptop, apgsearch turns out to be thoroughly impressive. Usually this 4-year-old laptop overheats from even a flash game, but it survived 10,000,000 apgsearch-powered soups of B34/S26 over just a few hours, running at 1100+ soups per second. That's huge. B34/S26's ash is sparse (about one object per three soups) and 75.5% of it is blinkers, so it's a bit of an ideal case, but that just makes the search cleaner.
The breakdown of 3,373,589 objects is below.
EDIT: Lost a digit somewhere, but that's fixed (and the font). I'm doing a 100,000,000 soup run now and will report those results tomorrow. It's going to take about 22 hours. Yes, searching 100,000,000 soups is now something that a mediocre laptop can do in a day, thanks to calcyman.
The breakdown of 3,373,589 objects is below.
Code: Select all
x = 37, y = 426, rule = B34/S26
o9b3ob3obobob3ob3ob3ob3o$o11bobo3bobo3bo3bo3bo3bo$o9b3ob3ob3o3bob3ob3o
b3o$10bo5bo3bo3bo3bo3bobo$10b3ob3o3bo3bob3ob3ob3o6$bo9b3ob3ob3ob3obobo
$2o11bobobo3bobo3bobo$2o9b3obobo3bob3obobo$bo9bo3bobo3bo3bobobo$11b3ob
3o3bob3obobo6$b2o8bob3ob3obobobobobo$o10bo3bo3bobobobobobo$b2o8bob3o3b
ob3obob3o$2bo8bobo5bo3bobo3bo$11bob3o3bo3bobo3bo6$bo8bob3ob3obobobob3o
$obo7bo3bo3bobobobobobo$obo7bob3o3bobob3obobo$2bo7bobo5bobo3bobobo$10b
ob3o3bobo3bob3o6$bo8bob3ob3ob3ob3obo$obo7bo3bobo5bobobobo$obo7bob3ob3o
b3ob3obo$bo8bobo3bobo3bo3bobo$10bob3ob3ob3ob3obo6$bo8bobob3obobobob3o$
2o8bobobobobobobo3bo$b2o7bobob3obob3o3bo$bo8bobo3bobo3bo3bo$10bobob3ob
o3bo3bo6$o9b3obob3ob3ob3o$2o8bobobobo5bo3bo$2o8b3obob3o3bob3o$bo10bobo
bobo3bobo$10b3obob3o3bob3o6$bobo6b3ob3ob3obobo$2o8bobo3bobo3bobo$b3o6b
3ob3ob3ob3o$2bo9bo3bo3bo3bo$10b3ob3ob3o3bo6$b3o6b3ob3ob3ob3o$o9bo3bobo
bo3bo$b3o6b3obobob3ob3o$bobo8bobobobobo3bo$10b3ob3ob3ob3o6$bo8bobob3ob
3obo$obo7bobo3bo3bobo$2bo7b3ob3ob3obo$bobo8bo3bo3bobo$b3o8bob3ob3obo6$
o10b3ob3ob3obo$3o10bobobobobobo$obo8b3ob3obobobo$3o8bo3bobobobobo$o10b
3ob3ob3obo6$2o8bobobob3o$o9bobobobobo$bo8bobobob3o$2o8bobobo3bo$bo8bob
obob3o6$bo8b3ob3ob3o$bobo8bo3bobobo$obo9bo3bobobo$2bo9bo3bobobo$12bo3b
ob3o6$2o8b3obob3o$o11bobo3bo$bo10bobob3o$2o10bobobo$bo10bobob3o6$2o8b
3obobob3o$o9bo3bobo3bo$bo8b3ob3ob3o$2o10bo3bobo$10b3o3bob3o6$o2bo6bobo
b3obobo$o2bo6bobobobobobo$o2bo6b3ob3ob3o$o2bo8bobobo3bo$12bob3o3bo6$3o
7bobob3ob3o$ob2o6bobo3bobo$4o6b3ob3ob3o$2b2o8bo3bo3bo$2bo9bob3ob3o6$6o
4b3ob3ob3o$o4bo6bobobo3bo$ob2obo4b3ob3o3bo$12bobobo3bo$2b2o6b3ob3o3bo
6$b2o8b3ob3ob3o$4o9bobo3bobo$b2obo6b3ob3ob3o$2b2o9bobobobobo$3b2o6b3ob
3ob3o6$bo8b3ob3ob3o$3obo7bobobobobo$2bo2bo4b3obobob3o$3bobo4bo3bobobob
o$10b3ob3ob3o6$4bo5bob3ob3o$3o2bo4bobobobobo$b2o2bo4bob3ob3o$3bo6bo3bo
bobo$10bob3ob3o6$4o6b3ob3o$o2bo6bo3bobo$4o6b3ob3o$4o8bo3bo$b2o7b3ob3o
6$3bo6b3obobo$b2o2bo4bo3bobo$3obo5b3ob3o$b2o2bo6bo3bo$3bo6b3o3bo6$bobo
bo4b3obobo$3o2bo6bobobo$4bo5b3ob3o$10bo5bo$10b3o3bo6$ob2o6bob3o$3b2o5b
obobo$o3bo5bob3o$2o2bo5bo3bo$b3o6bob3o6$b4o5bobobo$bo2bo5bobobo$5o5bob
3o$b4o5bo3bo$2b2o6bo3bo6$4o6bobo$2obo6bobo$ob2o6bobo$4o6bobo$10bobobo
6$bo8bobo$2o3bo4bobo$6o4b3o$o3b2o6bo$4bo7bo6$bobo6bobo$3o2bo4bobo$2b2o
2bo3b3o$4bobo5bo$12bo6$o2b4o5b3o$ob2o2bo7bo$2obo2bo5b3o$4b2o8bo$12b3o
6$3o7b3o$b2obo7bo$3bo2bo3b3o$3bo2bo3bo$5bo4b3o6$3o7b3o$o3bo7bo$2b2o6b
3o$bo3bo4bo$3b3o4b3o6$b4o5b3o$3obo7bo$bob2o5b3o$b4o5bo$3bo6b3o6$4bo7bo
$3o2b2o5bo$b2o2b3o4bo$3bo8bo$12bo6$bo3bo6bo$b2o3bo5bo$o2b2obo5bo$b2o3b
o5bo$bo3bo6bo6$2bobo2bo4bo$bo2bob3o3bo$obobo7bo$b2o9bo$o2bo8bo6$obo9bo
$o2bobo6bo$bob3o6bo$4b2o6bo$4bo7bo6$5b3o4bo$bo3bobo4bo$2b2o8bo$2o10bo$
2bo9bo6$b4o7bo$3obo7bo$bob3o6bo$b4o7bo$12bo6$obo9bo$o2bo8bo$bo10bo$3b
3o6bo$5b3o4bo$6bo5$4bo7bo$3obo7bo$4bo7bo$bo10bo$bob3o6bo$bo5$4o8bo$2ob
o8bo$ob2o8bo$4o8bo$2bo9bo6$2bo9bo$2bobo7bo$2obo8bo$2bob2o6bo$bobo8bo$
3bo!
Tanner Jacobi
Coldlander, a novel, available in paperback and as an ebook. Now on Amazon.
Coldlander, a novel, available in paperback and as an ebook. Now on Amazon.
Re: apgsearch: a high-performance soup searcher
Has it been actually ever proven, that the glider and three *WSS are the four smallest spaceships?Tropylium wrote:After all, we still have no proof on what might be the 5th smallest spaceship, either.
Ivan Fomichev
Re: apgsearch: a high-performance soup searcher
Halfway through the run, and I found a tiny bubble in the code. (42 million soups and only now does one show up. Incredible performance.) Two closely-spaced c/8 ships in a certain configuration register as one object in apgsearch v0.4. I think it's because of this phase:
One of the sparks from the right ship is two cells away from the left ship, so it "should" interfere with the left ship's evolution. But none of the cells that could be affected actually are, due to the birth numbers of the rulestring. The relevant cell that is born next generation simply appears due to the "4" instead of the "3", for example.
The two ships in question appear from this seed and soup number:
Kazyan's100M_2014-09-30T12:09:21.346000_31187720
Code: Select all
x = 12, y = 10, rule = B34/S26
8b2o$6bo$9bobo$5bo5bo$9bobo$2b2o2bo$b4o3b2o$3ob2o$b4o$2b2o!
The two ships in question appear from this seed and soup number:
Kazyan's100M_2014-09-30T12:09:21.346000_31187720
Tanner Jacobi
Coldlander, a novel, available in paperback and as an ebook. Now on Amazon.
Coldlander, a novel, available in paperback and as an ebook. Now on Amazon.
Re: apgsearch: a high-performance soup searcher
The same issue in a different rule was discussed earlier in this thread. It's unlikely to get a general solution, but if you care about a particular rule then a specific solution is probably not too much work (not that I'm volunteering ).Kazyan wrote:Halfway through the run, and I found a tiny bubble in the code. (42 million soups and only now does one show up. Incredible performance.) Two closely-spaced c/8 ships in a certain configuration register as one object in apgsearch v0.4. ...
The 5S project (Smallest Spaceships Supporting Specific Speeds) is now maintained by AforAmpere. The latest collection is hosted on GitHub and contains well over 1,000,000 spaceships.
Semi-active here - recovering from a severe case of LWTDS.
Semi-active here - recovering from a severe case of LWTDS.
- lukebradford
- Posts: 101
- Joined: October 11th, 2013, 8:07 pm
- Location: Cambridge, MA
- Contact:
Re: apgsearch: a high-performance soup searcher
This is extremely cool, thanks for making it!