LLSSS min pop search results spam

[DroneBetter]

Keith, your program is capable of enumerating oscillators by population as well as spaceships, right? Does it incur the same exponential slowdown with period when they're stationary?
I ask because there seem to be no such enumerations for oscillators in recent history beyond period 2 in 2018 (for A056614), our best result (cited by the wiki, at least) for period-8 oscillators is that there are none of population ≤ 10, which I presume was from an original search by Mark Niemiec and not Paul Callahan's census of the results of all polyplet clusters in 1997 (which only went up to 9), but happened no later than March 8, 2000. This leads to the somewhat inelegant note in Figure eight,

With 12 cells in its smallest phase, it is the smallest known period 8 oscillator, ahead of blocker at 15 cells. It is known that no period 8 oscillators exist with 10 or fewer cells.

The extremely highly suspected nonexistence of an 11-cell one seems like the kind of thing that ought to have been known very much earlier than today.
It would also be nice to make a modern version of Niemiec's page that goes further in both known and exhausted counts and contains your tabulated results in both oscillators and spaceships, maybe in the LifeWiki: space (alike LifeWiki:Game of Life Status page and LifeWiki:Spaceship Search Status Page).

[amling]

Keith, your program is capable of enumerating oscillators by population as well as spaceships, right? Does it incur the same exponential slowdown with period when they're stationary?
I ask because there seem to be no such enumerations for oscillators in recent history beyond period 2 in 2018 (for A056614), our best result (cited by the wiki, at least) for period-8 oscillators is that there are none of population ≤ 10, which I presume was from an original search by Mark Niemiec and not Paul Callahan's census of the results of all polyplet clusters in 1997 (which only went up to 9), but happened no later than March 8, 2000. This leads to the somewhat inelegant note in Figure eight,

With 12 cells in its smallest phase, it is the smallest known period 8 oscillator, ahead of blocker at 15 cells. It is known that no period 8 oscillators exist with 10 or fewer cells.

The extremely highly suspected nonexistence of an 11-cell one seems like the kind of thing that ought to have been known very much earlier than today.
It would also be nice to make a modern version of Niemiec's page that goes further in both known and exhausted counts and contains your tabulated results in both oscillators and spaceships, maybe in the LifeWiki: space (alike LifeWiki:Game of Life Status page and LifeWiki:Spaceship Search Status Page).

It has the same problem with failing to terminate once it reaches double pop, but that's double pop of what it considers period 8, namely a bunch of cells, all of which are periodic at period 8, not what humans consider period 8, namely that but also at least some cell has full period. This means e.g. blinkers count and it's gonna be limited to 2*3 - 1 = pop 5. Even so I would bet the horrible performance for higher generation counts will make that intractable.

I have a note to go after statorless p3 since the human definition and the program definition are the same and I think it's conceivable I could get to the obvious target of 140 for the known oscillator.

[DroneBetter]

Following your proof of 30P5H2V0's minimality, could you try searching odd-symmetric 2c/5 in order to prove 44P5H2V0's (since it is less than double 30)? (Unfortunately, the smallest known nontrivial even-symmetric one is 70 cells, but you could perhaps at least disprove the existence of a ≤58-cell example.)

Also, could you try getting lower bounds on the populations of some other speeds (such as c/5), and what is the greatest period for which you believe you could feasibly improve upon the present lower bound of 10 (from Paul Callahan's and Nick Gotts's exhaustive small pattern censuses)?

[amling]

Following your proof of 30P5H2V0's minimality, could you try searching odd-symmetric 2c/5 in order to prove 44P5H2V0's (since it is less than double 30)? (Unfortunately, the smallest known nontrivial even-symmetric one is 70 cells, but you could perhaps at least disprove the existence of a ≤58-cell example.)

I believe 2c/5 odd to pop 57 is in range for my best computer, but the line of projects waiting for it is quite long. That computer was occupied for a month plus with the c/2 asym to pop 127 and a lot of ideas cropped up during that time. It is my intent to eventually run 2c/5 odd to pop 57 there but I absolutely want to burn down some of this queue first.

