Riesel base 6 - team drive #4 - EIGHT OR BUST!
 

We are starting Conjectures 'R Us (CRUS) team drive #4 for Riesel base 6 starting at n=150K and continuing until all k's have a prime or we just get tired of searching! :smile: Included in the drive are all remaining 8 k's that need a prime. We have now found 7 primes so there is only 1 k remaining. It is k=1597 with a weight of 272.

The file has been sieved for n=1M-2M. The sieve depth is P=180T. As we find primes, we'll remove k's from the file for higher n-ranges.

This is a very exciting drive. With such a low base and so few k's remaining, we have a very good chance of proving the conjecture over the next few years.

We will be running the remainder of the drive on CRUS PRPnet server port 1400. The server will hand out the final range of n=1.5M-2M.

Instructions for running a PRPnet server and download links can be found [URL="http://www.mersenneforum.org/showthread.php?t=12223"][COLOR=#000080]here[/COLOR][/URL]. The info. specific to this server that needs to be entered into your prpclient.ini file is:

server=G1400:100:1:noprimeleftbehind.net:1400

Server info.:

[B]CRUS PRPnet server (updated 2014-09-03 07:00 GMT):[/B]
maintained by gd_barnes
Short identification: G1400
server: noprimeleftbehind.net
port: 1400
Riesel base 6: 1 k remaining to n=2M
n-range: 1.5M-2M
currently processing at n= [COLOR=#0000ff](complete)[/COLOR]
Server summary: [URL="http://noprimeleftbehind.net:1400/all.html"][COLOR=#000080]http://noprimeleftbehind.net:1400/all.html[/COLOR][/URL]

Many thanks to Lennart for sieving n=150K-1M/P=0.8T-32T and to Karsten for releasing this base for a team effort at n=150K! :smile:

Primes found:
[code]
prime found by
[COLOR=#ff0000]36772*6^1723287-1 Mini-Geek[/COLOR]
[COLOR=red]43994*6^569498-1 unconnected[/COLOR]
[COLOR=red]77743*6^560745-1 unconnected[/COLOR]
[COLOR=red]51017*6^528803-1 Batalov[/COLOR]
[COLOR=red]57023*6^483561-1 Batalov[/COLOR]
[COLOR=red]78959*6^458114-1 Flatlander[/COLOR]
59095*6^171929-1 Mini-Geek
[/code]Status:
[code]
n-range tested by Status # of primes
>3M Puzzle-Peter in progress
2M-3M Puzzle-Peter complete 0
1.5M-2M PRPnet (G1400) complete 1
1.3M-1.5M Puzzle-Peter complete 0
1.28M-1.3M Mathew complete 0
1.25M-1.28M MyDogBuster complete 0
1.24M-1.25M Mathew complete 0
1.051M-1.24M Puzzle-Peter complete 0
1.05M-1.051M mdettweiler complete 0
1.01M-1.05M Flatlander complete 0
1M-1.01M Mini-Geek complete 0
950K-1M unconnected complete 0 (k=36772 only)
900K-950K Batalov complete 0 (k=36772 only)
870K-900K unconnected complete 0 (k=36772 only)
750K-870K Batalov complete 0 (k=36772 only)
600K-750K unconnected complete 0 (k=36772 only)
533K-600K unconnected complete 2 (k=36772, 43994, & 77743 only)
530K-533K mdettweiler complete 0 (k=36772, 43994, & 77743 only)
521K-530K Batalov complete 1 (minus k=1597)
520K-521K Dougal complete 0 (minus k=1597)
514K-520K Batalov complete 0 (minus k=1597)
514K-1M Batalov complete 0 (k=1597 only)
510K-514K Flatlander complete 0
500K-510K Batalov complete 0
482K-500K Batalov complete 1 (minus k=1597, 36772, & 43994)
370K-482K Flatlander complete 1 (minus k=1597, 36772, & 43994)
370K-500K Lennart complete 0 (k=1597, 36772, & 43994 only)
338K-370K Lennart complete 0
335K-338K Flatlander complete 0
323K-335K Batalov complete 0
320K-323K Flatlander complete 0
314K-320K Lennart complete 0
305K-314K KEP complete 0
293K-305K Batalov complete 0
290K-293K Flatlander complete 0
285K-290K Batalov complete 0
280K-285K Flatlander complete 0
275K-280K Lennart complete 0
270K-275K Dougal complete 0
265K-270K Lennart complete 0
260K-265K mdettweiler complete 0
255K-260K Lennart complete 0
250K-255K Flatlander complete 0
220K-250K Lennart complete 0
215K-220K Dougal complete 0
200K-215K Lennart complete 0
195K-200K Flatlander complete 0
190K-195K MyDogBuster complete 0
185K-190K mdettweiler complete 0
180K-185K Flatlander complete 0
175K-180K MyDogBuster complete 0
170K-175K Mini-Geek complete 1
160K-170K Flatlander complete 0
155K-160K MyDogBuster complete 0
150K-155K Mini-Geek complete 0
[/code][B]All sieved files have been tested. Individuals are now testing higher n-ranges.[/B]

Let's blow away the final few k's!


Gary

Reserving first file. (not sure of its n's, one of the mods here can edit this post with the range after you know it, if you want)

[quote=Mini-Geek;186178]Reserving first file. (not sure of its n's, one of the mods here can edit this post with the range after you know it, if you want)[/quote]
That would be 150K-155K. I've sent Gary instructions for uploading the sieve files to the [URL]http://nplb-gb1.no-ip.org/[/URL] server, so he should be able to get those up next time he's online. :smile:

[quote=Mini-Geek;186178]Reserving first file. (not sure of its n's, one of the mods here can edit this post with the range after you know it, if you want)[/quote]

The files are in n=5K ranges, which I'm sure you'll find to be a good size. All files up to n=200K are now posted.

Let us know when you have the file and we'll remove it from the 1st post here.


Gary

Taking 155K-160K

I've got the file.

Taking 160-165.

(8 or Bust. Cool!)

[quote=gd_barnes;186173]Status:
[code]
n-range tested by Status # of primes
155K-160K MyDogBuster in progress
150K-155K Mini-Geek in progress
[/code][/quote]
Haven't you got that backwards?

[quote=Mini-Geek;186242]Haven't you got that backwards?[/quote]
No, that's the way all the other drives have done it for quite a while. Early on, we did them from lowest to highest, but then realized that didn't take long to become a pain in the butt: as soon as the table fills up the heigth of the code box, then you start having to scroll down in order to see the newest stuff. Much easier to put the newest stuff on the top. :smile:

[quote=Flatlander;186224]Taking 160-165.

(8 or Bust. Cool!)[/quote]

I like that. I'll put that in our thread name. :smile:

I was hoping you would. :grin:

I added a little more info. in the 1st post. The file has been sieved for n=150K-1M to P=6T. We should be able to test to n=~300K before more sieving is needed. If I think about it, I'll check it when we get to around n=250K.

The first few files should test quite fast but I'll maintain the n=5K ranges up to at least n=200K. A file at n=200K should take ~50-60% longer to test than one at n=150K. Ideal would have been n=7K or 8K ranges to start with but I didn't want to mess with the odd n-ranges.

Maybe it's worth mentioning that the -l option should be used?

[B][COLOR="Red"]edit:
[/COLOR]
Also taking 165-170.[/B]

150K-155K complete, no primes. Results attached.
Taking 170-175.

Taking 175-180

Taking 180-185

Riesel Base 6
 

Riesel Base 6

155K-160K results No primes

160-170 is complete.

Taking 185K-190K.

175-180 complete Results attached

No Primes

Taking 190-195

180-185 is complete.

Taking 195-200.

Taking 200k-205k

===================

I am sieving base 6 290k-1M

I have 290k-1M done to 8T now.
=======================
Lennart

200k-205k Complete

Taking 205k-215 (2 files )


Lennart

reserving 215-220

[quote=Dougal;187195]reserving 215-220[/quote]
Welcome to Conjectures 'R Us! :grin:

[QUOTE]Welcome to Conjectures 'R Us! :grin:[/QUOTE]

Indeed, welcome.

The files went fast. More files mon capitan (that's you Gary). LOL

Who's going to find the first of 8?

205k-215 (2 files ) no primes Complete

Lennart

I am reserving 220k-230k

Taking from sieve file.

Lennart

Here is 230k-235k

Download and run :)

Lennart

[quote=Lennart;187206]Here is 230k-235k

Download and run :)

Lennart[/quote]
Oh, thanks. Come to think of it, since the sieve file is posted in the team sieve thread, I can access that too...I'll post some files shortly. :smile:

Files have been posted up to n=290K. Since Lennart's doing further sieving for 290K+, these should be all the files that are needed until the sieving is complete.

Come and get 'em! :smile:

Edit: BTW @Gary: I see that Lennart's results are in PRPnet completed_tests.log format. Stay tuned, I'll process them and get the sorted, LLR-format results to you ASAP. :smile:

I reserve 230k-250k

Lennart

220k-230k Complete No primes

Lennart

Holy cow. Fast moving drive! :smile:

Max, Thanks for posting more files. I was going to drop to 3K files at n=220K. I suppose that is not necessary now.

Just to let everyone know: An n=5K file at n=280K could take ~1-2 CPU weeks. If you need a smaller file, feel free to reserve part of one. A personal PRPnet server running several cores on it is probably the best way to process one or more of the files.

It looks like Karsten took all the primes before releasing this base. lol


Gary

Using pr_prob it seems you can expect a prime every ~5100 tests at n=150k and ~8600 at n=250k.
I didnt do exact conversions for digits in base 6 to digits in base 2 hence the ~s.
You are not lacking in primes found.

Taking 250-255.

230k-250k Complete No primes


Taking 255k-260k............................!!

185K-190K complete, no primes. Results attached.

Taking 260K-265K.

255k-260k Complete No primes

it's seems i have to participate to find the next prime, heh? :grin:

[quote=henryzz;187245]Using pr_prob it seems you can expect a prime every ~5100 tests at n=150k and ~8600 at n=250k.
I didnt do exact conversions for digits in base 6 to digits in base 2 hence the ~s.
You are not lacking in primes found.[/quote]

I ran it through my "odds of prime" spreadsheet, which allows the conversion to other bases. Here is what I have:

n=150K; 1 in 5129
n=175K; 1 in 5984
n=200K; 1 in 6839
n=225K; 1 in 7694
n=250K; 1 in 8548
n=275K; 1 in 9403
n=300K; 1 in 10258


It looks like you DID do some sort of conversion to base 6 because your odds are very close to mine. Changing the above to base 2 would have made a much better chance of prime at each level.

Below is what we have completed so far and the expected # of primes at each n-range level. To make it easier, I just took the avg. # of pairs that should be at each range (989 per each n=10K range) and the average n-range. Technically you should use the exponential avg. but the ranges are small enough that's it not too far off. In other words, the estimate should be a few hundredths of a prime higher.

150K-170K; 0.36 primes
175K-190K; 0.24 primes
200K-215K; 0.21 primes
220K-250K; 0.37 primes
255K-260K; 0.06 primes

Total: 1.24 primes

So it looks like we are "lacking" on primes for the range that we have searched so far. Alas, it's only one prime. I do hope we get at least 1 by n=300K. If not, my estimate of finding them all by n=~10M will have to increase to n=~12M-15M. :smile:

We still have some gaps left to fill in yet but the highest percentage increase in n-value between primes so far has been 49.8%...from n=66262 to n=99609. To top that, we'd have to not find a prime up to n>214570. But it's to be expected that the percentage will keep getting larger as we search higher since there are less k's to find a prime for.


Gary

[quote=kar_bon;187287]it's seems i have to participate to find the next prime, heh? :grin:[/quote]

Yes! Bring on the Riesel base 6 prime finder! :smile:

Taking 265K-270K.

Lennart

reserving 270-275 for another computer

Taking 275k-280k



265k-270k complete

Lennart

lennart,i didnt think you reserved 265-275, a typo?

nevermind,looking at your results,it looks to be a typo

[quote=Dougal;187369]lennart,i didnt think you reserved 265-275, a typo?

nevermind,looking at your results,it looks to be a typo[/quote]

Yes sorry. Wrong by me :smile:

shall be 265k-270k


========================================================

I have sieved 290k-1M to 17T now.

978 sec/factor on one core 2,4Ghz

Here it is.





Lennart

[quote=Lennart;187373]Yes sorry. Wrong by me :smile:

shall be 265k-270k


========================================================

I have sieved 290k-1M to 17T now.

978 sec/factor on one core 2,4Ghz

Here it is.





Lennart[/quote]
I've fixed the typo in your original post. Meanwhile, are you planning to continue with the sieve, or are you stopping at 17T? On my computer (C2D 2.2Ghz), tests at ~260K take about 990 seconds apiece. Thus, it would seem that we're still a ways away from optimal for anything >290K.

[quote=mdettweiler;187379]I've fixed the typo in your original post. Meanwhile, are you planning to continue with the sieve, or are you stopping at 17T? On my computer (C2D 2.2Ghz), tests at ~260K take about 990 seconds apiece. Thus, it would seem that we're still a ways away from optimal for anything >290K.[/quote]

Thank's.


Yes it is true that we have to sieve more.

I will countinue to sieve, i just thought we need more to LLR soon :smile:


Lennart

195-200 is complete.

[quote=Lennart;187380]Thank's.


Yes it is true that we have to sieve more.

I will countinue to sieve, i just thought we need more to LLR soon :smile:


Lennart[/quote]
Ah, I see. Well, I was thinking that we should probably wait until the next chunk (290K-400K?) is optimally sieved before breaking off any more for LLRing. If we end up running out of files for a short time, there's always plenty of work over on the Sierpinski side. Of course, the final decision is up to Gary. :smile:

Taking 280-285.

Thought I should give an update on 170k-175k:
I bit off a bit more than I could chew between NPLB, CRUS, and factoring, so I paused this work (after crunching ~45 of the ~280 candidates) until I could finish the NPLB work (specifically, mini-drive 454K-456K; that work is currently getting all of my CPU). That should finish early tomorrow morning, then within another two days or so I'll finish 170k-175k.
Sorry for the delay. Hopefully it's not causing too much trouble. (would be quite a mixed bag if a prime is in 170-175, huh! :smile: on the plus side, we'd be down to 7 k's, on the down side, that means I made other people waste work from doing needless tests on higher n's for the k) I'll be more careful in the future.

[quote=mdettweiler;187383]Ah, I see. Well, I was thinking that we should probably wait until the next chunk (290K-400K?) is optimally sieved before breaking off any more for LLRing. If we end up running out of files for a short time, there's always plenty of work over on the Sierpinski side. Of course, the final decision is up to Gary. :smile:[/quote]

I will have the file sieved to 32T tomorrow :smile:

275k-280k Complete.


Lennart

[quote=Mini-Geek;187391]Thought I should give an update on 170k-175k:
I bit off a bit more than I could chew between NPLB, CRUS, and factoring, so I paused this work (after crunching ~45 of the ~280 candidates) until I could finish the NPLB work (specifically, mini-drive 454K-456K; that work is currently getting all of my CPU). That should finish early tomorrow morning, then within another two days or so I'll finish 170k-175k.
Sorry for the delay. Hopefully it's not causing too much trouble. (would be quite a mixed bag if a prime is in 170-175, huh! :smile: on the plus side, we'd be down to 7 k's, on the down side, that means I made other people waste work from doing needless tests on higher n's for the k) I'll be more careful in the future.[/quote]
No problem--take your time. :smile: A few more days is no big deal.

For sieving extremely huge efforts like at NPLB, I do optimal sieve depth calculations as though we were only sieving a smaller n-range (even though we're actually including the higher n-range); that is the range that plan to break off and that we might finishing LLRing within one year. I do that to take into account future hardware and software improvements.

Here is an example of what I would mean using the sieving of an n=300K-1M range: Let's say we want to break off n=300K-500K, which is only 2/7ths of the range. "Act" as though we are only sieving n=300K-500K by taking your sieving removal rate and dividing it by 2/7ths. So if you're getting a removal rate of 1 every 200 secs., up that to 200 / (2/7) = 700 secs. If your PFGW test at 70% of the breakoff n-range (440K) is the same as that, then you have sieved enough and can break it off.

It's also good to lower the "true" optimal sieve depth on conjectures because k's with primes won't need to be tested for the entire range (if we can ever fine one, lol).

This is a tough decision this go around. Will we be able to test this thing to n=1M in a resonable time frame? I'll define reasonable as < 1 year. At a glance, it seems so but if you analyze it, likely not. It's a HUGE amount of work, even for only 8 k's. If a test at n=260K takes ~1000 secs., then a test at n=260K*4=1.04M will take ~1000*16=16000 secs. or over 4 hours! If Lennart or anyone else like Ian or myself stayed on with many cores for an extended period, probably yes, else probably not.

Let's hold off on a decision on far to sieve for now. BUT...let's NOT hold up files. IMHO, unless a drive is terribly undersieved (say well < 1/2 of what it should be), then never should you force interested testers to wait and work on other efforts that may be less interesting to them.

I don't really have the time but Lennart and Max, if you can coordinate on getting files posted up to a limit that you deem appropriate for the demand here, that would be great. P=32T is a tremendous depth to have sieved to already and we're testing in the upper n=200K's at only P=6T. In other words, even if you do the optimum depth of the entire n=290K-1M range (without my fancy adjustment), we're likely not much undersieved at P=32T for breaking off the n=290K-500K range (i.e. using a PFGW test at 70% or n=437K vs. the removal rate of the entire n=290K-1M file).

Don't overdo the posting of files until we come to a better conclusion on how far to sieve. I'd suggest posting up to n=330K at the most. You could consider posting in n=3K files also. If you do that, you might even just go to n=320K, which would be exactly 10 files. Lennart, with your resources, you could just reserve multiple files. We don't want to force the smaller resourced folks to rush and n=3K files would be good at this point. But at the same time, if there is a gap for too long, we risk wasting a lot of resources searching k's that aren't needed at these lower n-depths. Smaller files would help avoid that. At the higher n-depths, it's far less problematic as the chances are far lower of prime and the testing rate much slower so the gaps are perhaps only 10-20% below the current testing range vs. 30-50%.

And finally: One main reason I'm suggesting holding off on a decision on the optimum sieve depth is that we want to get more of the lower n-range holes filled in to see if there is a prime. If it's one of the heavier weight k's, it could have a large impact on the optimum sieve depth.


Gary

@Gary: Okay, that sounds good. As soon as Lennart's ready with that 32T file, I'll post 3K files up to 320K. If demand carries us past that, I'll post more, though as you said I'll hold off on initially posting more than that until we can get a better determination of how far to sieve.

Meanwhile, I've got to come up with a script to handle splitting of sieve files into team drive-size chunks automatically. I'm getting really tired of having to do those manually. :wink:

p=31999526896457, 19392312 p/sec, 69 factors, 100.0% done, 746 sec/factor
sr2sieve 1.8.9 stopped: at p=32000000000000 because range is complete.
Found factors for 69 terms in 51794.008 sec. (expected about 69.22)
q9550@q9550-desktop:~/Desktop/min/crus_6$

This is on a Intel Q6600 sieved with 4 core (-t4)

Thats ~3000 sec/factor

All will be done in about 4 hr.

Lennart

190K-195K complete - No primes

Results attached

[quote=mdettweiler;187487]@Gary: Okay, that sounds good. As soon as Lennart's ready with that 32T file, I'll post 3K files up to 320K. If demand carries us past that, I'll post more, though as you said I'll hold off on initially posting more than that until we can get a better determination of how far to sieve.

Meanwhile, I've got to come up with a script to handle splitting of sieve files into team drive-size chunks automatically. I'm getting really tired of having to do those manually. :wink:[/quote]

Aw, you wimp! I've been splitting 10's of files manually for a long time now. :smile:

Lennart, could you run a PFGW test of a candidate at n=~437K (70% of n=290K-500K range)? Since we know we're getting ~3000 secs. per factor, that will give us a good idea of how close we are to optimum depth for breaking off n=290K-500K -if- we include the entire n-range in the calculation (i.e. assumes we'll finish n=290K-1M within ~1 year).

Since Max tested n=260K at 990 secs. n=437K should take ~2.8 times that long or ~2800 secs., i.e. (437K/260K)^2, so I think we're even a little past optimum for including the entire range in a calculation for breaking off n=290K-500K.

I think the only way we'd be not past optimum for breaking it off is if Lennart's machine is much slower than Max's machine on a PFGW test. (That seems unlikely!) Therefore I think we can post as many files as we want at this point, although I'd suggest holding off until Tim and Dougal are done with their lower n-ranges. If a prime is found, it would be one thing to have to repost 10 files with a removed k, quite another to do 20-30 of them.

I think we need Karsten to come in here and show us how to find a Riesel base 6 prime! lol


Gary

New sievefile 32T
 

Here it is.

Will soon be back with the time on pfgw

Lennart


EDIT: 59095*6^435235-1 is composite: RES64: [9A8DA7CAF565D7ED] (2961.6498s+0.0260s)

on a q6600@2.4Ghz

Taking 285K-290K

[quote=Batalov;187540]Taking 285K-290K[/quote]
Welcome to Conjectures 'R Us! :grin:

To all: I've posted new n=3K files for 290K-299K. That makes for a total of only three files; this is intentional, since as Gary said earlier, until all the lower ranges come in and we're sure there aren't any primes hiding there, we'll be posting files in smaller batches to minimize admin effort in case of a prime being found. :smile:

[quote=mdettweiler;187545]To all: I've posted new n=3K files for 290K-299K. That makes for a total of only three files; this is intentional, since as Gary said earlier, until all the lower ranges come in and we're sure there aren't any primes hiding there, we'll be posting files in smaller batches to minimize admin effort in case of a prime being found. :smile:[/quote]

Once Tim and Dougal are done with their ranges, we'll be at n=250K. I'd definitely suggest posting more files at that point. After all, although unlikely, we could end up finding more than one prime for the same k, which would give us an extra top-5000 prime, which I won't complain about. :-) This happend on Sierp base 16 where you and I both found primes close together for the same k with 2 different reserved n-ranges. As I recall, it was k=63405 or something like that. Yours was lower so it got reflected as the prime for that k but both primes were reported at top-5000.

[quote=Lennart;187515]Here it is.

Will soon be back with the time on pfgw

Lennart


EDIT: 59095*6^435235-1 is composite: RES64: [9A8DA7CAF565D7ED] (2961.6498s+0.0260s)

on a q6600@2.4Ghz[/quote]

Wow! We're spot on the exact optimum sieve depth for breaking off n=290K-500K. 2961 sec. test time vs. ~3000 sec. removal rate. What a lucky break that is. Therefore we need no more sieving up to n=500K. I would say the next break off should be for n=500K-750K so when we hit n>400K, we can PFGW a candidate at n=675K and compare that to the removal rate of sieving n=500K-1M to see how much more we need to sieve that range.

If we find no primes up to n=500K (heaven forbid!), a fairly accurate estimate for the removal rate is 3000 secs. * (1M-290K) / (1M-500K) = 4260 secs. and an estimate for a PFGW test at n=675K would be 2961 * (675K/435K)^2 = 7130 secs.

Therefore, a rough estimate of the optimum sieve depth for breaking off n=500K-750K assuming no primes up to n=500K is 7130 / 4260 * 32T = ~54T. So if that estimate is close, the additional sieving needed is not great compared to what we've (Lennart) has already done, even if we don't find a prime. If we do find one or more, we may not need to sieve at all! I've had this happen quite a few times when breaking off lower n-ranges on new bases that I start. It all depends on the density of primes you encounter and how high the max n-value / min n-value is in your sieve file. If that ratio is high, like it is here (1M/150K=6.67), frequently you won't have to sieve much further (or at all) for the higher n-ranges IF you've used the entire file for calculating your optimum sieve depth for the lower n-ranges, which is the correct thing to do IF you are actually going to test the entire file within a reasonable time frame.


Gary

59095*6^171929-1 is 3-PRP! :w00t::w00t::w00t::w00t::w00t:

The primality test is running now.
[code]Primality testing 59095*6^171929-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 11, base 1+sqrt(11)
N+1: 59095*6^171929-1 32500/444447 mro=0.126953125[/code]Lessee here... floor(171929*Log(10,6)+Log(10,59095)+1)=133792 digits, (where Log(x, y) = log(y)/log(x), which works out to be the base x log of y) which will place it at #4999 on the top 5000! Guess I should make a top-5000 code for CRUS quick! Edit: [COLOR=red]Prime "59095*6^171929-1" is too small (133792 digits). Need 134593 digits or more for a general prime. [/COLOR]Awww, I just barely missed it being on the top-5000 (even if only for a moment). :sad:

[quote=Mini-Geek;187707]59095*6^171929-1 is 3-PRP! :w00t::w00t::w00t::w00t::w00t:

[/quote]

Congratulation :smile:

Lennart

300000/444447

Primality tests of base 6 numbers this large sure take a while...
This would've been my first non-NPLB and non-base 2 prime to make the top 5000, if only I had discovered it a wee bit sooner. Wasn't quite as down-to-the-wire as you may think, since I still had to run the lengthy primality test before submitting it.

So we now should scratch all 59095 from our work files, right?

All I can say is, it's about time! :w00t:

:banana: :banana: :banana: :banana: :banana:

I'll remove the k from the posted files but will hold off on uploading the new versions until the primality proof comes in.

I'll also remove it from my in-progress file for 260K-265K. Note to anyone else doing this: make sure you adjust the line # accordingly in pfgw.ini after removing anything from the input file. Otherwise, things can get messy. :smile:

Edit: @Batalov, yes.

then better not delete them but stop the runners, "Replace 59095 to //59095", start 'em, right?


P.S. Kinda worked:
[FONT=Arial Narrow]Resuming input file x.txt at line 69[/FONT]
[FONT=Arial Narrow]Using zero-padded FFT length 80K on 78959*6^289478-1[/FONT]
[FONT=Arial Narrow]Resuming at bit 325799[/FONT]
[FONT=Arial Narrow]78959*6^289478-1 is composite: RES64: [24BB3383C8613258] (805.6220s+0.0150s)[/FONT]
[FONT=Arial Narrow]#59095*6^289481-1 - Evaluator failed[/FONT]
[FONT=Arial Narrow]Using zero-padded FFT length 80K on 43994*6^289482-1 ...etc[/FONT]

Primality testing 59095*6^171929-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 11, base 1+sqrt(11)
59095*6^171929-1 [B]is prime![/B] (6022.6429s+0.0067s)

[quote=Batalov;187724]then better not delete them but stop the runners, "Replace 59095 to //59095", start 'em, right?[/quote]
It'll say something like this:
//57023*6^174589-1 - Evaluator failed
and skip that line. No harm done, though it's not really how it should be. Also, it will probably mess up your current line progress, soo...might not really work for your purposes.

[quote=Batalov;187724]then better not delete them but stop the runners, "Replace 59095 to #59095", start 'em, right?[/quote]
Uh...no. I'm pretty sure that the ABC format does NOT accept comments on any other line than the first, and even there, they have to be preceded by "//", not by "#". You have to actually remove the numbers from the file.

The easiest way to do this is with the srfile utility, which is included with the srsieve sieving program. You can get srsieve at [URL]http://www.geocities.com/g_w_reynolds/srsieve/[/URL]. Then, do the following:

-Shut down PFGW.

-Change the first line of the sieve file to "1:M:0:6:258". This essentially puts the file in NewPGen format, which is necessary because srfile doesn't support the particular type of ABC format we're using for this.

-Then, run srfile as follows:
[i]srfile -d 59095*6^n-1 -G sieve-file-name.txt[/i]

-srfile will output the file with the removed k under the name t17_b6.prp. Open that file, and change the first line to "ABC $a*6^$b-1 // {number_primes,$a,1}".

-Now, locate the number in t17_b6.prp that was the one you were in the middle of testing when you shut down PFGW. If you were in the middle of testing something from k=59095, then find the next one after the one you were testing. Look at the line number for that test and write it down.

-Open pfgw.ini and change the line labeled "CurLineNum=" to the number you just wrote down.

-Delete the old sieve file, and rename t17_b6.prp to the old file's name.

-Start PFGW with the same command line you used when you first started your range.

That should do the trick. Note that if any of that seems to complex for you to handle, [b]it won't hurt to just leave the k in[/b]. It's better to spend a few minutes more testing some extra numbers than it is to mess up and skip or re-test part of your range.

To all: I've removed k=59095 from the posted files.

How does PFGW store its list of k's to skip? If that could be easily edited to include 59095, that'd be great. :smile:
Or, here's a simple trick you could do to get it to skip that k:
Stop PFGW
Open your sieve file in Notepad (or similar)
Delete all lines up to the candidate you're currently working on (leave the current one alone)
Put "59095 171929" on its own line at the top (below the header line, of course)
Start PFGW again

When you start PFGW back up, it'll see that the file changed and restart at line 2, find the PRP, then know to skip all with that k, then continue to the one you left off at and resume from its save file. The only downside is that you have to duplicate the few minutes (for me, 13.85 minutes in far-from-optimal conditions, probably closer to 10 minutes CPU time) to find that number is PRP, and do so for every instance of PFGW.

[quote=Mini-Geek;187729]How does PFGW store its list of k's to skip? If that could be easily edited to include 59095, that'd be great. :smile:
Or, here's a simple trick you could do to get it to skip that k:
Stop PFGW
Open your sieve file in Notepad (or similar)
Delete all lines up to the candidate you're currently working on (leave the current one alone)
Put "59095 171929" on its own line at the top (below the header line, of course)
Start PFGW again

When you start PFGW back up, it'll see that the file changed and restart at line 2, find the PRP, then know to skip all with that k, then continue to the one you left off at and resume from its save file. The only downside is that you have to duplicate the few minutes (for me, 13.85 minutes in far-from-optimal conditions, probably closer to 10 minutes CPU time) to find that number is PRP, and do so for every instance of PFGW.[/quote]
Hmm...I guess that works too. One other thing you'll have to make sure is that you remove the re-processed prime from the final results file, but as long as you're fine with doing that and can spare about 10 minutes of CPU time, then this method would work OK. :smile:

To answer your question about how PFGW stores its list of k's to skip, I think it only stores them in memory, and thus the list is lost every time it's restarted. Hmm...methinks maybe the next version of PFGW could save the list in the .ini file to avoid these problems?

Hey guys, make it much easier on yourself. Just leave k=59095 in your in-process files. Maybe you'll find a top-5000 prime for it! :smile: It won't hurt anything to find an extra prime for the same k, especially since it would be top 5000.

It seems that everyone is making it much too hard if you want to remove a k from an in-process file. On your PFGW file, do the following (which is what I always do in files for NON-top 5000 work), which is a variation on what Tim suggested:

1. Change the header to an LLR (NewPGen) header.
2. Use srfile to remove the k.

In the output file from #2, do the following:

3. Remove all lines from the first part of the file that have already been tested.
4. Change the header back to PFGW format.
5. Change the file name back to the same as it was before except add a "-b" or "-2" to the end of it.
6. Run PFGW with the new file name while keeping the existing results named pfgw.out. It just starts from line #1 and continues concatenating results on to pfgw.out.


That's about equal effort and is far less risky than trying to mess with line #'s or inserting a prime at the beginning of it, which would also mess up the line #'s.

One more thing I do in the results file: I manually type a line in there at the CURRENT end of the file that says: Removed k=xxxxx. That would help us if we ever want to match up what was tested with the original sieve file. The comment would show exactly where that k would no longer have results.

Note that I said I do the above for NON-top 5000 work. Personally, I never remove a k from an in-process file if the file is top-5000 work. It's sufficiently sieved. You may as well take a shot with a few more top-5000 tests. Using the approach netted me an extra top 5000 prime on Sierp base 16, even though Max had found a slightly smaller prime on the same k a few days before.

Max note: I have included the # of primes we've found and our current # of k's remaining in the 1st para. of the 1st post here.


Gary

Max,

Let's start uploading files to the noprimeleftbehind server again now. Thanks.


Gary

Shouldn't the title of the thread be "SEVEN OR BUST" now?

Nice find Tim.

[quote=MyDogBuster;187783]Shouldn't the title of the thread be "SEVEN OR BUST" now?

Nice find Tim.[/quote]
FIVE OR BUST didnt change theirs even though they are at 3 now

170k-175k complete, 1 prime found. The results are attached. (I included the two original, untouched log files, and one where I merged them and took out all non-result info, such as restarting notes and the primality test)

Seventeen or Bust hasn't been changing their name with each prime either. Given the informality of "Eight or Bust" we may change it as we go, but then when we're at Five we'll be named the same as another project.

Taking 290-293.

250-255 is complete.

280-285 is complete.

[quote=gd_barnes;187771]Max,

Let's start uploading files to the noprimeleftbehind server again now. Thanks.


Gary[/quote]
Way ahead of you there. :smile: When I removed k=59095 from the posted files, I put the updated ones on the noprimeleftbehind.net server.

Max,

Changed my mind...go ahead and post files up to n=320K in 3K chunks now even though we still have one range for n<=250K to finish up. There's no reason to hold up the drive with this much demand. Even if a prime at a lower limit is found, it doesn't hurt much to be searching a k somewhat higher on the offhand chance that we might get two top-5000 primes for it.

I also don't see any problem with leaving the k in the posted files if a prime is found to reduce admin time. Like other drives, I/we will just note in the 1st post here that k=xxxxx has not been removed from any files and people can make their own decision on whether they want to remove it before searching it. The main situation that I want to remove k's from already posted files is when it is non-top 5000 work, especially where many smaller primes are being found like is the case with the base 3 drives.

Of course if we find a prime, we should go ahead and remove the k from the n=320K-1M portion of the file for future posting of files. I assume you've already done that for k=59095 for n=290K-1M.

Ian,

The "xx or bust" projects just leave their name the same as they find primes...that is "17 or bust" and "5 or bust" so we'll leave it at "eight or bust". I'll be keeping the # of primes found and k's remaining in the 1st para. of the 1st post here.


Gary

[quote=gd_barnes;187833]Max,

Changed my mind...go ahead and post files up to n=320K in 3K chunks now even though we still have one range for n<=250K to finish up. There's no reason to hold up the drive with this much demand. Even if a prime at a lower limit is found, it doesn't hurt much to be searching a k somewhat higher on the offhand chance that we might get two top-5000 primes for it.

I also don't see any problem with leaving the k in the posted files if a prime is found to reduce admin time. Like other drives, I/we will just note in the 1st post here that k=xxxxx has not been removed from any files and people can make their own decision on whether they want to remove it before searching it. The main situation that I want to remove k's from already posted files is when it is non-top 5000 work, especially where many smaller primes are being found like is the case with the base 3 drives.

Of course if we find a prime, we should go ahead and remove the k from the n=320K-1M portion of the file for future posting of files. I assume you've already done that for k=59095 for n=290K-1M.[/quote]
Okay, sounds good. In the particular case of last night when the prime for k=59095 was found, it wasn't a big deal to remove the prime from all the files, since there was only three of them. But, yes, I'll keep that in mind for the future.

Meanwhile, files have been posted up to n=320K. Come and get 'em! :smile:

Done with 285-290K, taking 293-...-305K.

Wrong file name, sorry, but the contents are 285-290K.

260K-265K is complete, no primes. Results are attached.

Note: since my range is well above where Mini-Geek found his prime for k=59095, I removed all the results for that k from my results file, and placed them in a separate file (also attached) to avoid confusion since I removed k=59095 from my input file about halfway through.

270-275 complete,no primes
[ATTACH]4064[/ATTACH]

Reserving n for n from 305K to 314K. A total of 3 files. ETA very soon :smile:

Regards

KEP

215-220 complete,no primes
[ATTACH]4066[/ATTACH]

Taking 314k-320k

Lennart

Nice work everyone to bring us up to n=290K so quickly! :smile:

Files have been posted up to n=350K. Guys, let me know when these files are starting to get too big, and I'll decrease them to n=2K.

314k-320k Complete No primes

Lennart