Revise that. I'm out of town from early tomorrow, so I'll just go up to 20G.
I've started a new thread, because current sieving thread is in danger of becoming very confusing to the "first time visitors".
I have sieved 1<n<3M with p range 5G - 7G. This yielded 612 factors (all new to the DB), which were distributed according to k as follows
5359 191
19249 77
21181 135
22699 21
33661 124
55459 64
So I guess sieving was incomplete in the low p ranges for these six k.
It's also worth noting that 29 factors were generated where 2.8M<n<3.0M, i.e. factors for k/n pairs which have not yet been assigned for PRP testing.
I'll continue with p range 7G-30G (which should take about a day). If we really can knock out factors for k/n pairs that have not yet been assigned, then this is well worth the effort. We have about 17 days before assigned n>3M. After that this becomes wholly double checking, and therefore much lower priority.
Nuutti, I'll continue submitting these, and then I'll send you the eliminated factors.
Revise that. I'm out of town from early tomorrow, so I'll just go up to 20G.
for less than 3 million, the factoring was done a lot higher before putting the numbers online. so in essence, there are a lot of numbers the server doesn't "know" the factors for because those numbers aren't even online.
unfortunantely, all the numbers you submitted did not do anything. You would have to find factors >500G in that range for them to be factors that haven't been found before.
-Louie
after reading your discussion in the other thread, let me ammend my comments so they might make sense.
for instance, when the 3 - 20 million numbers went online, here's more or less what I did:
1) sieved the numbers up to 1G myself.
2) added all numbers without a factor to a seperate table
3) setup the sieve submitter to save factors and mark the other table complete for each factor
this is different than what i did for n < 3 mill
1) added all the numbers directly from phil charmody's sieve files
2) sieved them myself with computing clusters
3) deleted the numbers as factors were found
-Louie
Hey, what about double checking PRP tests for 0<n<1?
Maybe the previous prime searchers made a mistake.......
I don't think anyone is taking about mistakes here. Double-checking is a part of PRP testing. Because of all the great efforts made by Paul and Phil, we now have sieving tools that are so fast that sieving can be considered as a pre-double check effort.
I would have suggested starting where Louie et al let off, however nuutti chose to start from the beginning again. This has identified some holes in some k ranges, but small in the grand scheme of things.
I'd also like to point out that there would be holes in the 3M<n<20M sieving effort were it not for Louie's great efforts in structuring the DB to allow eliminated factors to be exposed, allowing anyone who wishes to check for holes. This will have significantly improved the integrity of this range.
Mike.
Last edited by MikeH; 02-16-2003 at 04:45 AM.
I agree that a double check of 1<n<3,000,000 makes sense. (especially if somehow a tiny little prime(s) succeded to hide despite everthing for any reason). And I also agree with nuutti about starting from the beginning for the double checking effort. As it's name implies, it is a double check.
Removing one or more k values through double checking (sieve+prp) the n<3,000,000 range would definitely enable us focus our cycles to the remaining k's and boost the project's performance.
Well, errors/mistakes do happen.
Just out of curiosity, I checked for holes when Louie put 0-200G data online (for 3m<n<20m) and found a total of 317 new factors in two holes of 0.45G (0.03G+0.42G) on Feb 4th (mentioned here).
Today, again, since the range is almost finished, I looked through potential holes for the 200G-650G range, and found 7 new factors so far with a sieving effort of 0.10G.
Last edited by Nuri; 02-15-2003 at 08:32 PM.
Louie,
Thanks for your comments. One thing I'd like you to clarify. Or rather two.
1) How is the sieve submitter set up to handle factors for numbers under 3m. Does it delete them or mark them? And is there any difference between the way that numbers in the database are treated as opposed to numbers not in the database. eg. MikeH's 612 factors... Do those numbers get added to the table and marked as done or are they ignored?
And suppose I sieved 1T - 1.01T today and submitted some new factors. Will the sieve submitter handle them properly or throw them out?
2) Should we start a sieving effort for p > 500G. Of course the answer to this question depends on the first one.
Ok, I've finished p range 5G - 20G (so this includes yesterday's numbers). This yielded 1733 factors, which were distributed according to k as follows (with p range in which factors were seen).
5359 606 (5G-20G)
19249 190 (5G-20G)
21181 135 (5G-6G)
22699 141 (6G-20G)
33661 124 (5G-6G)
55459 537 (6G-20G)
Number of factors where 2.8M<n<3.0M: 102
I've tried to figure out whether these high n factors have removed potential PRP testing, but after submission, the "Remaining tests n < 3000000" on the projects stats page did not decrease (other than for a corresponding increase in "Proth tests completed", which is normal).
I'll leave you guys to figure this out, and continue sieving if you wish, I'm now travelling.
Sorry, I missed this post. This is pretty much what I'd guessed. In which case, would it be possible to produce a new sob.dat file for this n range, where only the k/n pairs without known factors are present?Louie said
unfortunantely, all the numbers you submitted did not do anything. You would have to find factors >500G in that range for them to be factors that haven't been found before.
Nuutti, I'm guessing that the core of your sob.dat file didn't originate from the SB DB?
All this said, it probably isn't a bad idea starting from scratch. The 3M<n<20M effort has exceeded 5T (with only a few small holes) in one month. With the current DB structure, everything becomes more traceable in any case.
I have created file from scratch mainly because I had impression that numbers under n =1,000,000 have not sieved very high.
I know that numbers in the range 2,000,000 -> 3,000,000 have sieved very high but because it is simpler to sieve hole range and it does not affect to speed very much I decided to go for
1->3,000,000 from scratch. also different k values have different sieving depths under 2,000,000 (I guess).
Nuutti
I have assumed that Louie have not sieved numbers in the range
n= 1<n<5,000,000 at all because these have checked by previous searchers and projects and only partially between n values 500,000 -> 1,000,000 (depend on k value).
Correct me if I have assumed something wrong.
Yours,
Nuutti
Nuutti,
I would have done it the same way that you did. In fact, I was planning to do so. A "double check" should be as independent of the original way as is possible. I've been worried that the ranges below that done by Louie could have gaps in them. No offence to the people that did it, I'm just worried that something could have "fallen in the cracks". The other thing would be keeping track of the factors for other researchers just as has been done for n > 3000000.
For now I'm working on n > 3000000 and will until there are no gaps for p below 10000000000000, but will be happy to join this effort later.
Joe O
I also plan to partizipate sieving until we reach 10T.
Sieving files 1<n<3,000,000 can be found here :
http://powersum.dnsq.org/doublesieve/
Nuutti
nutti is right. n < 1 mill is not sieved high for most k values.
garo, yeah, if you used nutti's file and sieved a higher range, it would accept and save your results. even if you sieved a low range like MikeH did and duplicated some of my old work, it will still save the factors... it just can't remove any current tests because they are already gone.
for numbers less than 3 mill, if you submit a factor, it will try to mark the number complete, but more than likely, the number was already sieved by me and will not even exist on the server. there is no way for you to know this based on the output of the sieve submitter. in other words, even if you find factors that the server doesn't "know" about, they likely aren't removing tests if they are small factors.
as for weather to start sieving these, i would say it's not as high of priority as the other sieving is still. i think it's cool that a few people are trying it out. go ahead and submit all your factors you want. maybe someone should keep track of what sieving you do sorta like the main thread.
-Louie
I do like this idea. If you don't mind, I'll start sieving the 500-600G range using Nuuti's DoubleSoB file, just to see what the server returns.
I misspoke earlier when i said p > 500G would remove tests about to be prp'ed. I should have said p > 5T. Sorry Halon.
Note, only the upper range (2.5 - 3 mill) have been sieved high. the rest of the ranges have various lower limits.
-Louie
No problem; I'll go ahead and finish 500-510 and see what the server does.
500-510 complete and submitted. 14 results found.
Found one, 505401141031|55459*2^2879038+1, in the pending PRP test list range (though it's probably already been eliminated).
Four others were in the 2M+ range.
Just to make sure: the SoB.dat file from Nuuti's DoubleSieve .zip is the full complement of numbers that's already been sieved prior to being handed out as PRP tests?
EDIT: I've started work on the 20-50G range.
Last edited by Halon50; 02-17-2003 at 04:00 AM.
Can you mail those factors to (also)me. In the first phase I can keep
list about found factors.
Nuutti
If you use my file you are going to do some duplicating but only partially.
Louie used Phil's sieving files when he added numbers to server
(in the first phase) and different k values have different sieving limits. You can check original sieving limits here :
http://fatphil.org/maths/sierpinski/old.html
I also have impression that low n values have not sieved at all.
Proth.exe usually sieves up to 1G-2G.
Later Louie sieved range 2,500,000 -> 3,000,000 deeper.
Nuutti
Nuutti, could you describe the process for creating your file. I am especially interested if you made any assumptions or just let the program do its thing.
Joe O
OK. I have that stuff at home. I will reply when I am there.
Nuutti
Ok, 20-50G complete and submitted. 893 of 894 results were "new".
I'm sorry to say that I had already deleted the 14 factors for 500-510G to get ready for the 20-50G range. The one factor posted a few messages above is all that remains. I'll go ahead and email you the 20-50G range though.
EDIT: The PM system has a limit of 5000 chars, so I'll just attach the result file here.
I got instructions from Paul Jobling how to create SoB.dat using
SoBSieve.exe. I used version 1.06.
Here are instructions :
---klip---
However, there is a *much*
easier way to get SoBSieve to generate a new file.
1) Delete the SoBStatus.dat file.
2) Create a SoB.dat file that contains
<number of ks>
<min n>
<max n>
k=<first k>
k=<second k>
etc.
Then When SoBSieve starts, it will prompt for the range of p. Use pmin=0. It
will then create the SoB.dat file when it has sieved up to pmax.
---klip---
Nuutti
Nuutti,
Thank you.
And now for a few questions
1) You didn't have to give it any n values, just the range?
2) What was your pmax when you created the file?
3) Will the program work for more or less than 12 k? This may be a Paul.Jobling question. It would only become important if we found another prime.
Thanks again.
Joe O
I gave just range like this :
---Sob.dat begins--
12
1
3000000
k=4847
k=5359
k=10223
k=19249
k=21181
k=22699
k=24737
k=27653
k=28433
k=33661
k=55459
k=67607
---SoB.dat ends
I guess that I used p=1,000,000 But when you are using the
latest version you have to give 1 G(I guess), but you can press stop button any time. I used 1.06 so I was able to recreate SoB.dat after every run. if p value is very low then SoB.dat will be very big (at least if p is less than 100).
I am sure that you can try any any number of k values.
You can also edit SoB.dat using text editor. It is a text file.
So if we will find one prime then we can remove that k value from SoB.dat using text editor.
Nuutti
Started 50-110G range. This will probably take a couple days.
Just came back from a vacation, so i didn't have the chance to read everything, but i can't help but wondering, why do you guys want to double check the sieving?
Doesn't it make more sense to continue were sieving left of instead of doing all the work again?
Maybe a few numbers have slipped through the sieving process, but i don't believe it would be many, and in every case, they were already proven composite by prp testing.
I think that purpose is not double check sieving but sieve before double cheking.
The result is some doubling with previous sieving efforts, but because
current software works differently (I guess that number of k values does not matter a lot) it doesn not affect to the speed.
There are some k values that have not sieved at all or very little.
and when we get higher in p values there will be more unsieved stuff. like p=100G.
Yours,
Nuutti
Thnks, that makes more sense, but i think i read that Louie tested numbers > 2.5M to 5T , and there is no need to test numbers below 1M that deep (better spend your time prp-ing)
Smh is correct, of course, there is no need to sieve the numbers below 1M very deeply. However, since the range 1M-3M was sieved less than optimally (with current software unavailable at that time), why sieve just 1M-3M when sieving 0M-3M takes only 22% more time?
How deep numbers under 1M should sieved ?
I wasn't originally aware that louie have tested range 2,5 M -> 3,0 million that deep.
square(2.5)=1.58
square(3)=1.73
So if we have unneededly tested that range it means that
it is 9,5% slower to test bigger range than smaller one.
Not good, but not very very bad either.
And there does not seem to be very accurate information
about how deep every k is sieved and what n ranges
have sieved deeper and what n ranges are sieved less deep and what n ranges have not sieved at all.
most of previous sieving limits are so low that with current
software we reach most of them in days.
I know that you have some of this information but unfortunately
you were out of town. My purpose was wait until you are back and when we have reached 10T in normal sieving, but then some one started asking sieving file for 1->3,000,000 n values and because I had one I posted it to online.
Nuutti
Louie wrote earlier in this thread:
I must have some data for K=4847 which should be sieved upto 1T. I don't know if there is a program that can convert old NewPGen data into SoBSieve data, but it shouldn't be to hard to write a simple conversion program.I misspoke earlier when i said p > 500G would remove tests about to be prp'ed. I should have said p > 5T. Sorry Halon.
Note, only the upper range (2.5 - 3 mill) have been sieved high. the rest of the ranges have various lower limits.
Other sieve files to various depth should be available too.
But maybe you are right, and it's easiest to just let the sieve run.
BTW, i'm not sure if residues for all tests before SoB are available. And a double check of course needs a matching pairs of residues.
Are there any plans yet, within or outside SoB to start prp-ing for a double check? The first couple of N=100K's should be done fairly quickly
Just thought that I'd gather the following information together:
0 - 5 Nuutti [complete]
5 - 20 MikeH [complete]
20 - 110 Halon50 [complete]
500 - 510 Halon50 [complete]
5000 - 6000 Joe O
Are there any others?
Last edited by Joe O; 02-20-2003 at 10:54 AM.
Joe O
I just started 5500 - 6000
I just started 5000 - 5500
I need a faster NbeGone!
Last edited by Joe O; 02-20-2003 at 10:56 AM.
Joe O
50-110G finished. 752 new factors, no duplicates.
Joe O, for those high ranges, I believe SoBSieve is a lot faster. NbeGone is faster for the low ranges.
Thanks for the info! I'm currently running those ranges on an AMD K6-2/500 and an AMD K6-III/400. The current versions (1.22 and above) of SOBSieve will not run on them. I'll have to find a version prior to 1.22 and see if it works. Thanks again.
Joe O
Could you please post SoBSieve v.1.06 here?
The oldest version I have is v.1.10, and it doesn't
allow me to create my own SoB.dat file
Posting Permissions
