mersenneforum.org

mersenneforum.org (https://www.mersenneforum.org/index.php)
-   No Prime Left Behind (https://www.mersenneforum.org/forumdisplay.php?f=82)
-   -   Mini-drive for k=3010-3200 n=420259-600000 (https://www.mersenneforum.org/showthread.php?t=11706)

gd_barnes 2010-04-16 07:39

Max,

All manual results for this drive are now on Jeepford for n=400K-508K except n=492K-493K. I don't know if you're going to do any sieve file matchup but you might get a little frustrated attempting to for a couple of reasons:

1. The results from n=400K-420259 are Chris's that he did before the drive started.
2. Chris left gaps in his searches and set up his sieve file sieved to P=4T for n=420259-500K to fill in the gaps. We used that P=4T file for n=420259-446K but some of the results in there are his and hence, he did not include them in the P=4T file. So for his results, we cannot match them vs. anything.
3. The only results that can match up exactly with an original sieve file are n=430378-446K against the P=4T file and n=449K-492K/493K-508K against our P=30T file. n=446K-449K appeared to be done with a combination of the P=4T, our interim P=19T, and the final P=30T sieved files.

I did quite a bit of work on this tonight and corrected several things:
1. Changed all ' Res64' residues to ' LLR Res64'.
2. Changed Tim's results from LLRnet format to our standard LLR format.
3. Removed 3 duplicate tests.
4. Corrected line spacing on 2 results that did not have a line break; causing them to scroll completely across the file and not match on counts vs. the original sieve file.
5. Matched up the results COUNTS only for n=430378-446K against Chris's original P=4T sieve file and for n=449K-492K/493K-508K against our P=30T sieve file. I did not match the k/n values with the sieve files. n=430378 was the highest range that Chris and below that, his sieve file only included what he had not done.
6. Separated the results into appropriate range files that pertained to some of the above changes in sieve depths and when Chris started/ended his testing. The only thing is that I didn't pull what are his results out of the n=420259-430378 file.

In a synopsis:
1. n<446K was done vs. a P=4T sieve file.
2. n=446K-449K was done vs. a P=4T, 19T, and 30T sieve file.
3. n>449K was done vs. a P=30T sieve file.

If you want to do a k/n pair matchup vs. a sieve file, here is the best course of action: Make sure all results are there and that k/n pairs match up vs. our current P=30T sieve file for the entire n=400K-508K range (minus n=492K-493K). That's it! But let me explain: If there are extra results, ignore them. We just want to make sure all results are there vs. the P=30T file. That way, we know no primes have been missed. That's what I did for filling in the missing results on Benson's range.

Even though Chris started this while at RPS, he was with NPLB when he forwarded us his file. So we may as well load the entire range into the DB, including his stuff starting from n=400K. It'd be a little easier that way. After all, he got us started by providing us his sieve file. The problem will be for you is separating his results out of the n=420259-430378 file because they did not stop right on the n-value. For example, he did some of the n=420259 pairs but not all of them. The 1st post here only rounds off stuff so you'll need to go into the first few posts to find out what is his and what is the next person's results. I got you started by separating out what could easily be separated.


Gary

gamer007 2010-04-16 08:06

[quote=gd_barnes;212001]Gamer,

We're in the process of getting ready to load all manually produced results into our DB, which reflects work done by everyone and gives a score based on effort done. Unfortunately without the n=492K-493K results, the DB won't give you that credit. If you aren't too concerned about that, then don't worry about it. But if you'd like for the DB to give you that credit, you would need to redo that range.

I'm sorry about that. Many times I won't save off the results out of the posts for several weeks. Unfortunately somehow in that post, they did not get attached, even though it appears you intended to post them.


Gary[/quote]

I wouldn't mind redoing it. Do you need it in a hurry? I can pause my current range and start on the old range.

gd_barnes 2010-04-16 08:11

1 Attachment(s)
[quote=gamer007;212006]I wouldn't mind redoing it. Do you need it in a hurry? I can pause my current range and start on the old range.[/quote]

No, no rush. Take your time. We'll load it when you're done with it or with our mammoth process that we're doing. Attached is the file. Thanks!

gamer007 2010-04-16 08:14

No problem. :smile: I'll start on it once I finish the current range.

mdettweiler 2010-04-16 16:28

[quote=gd_barnes;212003]Max,

All manual results for this drive are now on Jeepford for n=400K-508K except n=492K-493K. I don't know if you're going to do any sieve file matchup but you might get a little frustrated attempting to for a couple of reasons:

1. The results from n=400K-420259 are Chris's that he did before the drive started.
2. Chris left gaps in his searches and set up his sieve file sieved to P=4T for n=420259-500K to fill in the gaps. We used that P=4T file for n=420259-446K but some of the results in there are his and hence, he did not include them in the P=4T file. So for his results, we cannot match them vs. anything.
3. The only results that can match up exactly with an original sieve file are n=430378-446K against the P=4T file and n=449K-492K/493K-508K against our P=30T file. n=446K-449K appeared to be done with a combination of the P=4T, our interim P=19T, and the final P=30T sieved files.

I did quite a bit of work on this tonight and corrected several things:
1. Changed all ' Res64' residues to ' LLR Res64'.
2. Changed Tim's results from LLRnet format to our standard LLR format.
3. Removed 3 duplicate tests.
4. Corrected line spacing on 2 results that did not have a line break; causing them to scroll completely across the file and not match on counts vs. the original sieve file.
5. Matched up the results COUNTS only for n=430378-446K against Chris's original P=4T sieve file and for n=449K-492K/493K-508K against our P=30T sieve file. I did not match the k/n values with the sieve files. n=430378 was the highest range that Chris and below that, his sieve file only included what he had not done.
6. Separated the results into appropriate range files that pertained to some of the above changes in sieve depths and when Chris started/ended his testing. The only thing is that I didn't pull what are his results out of the n=420259-430378 file.

In a synopsis:
1. n<446K was done vs. a P=4T sieve file.
2. n=446K-449K was done vs. a P=4T, 19T, and 30T sieve file.
3. n>449K was done vs. a P=30T sieve file.

If you want to do a k/n pair matchup vs. a sieve file, here is the best course of action: Make sure all results are there and that k/n pairs match up vs. our current P=30T sieve file for the entire n=400K-508K range (minus n=492K-493K). That's it! But let me explain: If there are extra results, ignore them. We just want to make sure all results are there vs. the P=30T file. That way, we know no primes have been missed. That's what I did for filling in the missing results on Benson's range.

Even though Chris started this while at RPS, he was with NPLB when he forwarded us his file. So we may as well load the entire range into the DB, including his stuff starting from n=400K. It'd be a little easier that way. After all, he got us started by providing us his sieve file. The problem will be for you is separating his results out of the n=420259-430378 file because they did not stop right on the n-value. For example, he did some of the n=420259 pairs but not all of them. The 1st post here only rounds off stuff so you'll need to go into the first few posts to find out what is his and what is the next person's results. I got you started by separating out what could easily be separated.


Gary[/quote]
No problem--I'm not doing any kind of matching-up in my import preprocessing. The goal is to get it all in the DB and once there, it should be much easier to write scripts to query for exactly what's missing without needing the crazy matching systems we use now. :smile:

gd_barnes 2010-04-17 05:14

[quote=mdettweiler;212041]No problem--I'm not doing any kind of matching-up in my import preprocessing. The goal is to get it all in the DB and once there, it should be much easier to write scripts to query for exactly what's missing without needing the crazy matching systems we use now. :smile:[/quote]

Only the MANUAL results please! Which of course means all of them for this drive but very few of them for the 5th drive and later.

mdettweiler 2010-04-17 10:53

[quote=gd_barnes;212104]Only the MANUAL results please! Which of course means all of them for this drive but very few of them for the 5th drive and later.[/quote]
Yes, gotcha completely there...see my latest post in the "Loading of manual results into the DB" thread. :smile:

gamer007 2010-04-20 00:25

1 Attachment(s)
508K-509K is complete. No primes. Looks like there's a drought going on.
Now to recrunch 492K-493K.

gamer007 2010-04-23 23:46

1 Attachment(s)
492K-493K is complete (again). :smile: Hopefully the file uploads this time.

Reserving 509K-510K.

gd_barnes 2010-04-24 09:43

[quote=gamer007;212997]492K-493K is complete (again). :smile: Hopefully the file uploads this time.

Reserving 509K-510K.[/quote]

Thank you Gamer for doing that. I'm sorry that happened.

gamer007 2010-04-27 20:34

1 Attachment(s)
509K-510K is complete. No primes.


All times are UTC. The time now is 20:57.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.