I had actually already run one of the five phases (which I thought was worst) for 2c/5 odd pop 44 as part of projections to try to decide if I could afford to reach pop 57. It took ~7 h and 8.77 GB. I guess I can see if I can try to squeak the other four phases through on some computer somewhere...

Also, could you try getting lower bounds on the populations of some other speeds (such as c/5), and what is the greatest period for which you believe you could feasibly improve upon the present lower bound of 10 (from Paul Callahan's and Nick Gotts's exhaustive small pattern censuses)?

Theoretically yes, practically unlikely any time soon. I am extremely swamped with projects right now and this min pop stuff runs so very slow. For now I've focused on trying to prove minimality for known ships rather than probe the boundaries for every possible vacuum-compatible velocity. Maybe the future will be different in a few months when I clear out my current backlog and complete the min pop searches for suspected minima.

[amling]

I have a note to go after statorless p3 since the human definition and the program definition are the same and I think it's conceivable I could get to the obvious target of 140 for the known oscillator.

Alas, nope. Pop 125 took ~118GB (no results) and pop 126 hit 120GB limit and died.

[amling]

Following your proof of 30P5H2V0's minimality, could you try searching odd-symmetric 2c/5 in order to prove 44P5H2V0's (since it is less than double 30)? (Unfortunately, the smallest known nontrivial even-symmetric one is 70 cells, but you could perhaps at least disprove the existence of a ≤58-cell example.)

I had actually already run one of the five phases (which I thought was worst) for 2c/5 odd pop 44 as part of projections to try to decide if I could afford to reach pop 57. It took ~7 h and 8.77 GB. I guess I can see if I can try to squeak the other four phases through on some computer somewhere...

2c/5 odd to pop 44 all five phases done, taking ~10.3 GB and ~5.5 days (although on a highly, highly loaded computer so that time is way inflated). Found only 44P5H2V0.

[amling]

c/4 odd to population 61 I already extrapolated to take 5 days for worst phase (of four) and need that same fanciest computer. I'm not as sure about the other three phases but I assume they'll be between 0 and 5 days each.

Phase 0, which I thought would be the worst phase, took ~6.8 days and ~99 GB. It found the known pop 46 gutter ship (as expected, its minimum population is in this phase) and did not find the pop 61 ship mentioned earlier (as expected, it should be found in phase 1). It also found this pop 61 ship, which I at least wasn't expecting and can't seem to find in jslife-moving's small ships collection:

Code: Select all

#C [[ TRACK 0 -1/4 ]]
x = 31, y = 13, rule = B3/S23
13bo3bo$11b9o2$14b3o$13b5o$10b2o7b2o$9b3o7b3o$8bo13bo2$2bo3b2obo11bob
2o3bo$b2o3b2o15b2o3b2o$o2b2o3bo13bo3b2o2bo$bo4b2o15b2o4bo!

Phases 1-3 still WIP.

[DroneBetter]

As another idea for future endeavours, could your program be very efficient at enumerating oscillators of specific period without the constraint of volatility 1? Mark Niemiec's Life Object Counts page (which I have now copied into LifeWiki:Object counts, albeit containing only proven values and expanded with your results) has p2 oscillators up to population 21 (at which there are 6596), whereas you were able to find true-period c/2's up to 127 (1370036). However, LLSSS can only reach up to and excluding twice the smallest population of a given simplified speed, so I am presuming you wouldn't be able to go beyond eight cells (or four plus the minimal population of an actual example, if you required a pattern does not oscillate at a subperiod) due to noninteracting blocks, currently. Would it be infeasible to implement object separation and branch disqualification to be able to expand any other rows of the table any further?

[amling]

As another idea for future endeavours, could your program be very efficient at enumerating oscillators of specific period without the constraint of volatility 1? Mark Niemiec's Life Object Counts page (which I have now copied into LifeWiki:Object counts, albeit containing only proven values and expanded with your results) has p2 oscillators up to population 21 (at which there are 6596), whereas you were able to find true-period c/2's up to 127 (1370036). However, LLSSS can only reach up to and excluding twice the smallest population of a given simplified speed, so I am presuming you wouldn't be able to go beyond eight cells (or four plus the minimal population of an actual example, if you required a pattern does not oscillate at a subperiod) due to noninteracting blocks, currently. Would it be infeasible to implement object separation and branch disqualification to be able to expand any other rows of the table any further?

