simeks wrote:dvgrn wrote:
Here's a minor power-law investigation relating to regular methuselahs:
...
Code: Select all
#C 62 soups, tub plus 2b3o$4bo$o3bo$o2bo$3o!...
Just thought it is worth mentioning that this is in fact
Lidka
Huh, interesting. Lidka predecessors are a really common bottleneck, the most frequent overlap in the 29K bin by about a factor of two.
It's possible to sort the output of my script to find which 16x16 pattern has an ancestor that takes the longest to evolve into Lidka. It turns out to be this one:
Code: Select all
#C 247-tick predecessor of original Lidka, total survival time 29,300 ticks
#C https://catagolue.appspot.com/hashsoup/C1/l_xsQF3KKe8cgm3386587/b3s23
x = 16, y = 16, rule = B3/S23
ob3o2b3ob2obo$obo2bo4bo3b2o$bo2bo2bob2o2b2o$2b2o3bo3b4o$5bo2bo4b2o$o2b
o2bo2bo5bo$ob2ob6o2bo$b3o3bobo2bob2o$b3o2bob2o3b2o$4b4o2b2ob3o$5o3bob
2ob2o$b2ob3obo2b5o$bo2b2ob2o4b3o$6obo$o2b2o3b3obo2bo$o2b3ob4obo2bo!
But of course Catagolue has probably thrown out sixty-odd more Lidka predecessors just after the bin filled up, and many thousands more since Year Zero of apgsearch. So there are probably older ancestors within reach of a dedicated search, though Catagolue won't notice them unless the storage rules are changed.
-- Not that there's any particular market for Lidka predecessors... but I wonder if copies of 32829M are piling up in the 32K and 33K bins?
We know for sure that 40514M (the next possible low-population bottleneck pattern in the
long-lived methuselahs list) isn't waiting to be rediscovered in the 40K bin, since apgsearch is still stubbornly refusing to find any methuselahs at all in the 40nnn range.
NickGotts wrote:dvgrn says:
The exponential curve is painfully bumpy, not nice and smooth.
If the number of methusalehs in successive bins approximates to a power law, then the curve is not exponential: power law distributions approach zero much more slowly. See
https://en.wikipedia.org/wiki/Power_law.
I've read the Wikipedia treatment of power-law approximations, and am now more confused than when I started. Everyone should take both terms I used, "exponential" and "power law", with several grains of salt.
In other words, I'm definitely not at all clear on what the best statistical method would be for fitting a predictive equation to the long-tail curve of counts in the 1000-tick methuselah bins. It just seemed interesting that the apparent excessive noise in the counts for some of the lower bins, could be at least partly explained by early low-population bottlenecks like Lidka.
I suppose something similar might be true for statistical bumps in the N-bit still life counts: if you remove duplicates that are due to the exact same low-bit-count predecessor, maybe the remaining counts would be easier to fit to... um... some smooth curve or other.
-----------------------------------
Meanwhile, here's a version of the methuselah fingerprinter script that handles pulsars as well as beacons correctly, and makes just one call to Catagolue instead of up to five hundred, using lifelib calls to re-create the soups from a
list of soup sample hashes. That link is really most of what is needed -- at least for C1 soups, it's pretty easy to produce them directly from the hash string -- but for now I'll leave it as an exercise for the reader to improve the script to take input from the user about which bin to process, and maybe remove the dependency on lifelib if that causes trouble for too many people.
(In theory, acquiring lifelib is as simple as
pip install python-lifelib, but on Windows it's also necessary to install Cygwin. And people may run into other speed bumps that I haven't thought of yet.)
Anyway:
Code: Select all
# methuselah-fingerprinter-stride-6.py
import golly as g
import urllib2
import lifelib
############################################ #
lifelib.add_cygdir(r'C:\cygwin\cygwin64') # Replace this directory as appropriate for your own system #
##############################################################
sess = lifelib.load_rules('b3s23')
lt = sess.lifetree()
samples = lt.download_samples('b3s23','methuselah_30k')
# quick test that lifelib is functioning correctly #########
# g.note("Number of C1 samples: " + str(len(samples['C1'])))
# g.note("This is what the 41st sample looks like: \n" + str(samples['C1'][40]))
binlimit = 31000
def runget(lastmin):
g.run(1)
p = int(g.getpop())
if lastmin>p: lastmin = p
return p, lastmin
lookup="0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ_!abcdefghijklmnopqrstuvwxyz"
all, count = "", 0
fname = g.getdir("temp")+"soup.rle"
for item in samples['C1']:
item.save(fname)
g.open(fname)
count+=1
g.fit()
g.update()
curmod0pop = int(g.getpop())
min = curmod0pop
curmod1pop, min = runget(min)
curmod2pop, min = runget(min)
curmod3pop, min = runget(min)
curmod4pop, min = runget(min)
curmod5pop, min = runget(min)
arr = []
for i in range(binlimit/6+1):
newmod0pop, min = runget(min)
newmod1pop, min = runget(min)
newmod2pop, min = runget(min)
newmod3pop, min = runget(min)
newmod4pop, min = runget(min)
newmod5pop, min = runget(min)
arr+=[newmod0pop-curmod0pop,newmod1pop-curmod1pop,newmod2pop-curmod2pop,newmod3pop-curmod3pop,newmod4pop-curmod4pop,newmod5pop-curmod5pop]
curmod0pop, curmod1pop, curmod2pop, curmod3pop, curmod4pop, curmod5pop = newmod0pop, newmod1pop, newmod2pop, newmod3pop, newmod4pop, newmod5pop
if i%100==0:
g.show("Soup #" + str(count) + ", T = " + str(i*6))
ptr = binlimit-1
s=""
while ptr>0:
if arr[ptr]!=0: break
ptr-=1
while ptr>0:
s+=lookup[arr[ptr]%64]
ptr -= 1
all+="Soup #" + str(count).ljust(4) + "Min: "+ str(min).ljust(4) + s + "\n"
g.note("Done! Click OK to copy results to the clipboard.")
g.setclipstr(all)
This was tested against the 30k bin (hardcoded a couple of places in the script), and as expected from the relatively low population of the bin, there are only 17 overlapping methuselahs, all due to fairly low-population bottlenecks:
Code: Select all
# predecessor of "pi plus 3 blocks and 2 boats"
C1/l_xc6ESG65SQiM18454601 Soup #114 Min: 32
C1/l_h87jdfEbnuJe123404158 Soup #212 Min: 26
C1/l_WLRPFsB7d4nv6265948 Soup #487 Min: 30
C1/l_4ApGCvbeHruv19387759 Soup #139 Min: 31
C1/l_PHVF44YYqHsT17098941 Soup #259 Min: 24
C1/l_qrQnE9nQsxUx4197988 Soup #20 Min: 23
C1/l_g9gyBfvQJSE910169933 Soup #484 Min: 21
C1/l_jqueKG6XH5sC15085823 Soup #427 Min: 26
C1/l_hbG7Js27XHHC14647911 Soup #221 Min: 18
C1/l_jfBNw3pbmXtm6437394 Soup #119 Min: 23
C1/l_h4JjAZb4X65u20697923 Soup #358 Min: 17
C1/l_vZF8TbCUEHJM276840 Soup #59 Min: 20
C1/l_rps9vD2BbfwE36506758 Soup #363 Min: 31
C1/l_xmmaxw7tvugw20250641 Soup #497 Min: 34
# R-pentomino plus blinker plus block plus junk
x = 16, y = 16, rule = B3/S23
o2b2ob2obobo2bo$2o6b2o2bo2bo$ob2ob5o4bo$6obo2bo3b2o$4ob2o2bob2obo$2o2b
5ob2ob2o$ob2ob3o2bo2bo$5bob3obobo$obo2bob2o5b2o$o6bobo2bo2bo$4bob2obob
5o$bo3b3o2b4o$o4b2o2b2o2bo$bob2obo6bo$o5bo2bob2o$3b2o9b2o!
C1/l_EPAky7dWczBR207300 Soup #47 Min: 21
C1/l_cTD4fz4Kw8Qv77625108 Soup #324 Min: 19
C1/l_QB7gRjJUMbV45083840 Soup #419 Min: 21
By contrast, the next lower bin, 29K, has somewhat over twice the methuselah count (where it "should" be only something like 1.7 times, going by the average probability ratio between bins). But it has 120 duplicates instead of less than 20, due to Lidka and other bottleneck attractors.