100000 was know maximal too, anyway.

It took about 2 days to "mine" through the 150K to 500K range, using 3 computers running simultaneously. The stated goal is to reach 1 million, which will take a long week at this rate... Yes because it's O(n²) so imagine a triangle : if you go to one half of a side, you only covered 1/4th of the surface. P&M orbits get a bit scarce/sparse but that's a relevant approximation.

There were a few hiccups because it was all manual operated and I automated as I went but the results look good. The range of scanned numbers is almost quadrupled and this will lead to a much finer sieve (despite the vanishing return). The sieve's efficiency has been evaluated and this foreshadows more investigations.

You can get the whole original log files (47039 orbits) as well as the processed .h and .txt (and the script that generate the ) in the "Files" section.

The corresponding sieve now contains 688 entries and goes up to {14009, 1189}, There is one small parasite (one orbit is rejected ?) that I must investigate though.

.

.

.

I found the "bug" ! 89651 appears twice in gPEAC.2-131540.txt ! I discover this only now, despite my past tests. I should be even more careful about duplicates, as this is already one year old. I updated gPEAC_scan_logs_501K.tbz.

.

.

.

Note : going from 131K to 500K orbits to build the sieve is not totally vain. A simple test included in sieve_out.c shows that testing the range 12-501K reduces the number of candidates from 122941 to 108628. Going to 1 million should help even more but we already see that the new sieve version increases the accuracy by 20% for now. That's still > 2× the number of orbits in the range (47038) but it's going to get better with higher numbers.

The log 149. Tighter C-ving presented some estimates for the powers of 2 and the results are unchanged so far. So w30, w31, w32, w34, w35, w63 are still good candidates.

Source code for the sieve generator, the sieve and the orbit scanner : gPEAC_500K.tbz