Yeah, min pop oscillators of one form or another have been floated a few times but double block (or double blinker!) is just unavoidable, limiting to pop 7 (double minus one) for odd periods and pop 5 for even periods.

Due to the way LLSSS stores partials (as collection(s) of possible vertical strips) there is no real global state and very much no collection of fully-realized partial results. Any partials output along the way are an illusion, constructed by complicated code which picks some path through the mess. Given this (weird storage of state) I just don't see any way to swing anything that could be described as "object separation and branch disqualification".

The one hacky idea I've had is for e.g. p27 oscillators to start with p9-only wildcard initial rows and force a strict p27 cell in the first row. This is theoretically possible for any prime power period, but I just don't think it's going to work out usefully. For one it's going to undercount the population in that it "doesn't see" the sub-period stuff you're going to have to invent to go above the first rows. Also, it's going to be unable to terminate as soon as you reach completing the smallest real answer plus 3 or 4 cells (to be able to find a disconnect blinker or block) so it's not going to get very far past minimum. And finally, performance of these min pop hacks has just been absolutely awful for higher generation counts.

I guess I will take a brief look at p4 and p5 (p6 is not a prime power and so it's not going anywhere without serious code work to somehow allow "p6 but subperiod", i.e. p2-or-p3 wildcards and also somehow allow strict-p6 wildcards).

[amling]

As another idea for future endeavours, could your program be very efficient at enumerating oscillators of specific period without the constraint of volatility 1? Mark Niemiec's Life Object Counts page (which I have now copied into LifeWiki:Object counts, albeit containing only proven values and expanded with your results) has p2 oscillators up to population 21 (at which there are 6596), whereas you were able to find true-period c/2's up to 127 (1370036). However, LLSSS can only reach up to and excluding twice the smallest population of a given simplified speed, so I am presuming you wouldn't be able to go beyond eight cells (or four plus the minimal population of an actual example, if you required a pattern does not oscillate at a subperiod) due to noninteracting blocks, currently. Would it be infeasible to implement object separation and branch disqualification to be able to expand any other rows of the table any further?

I guess I will take a brief look at p4 and p5...

8 GB gets p4 to pop 8 and extrapolates even 120 GB would only get to pop 10 (pop 11 predicted 350 GB+ memory).

8 GB gets p5 to pop 5 and extrapolates even 120 GB would only get to pop 7 (pop 8 predicted 270 GB+ memory).

Such extrapolation is dicey, especially on such limited and erratic data, but it still makes adding anything to the table somewhat unlikely. I have started runs to 60 GB for the assumed worst phases and will update my extrapolations when that finishes and we'll see if anything seems possible.

By the way, does anyone have any idea how p4 pop 11 is known? It wouldn't be covered by the big pop 10 work and I can't find anything specific about p4 on the linked original page.

EDIT: Extrapolation turned out pretty wrong. p4 pop 11 (worst phase only) finished fine w/in 60 GB but then something horrible happened for p4 pop 12. Due to the p2 wildcard initialization there are nonzero columns (as in not all zero in all generations) which are nonetheless zero weight (no cells in the generation we're counting population in). This means nontrivial cycles in the graph and so when it reaches the depth where it would find mold it also has arbitrary stuff like this:

Code: Select all

x = 101, y = 6, rule = LifeHistory
F.15B2A5B.F.2BABABABABA4B2A5B.F.15B2A5B.F.2BABABABABA4B2A5B.F$F.14BA
2BA4B.F.14BA2BA4B.F.14BA2BA4B.F.14BA2BA4B.F$F.13BABABA4B.F.13BABABA4B
.F.12BA2BABA4B.F.15BABA4B.F$F.13BA2BA5B.F.12B3ABA5B.F.16BA5B.F.13B2AB
A5B.F$F.12BA9B.F.12B3A7B.F.12BAB2A6B.F.13B3A6B.F$F.13BABA6B.F.22B.F.
13BA8B.F.13B2A7B.F!

I got no output other than stack overflow presumably because it hit one of these cycles before completing a first result. I will have to rethink how to handle finding and showing results here. It's a terrible combination of wanting all results at or below a given population but also needing to deal with cycles. Also how on earth are we gonna go back and solve or disprove possible tops for such an infinite mess of possible p2 starting rows? I'm beginning to think this might not be within reach...

I believe p5 is not going to have this problem since it's still-life wildcard initial rows and so any nonzero columns will be nonzero in the key generation. Already pop 6 finished and with materially less memory used than extrapolated. Pop 7+ still WIP.

EDIT2: p5 worst phase finished to pop 8 (but not pop 9) w/in 60 GB. I think I'm gonna forget trying to extrapolate and just put this project in the (long) line for the 120 GB box.

EDIT3: I've realized the p4 pop 12 search shouldn't have been having trouble with mold until 2 rows later than where it crashed, but something like this (p2 in all but last two rows) is the sort of thing it could have been choking on (the last 4 rows of), assuming it could find the pieces even with the pop 12 filtering:

Code: Select all

x = 89, y = 14, rule = LifeHistory
F.19B.F.19B.F.19B.F.19B.F$F.19B.F.19B.F.19B.F.19B.F$F.6B2A11B.F.6B2A
11B.F.6B2A11B.F.6B2A11B.F$F.3BABA2BA10B.F.3BABA2BA10B.F.3BABA2BA10B.F
.3BABA2BA10B.F$F.3B2ABABA2BA7B.F.3B2ABABA2BA7B.F.3B2ABABA2BA7B.F.3B2A
BABA2BA7B.F$F.6BABABABA6B.F.6BABABABA6B.F.6BABABABA6B.F.6BABABABA6B.F
$F.6BA2BA2BA6B.F.6BA2BA2BA6B.F.6BA2BA2BA6B.F.6BA2BA2BA6B.F$F.5B2A5B2A
5B.F.5B2A5B2A5B.F.5B2A5B2A5B.F.5B2A5B2A5B.F$F.4BA2B5A2BA4B.F.7B5A7B.F
.4BA2B5A2BA4B.F.7B5A7B.F$F.6BA5BA6B.F.3BAB2A5B2ABA3B.F.6BA5BA6B.F.3BA
B2A5B2ABA3B.F$F.2BABA2B3ABA2BABA2B.F.2BA4BAB2A5BA2B.F.2BABA2BAB3A2BAB
A2B.F.2BA5B2ABA4BA2B.F$F.2B2A4B2A5B2A2B.F.2B2A3BAB2A4B2A2B.F.2B2A5B2A
4B2A2B.F.2B2A4B2ABA3B2A2B.F$F.19B.F.19B.F.19B.F.19B.F$F.19B.F.19B.F.
19B.F.19B.F!

[amling]

c/4 odd to population 61 I already extrapolated to take 5 days for worst phase (of four) and need that same fanciest computer. I'm not as sure about the other three phases but I assume they'll be between 0 and 5 days each.

Phase 0, which I thought would be the worst phase, took ~6.8 days and ~99 GB. It found the known pop 46 gutter ship (as expected, its minimum population is in this phase) and did not find the pop 61 ship mentioned earlier (as expected, it should be found in phase 1). It also found this pop 61 ship, which I at least wasn't expecting and can't seem to find in jslife-moving's small ships collection:

Code: Select all

#C [[ TRACK 0 -1/4 ]]
x = 31, y = 13, rule = B3/S23
13bo3bo$11b9o2$14b3o$13b5o$10b2o7b2o$9b3o7b3o$8bo13bo2$2bo3b2obo11bob
2o3bo$b2o3b2o15b2o3b2o$o2b2o3bo13bo3b2o2bo$bo4b2o15b2o4bo!

Phases 1-3 still WIP.

Phase 1 completed in ~6.7 days and ~108.8 GB (oops, I was wrong about which was worst), finding the known pop 46 ship (it's pop 54 in this phase), the known pop 61 ship, and this pop 59 ship, which I think is a real surprise (not in jslife-moving and my notes suggest I believed 61 to be the minimum known odd-but-not-gutter ship population):

Code: Select all

#C [[ TRACK 0 -1/4 ]]
x = 27, y = 12, rule = B3/S23
7bo11bo$3o4bo11bo4b3o$bo4bobo9bobo4bo2$2b2obo6b3o6bob2o$bo3b4o4bo4b4o
3bo$bo3bo2bo9bo2bo3bo$6bo13bo$8b2o2b3o2b2o$10bo5bo$10bo5bo$10bobobobo!

Phases 2 and 3 still WIP.

[amling]

c/4 odd to population 61 I already extrapolated to take 5 days for worst phase (of four) and need that same fanciest computer. I'm not as sure about the other three phases but I assume they'll be between 0 and 5 days each.

Not so lucky as "5 days each", but it's all done now. It totaled ~22 days, maxing at 108 GB memory and finding only the above. To repeat/summarize it found (and this should be an exhaustive list of c/4 odd ships up to pop 61):

The known pop 46 gutter ship:

Code: Select all

#C [[ TRACK 0 -1/4 ]]
x = 19, y = 10, rule = B3/S23
3bo11bo$3bo11bo$2bobo9bobo2$bo3bo7bo3bo$bob6ob6obo$o7bobo7bo$o7bobo7bo
$o17bo$bob2ob2o3b2ob2obo!

This new (I think) pop 61 ship:

Code: Select all

#C [[ TRACK 0 -1/4 ]]
x = 31, y = 13, rule = B3/S23
13bo3bo$11b9o2$14b3o$13b5o$10b2o7b2o$9b3o7b3o$8bo13bo2$2bo3b2obo11bob
2o3bo$b2o3b2o15b2o3b2o$o2b2o3bo13bo3b2o2bo$bo4b2o15b2o4bo!

This known pop 61 ship:

Code: Select all

#C [[ TRACK 0 -1/4 ]]
x = 21, y = 13, rule = B3/S23
4b2o9b2o$b2o2bo9bo2b2o$bo17bo$ob2o3bo2bo2bo3b2obo$7b3ob3o$o4bo3bobo3bo
4bo$bo6b2ob2o6bo$bo7bobo7bo$6b2obobob2o$6bo2bobo2bo$9bobo$8bo3bo$8b2ob
2o!

This new (I think) pop 59 ship:

Code: Select all

#C [[ TRACK 0 -1/4 ]]
x = 27, y = 12, rule = B3/S23
7bo11bo$3o4bo11bo4b3o$bo4bobo9bobo4bo2$2b2obo6b3o6bob2o$bo3b4o4bo4b4o
3bo$bo3bo2bo9bo2bo3bo$6bo13bo$8b2o2b3o2b2o$10bo5bo$10bo5bo$10bobobobo!

[amling]

As another idea for future endeavours, could your program be very efficient at enumerating oscillators of specific period without the constraint of volatility 1?

p5 worst phase finished to pop 8 (but not pop 9) w/in 60 GB. I think I'm gonna forget trying to extrapolate and just put this project in the (long) line for the 120 GB box.

p5 worst phase finished to pop 9 (but not pop 10) w/in 120 GB so NG.

[Sokwe]

Do you think that the even-symmetric (2,0)c/5 search up to 58 or 60 cells could be completed with 120 GB? I imagine it would be very close to the memory limit.

[amling]

Do you think that the even-symmetric (2,0)c/5 search up to 58 or 60 cells could be completed with 120 GB? I imagine it would be very close to the memory limit.

I am more than a little confused by my notes regarding 2c/5 even and alas I don't remember what I was thinking. I wrote "first known hit is at P60" which seems to imply I should want to run pop 60, but then all further notes are about targeting pop 70 (which is projected to ~400 GB and thus probably out of reach even if projections are pessimistic). The same projections (which themselves ran the assumed worst phase to pop 58) put pop 60 at ~83 GB which is almost certainly in range.

If 2c/5 even pop 60 is interesting I can absolutely enqueue it, although, as always, it is a long, long line for the sole 120 GB box and right now I'm trying to clear out some of the ideas projects that have cropped up in the mean time before moving on to 2c/5 odd pop 57 which is also likely to take weeks.

EDIT: I reread some of the above which suggests this is the pop 70 ship I was thinking of:

Code: Select all

#C [[ TRACK 0 -2/5 ]]
x = 18, y = 16, rule = B3/S23
2bo12bo$bobo10bobo$2ob2o8b2ob2o$2o14b2o$2bo12bo$2b4o6b4o$2bo2b2o4b2o2b
o$3b2o2bo2bo2b2o$4b2ob4ob2o$5bobo2bobo$6bo4bo2$5bo6bo$3b2ob2o2b2ob2o$
4bo8bo$4b2o6b2o!

I assume 60 is 30P5H2V0 next to itself and I guess based on the status page this isn't known to be minimum so a pop 60 search would confirm that. I will make a note to run 2c/5 even to pop 60.

[Sokwe]

2c/5 pop 32 died in what I suspect is the worst phase search. After that I went back and ran pop 31 which squeaked by, running ~6h on the fanciest machine and maxing out at 119.89GB RAM. It found only the known pop 30 ship. This confirms that ship is smallest and there are no ships with minpop 31.

Based on this and your earlier asymmetric c/4 search, it seems like the asymmetric searches are substantially faster than the symmetric searches, even at similar cell counts (where 30 asymmetric is "similar" to 60 symmetric). Is that the case?

Given that the 31-cell 2c/5 search took very nearly 120GB RAM, does this essentially rule out the possibility of completing a 62-cell even-symmetric 2c/5 search with 120GB RAM?

[amling]

2c/5 pop 32 died in what I suspect is the worst phase search. After that I went back and ran pop 31 which squeaked by, running ~6h on the fanciest machine and maxing out at 119.89GB RAM. It found only the known pop 30 ship. This confirms that ship is smallest and there are no ships with minpop 31.

Based on this and your earlier asymmetric c/4 search, it seems like the asymmetric searches are substantially faster than the symmetric searches, even at similar cell counts (where 30 asymmetric is "similar" to 60 symmetric). Is that the case?

Given that the 31-cell 2c/5 search took very nearly 120GB RAM, does this essentially rule out the possibility of completing a 62-cell even-symmetric 2c/5 search with 120GB RAM?

"Substantially" is perhaps debatable and it's going to be tricky comparing in that even a single population addition is a huge difference. Note that times may vary rather wildly between computers and levels of loading with search projects. Far more stable (and limiting anyway) is max memory.

Alas I don't seem to have 30-cell asymmetric c/4 logs in all phases as I think I was just running what I thought was the worst phase and for symmetric I only have the 61-cell results which aren't divisible by two. The closest comparability I thus have I think is 30-cell asymmetric c/4 in phase 0 which maxed at 63.3 GB and 61-cell odd c/4 phase 0 (so half a cell more I guess?) which maxed at 99.2 GB. My original projections for c/4 asymmetric had suggested each cell was x1.34715625678054 so for half a cell on top of 63.3 GB I would have expected 73.5 GB. So I guess I would say "maybe"? There's a lot of approximation, projection, and comparing apples to oranges in all this.

32-cell 2c/5 failing in 120 GB rules out 64-cell 2c/5 even for sure (the latter should strictly contain the former). The same projections that put 60-cell 2c/5 even at 83.1 GB put 62-cell 2c/5 even at 113.7 GB and 64-cell 2c/5 even at 155.4 GB. This is at least still consistent with "these projections are not total garbage" and "60-cell 2c/5 even is likely in range, 62-cell might be in range, and 64-cell is not in range".

EDIT: Uh, one question for you perhaps is how interesting is 62-cell 2c/5 even assuming 60-cell 2c/5 even completes with no surprises (just the known doubling of the 30-cell ship)? I ask in that it's presumably going to take, as all of these population projects have, an enormous amount of time on the only 120GB-having computer I have and it seems like such a tiny bump.

[Sokwe]

one question for you perhaps is how interesting is 62-cell 2c/5 even assuming 60-cell 2c/5 even completes with no surprises (just the known doubling of the 30-cell ship)?

Lowest priority. Only run it if you have absolutely nothing else to run.

The same projections that put 60-cell 2c/5 even at 83.1 GB put 62-cell 2c/5 even at 113.7 GB and 64-cell 2c/5 even at 155.4 GB. This is at least still consistent with "these projections are not total garbage" and "60-cell 2c/5 even is likely in range, 62-cell might be in range, and 64-cell is not in range".

My naive thought would be that the even-symmetric 62-cell 2c/5 search would necessarily take at least as much memory as the 31-cell 2c/5 asymmetric search (in this case, 119.89GB RAM). If it takes any more memory, then I don't see how it could finish. Am I wrong in this assumption?

[amling]

The same projections that put 60-cell 2c/5 even at 83.1 GB put 62-cell 2c/5 even at 113.7 GB and 64-cell 2c/5 even at 155.4 GB. This is at least still consistent with "these projections are not total garbage" and "60-cell 2c/5 even is likely in range, 62-cell might be in range, and 64-cell is not in range".

My naive thought would be that the even-symmetric 62-cell 2c/5 search would necessarily take at least as much memory as the 31-cell 2c/5 asymmetric search (in this case, 119.89GB RAM). If it takes any more memory, then I don't see how it could finish. Am I wrong in this assumption?

Oh right, 119.89 is extremely close to 120. You're probably right that the extrapolation is just bad and 62 wouldn't make it anyway. Theoretically the machine has 128 GB (there is just other stuff in some of it so I usually limit to 120 GB) and there is swap if we really had to squeeze it through. Anyway, sounds like not happening since I am never out of search projects for this machine.

[amling]

2c/5 odd searches completed pop 57 in all five phases with a max memory of 79.7 GB and a total time of 13 days. Found only 44P5H2V0 and the known pop 57 ship and barring bugs this is a complete accounting of 2c/5 odd patterns of pop 57 or less.

[amling]

2c/5 even searches completed for pop 60 in all five phases: max memory 97.8 GB, total time ~26.5h. Found (blah blah barring bugs exhaustive collection of pop 60 2c/5 even patterns) only doubles of 30P5H2V0.

[Sokwe]

2c/5 even searches completed for pop 60 in all five phases: max memory 97.8 GB, total time ~26.5h. Found only doubles of 30P5H2V0.

Thanks! Interesting (?) that it took so much less time than the pop 57 odd-symmetric search. Was this the last spaceship min pop search you had in your queue?

the weighting doesn't make sense for gse where I need to not double the weights of reflected columns but rather count two different generations of pattern towards two different generations of bounds. This isn't gonna be fixable without some rather finicky hacking on the code.

I'm guessing this is still too much effort for too minor a result (2c/4 even-glide up to pop 32).

[amling]

Interesting (?) that it took so much less time than the pop 57 odd-symmetric search.

I did look into this a little but nothing really stands out. To a first approximation almost all search time for both was in `l2r_weights` in running the min pop filter and averaged close to 3200% CPU over the entire search (on this 32 proc box). Every even vaguely comparable size of memory number I can find was worse (generally comparing corresponding numbers near the memory peak of the worst of the five phases) for the 2c/5 even search but yet somehow its time is so much better.

The l2r_weights code is a repeated loop of parallel walks over the entire col until its propagated state stabilizes and so runtime is something like order of col size times number of steps it has to take divided by number of processors. Unfortunately I can't see number of steps it took to verify that it was much longer for the 2c/5 odd searches (this is my best guess) and even if I knew it was I would be hard pressed to give any notion of why other than just the shape of the search is different.

Something similar has been observed to happen for LLSSS arbitrary width search expansion steps where it's also a variable number of propagation steps until it stabilizes and some searches have to make surprisingly many, the last of which are frequently very, very small changes (but which still walk the entire column).

I might be somewhat more worried if there wasn't so much output in the log files showing what was happening and a trail of searches preceding this which are somewhat more verifiable (e.g. missed nothing from jslife-moving "small" collections).

Was this the last spaceship min pop search you had in your queue?

It was as the possible unrun searches still in range for today's computer are getting less and less exciting. Perhaps see y'all again on this thread when I get my next computer (which presumably will have more memory).