|
Sierp base 33 complete to n=25K; 3 k's remaining
Sierp base 37 complete to n=25K; 4 k's remaining See k's and primes on the web pages. Both bases are now unreserved. |
[quote=Flatlander;156769]Riesel base 95 tested to 10k. (No reservation.) No more testing.
24 ks remaining. I believe k=324 can be removed. Odd n has factors of 7,13,37 or 229 for as far as I could test. I think other ks can remain but I was having problems with the factoring website. The reason I am testing without making reservations is because it's difficult to tell which bases are hard until they are part tested. I regularly check this thread to make sure there is no repetition of work. I am trying to push Riesel base 39 to at least n=1000.[/quote] Good analogy. That is correct that k=324 can be eliminated. The official covering set for odd-n is {7 13 229}. 37 is not needed. This is a most unusual situation. So far, there is only one other Riesel k and base < 100 where algebraic factors on even-n combine with a covering set of MORE than one factor on odd-n to eliminate a k. That is 1369*30^n-1. Gary |
[quote=Flatlander;156769]
I am trying to push Riesel base 39 to at least n=1000.[/quote] Also Riesel base 58. (Can't stand those gaps. lol) |
Reserving Sierp. base 33 for sieving to n=100K. :smile:
I was thinking that this would be an interesting base to run through PRPnet--we'd probably have it done in a very short time, and with only 3 k's remaining, there is a very good chance of proving this base in a short amount of time. What does everyone think about this? (Note: even if we don't do it through PRPnet, I still plan to complete the sieving, which I started earlier today and is proceeding to finish probably sometime today or tomorrow. :smile:) |
[QUOTE=mdettweiler;157667]Reserving Sierp. base 33 for sieving to n=100K. :smile:
I was thinking that this would be an interesting base to run through PRPnet--we'd probably have it done in a very short time, and with only 3 k's remaining, there is a very good chance of proving this base in a short amount of time. What does everyone think about this? (Note: even if we don't do it through PRPnet, I still plan to complete the sieving, which I started earlier today and is proceeding to finish probably sometime today or tomorrow. :smile:)[/QUOTE] There are other bases with a single k left that have proven to be stubborn for n > 100K. The k for this base could be just as nasty. My personal opinion is that we should try to get all bases to n = 100K and then throw everything left into PRPNet, with the exception of the bases that have more than a few dozen k left. |
I'm in favor of a combination of your guy's suggestions and part of it is something that I alluded to in another thread. At some point in the near future, for bases <= 100 that have not already been done, do the following initial processing:
1. Test all bases <= 100 that will clearly have <= 35 k's remaining at n=10K. 2. For bases in #1 that have 8-15 k's remaining at n=10K, test them to n=25K. 3. For bases in #1 that have 1-7 k's remaining at n=10K, test them to n=100K. After completing the above, do the following final processing: 1. Put all bases that have 1-3 k's remaining into group 1. I'll rate each of these bases as having a > 50% chance of being proven in the next 10 years. 2. Put all bases that have 4-7 k's remaining into group 2. I'll rate these as having a 2-50% chance of being proven in the next 10 years. 3. Put all bases remaining that DID meet the criteria in #1 of the initial process but did NOT meet the criteria in #2 or #3 of the intial process or #1 or #2 of the final process into group 3. Most will have 8-35 k's remaining at either n=10K or 25K. I rate these as having < 2% chance of being proven in the next 10 years. 4. Sieve all of the above together as much as can be reasonably done. I don't know of a way to sieve multiple bases at once. Perhaps it can be done. 5. Put each group into a separate PRPnet server and let 'er rip. Group 3 may need to be broken down a little further as it will have a lot of bases and k's and will have been tested to a lower limit. This will give us a good chance at proving a few bases, will also bring some tougher but not virtually impossible bases to a point at which future generations of prime searchers could reasonably prove them, especially with continued software improvements like Phrot and PRPnet, :smile: and will knock out many k's on the virtually impossible bases. Personally, I can't get too excited about bases > 100 and don't recommend them for PRPnet. Actually, it took me quite a while to warm up to anything for bases > 32. Only the math of finding patterns in the partial algebraic factors got me more interested in them. Bases > 100 are great for individual efforts but are simply too hard to find primes for in a team effort because the base is so high, leaving few candidates to test within any specific numerical length range. Gary |
[quote=mdettweiler;157667]Reserving Sierp. base 33 for sieving to n=100K. :smile:
I was thinking that this would be an interesting base to run through PRPnet--we'd probably have it done in a very short time, and with only 3 k's remaining, there is a very good chance of proving this base in a short amount of time. What does everyone think about this? (Note: even if we don't do it through PRPnet, I still plan to complete the sieving, which I started earlier today and is proceeding to finish probably sometime today or tomorrow. :smile:)[/quote] I rate the odds at < 5% that this base will be proven in a "short" amount of time. By short, I mean < 1 year running a full quad 24x7. If we can focus 5-10 total quads from the team 24x7, we might have a 50-50 shot at proving it in < 1 year, but that's just a guess. I'd have to look at the specific weights of the k's to get a better estimate. If you can post your sieve file here or let me know how many testing candidates remain for each k, I can get a better estimate. I sense that the tremendous difficulty in finding the final primes on these bases is still lost on many people here. Base 33 is a very high base compared to bases < 10. A few questions: What do you mean by we'll have it "done" in a short amount of time? Do you mean proven or just the sieved n-range completely tested? Proven?...highly unlikely. Sieved n-range completely primality tested?...sure. I think that sieving n=25K-100K is a good range to start with and can probably be sieved to an optimal depth within 3 days. But the final prime on this base is likely to be far greater than n=100K so will probably need a lot more work. This base would fall in #3 of the 'initial process' that I spoke of in the last post. In other words, let's get it tested to n=100K and then we can consider putting the k's that remain in the 'group 1' team PRPnet server for higher n-ranges after getting those sieved. Group 1 will be the "> 50% chance provable in the next 10 years" bases. Be careful about thinking that a base can be proven in a "short" amount of time when testing has already reached n=25K with multiple k's remaining, even with just 2 or 3. Sometimes it happens but far more often then not, it does not. Gary |
@Gary regarding the overall plan you presented: okay, that sounds good. :smile: One thing I'm sort of confused about, though: are you saying that we should only put them into PRPnet for n>100K? Because PRPnet can handle stuff much lower than that, and it would be a waste to not utilize it for lower stuff because of an arbitrary limit. :smile:
Regarding Sierp. base 33: Ah, I see what you mean. Yeah, I guess you're right about it not being likely to be proven any time soon--I guess I just saw the three k's remaining at n=25K for a somewhat low base and figured "hey, looky, we can prove this one!" :smile: Anyway, regardless of when it's likely to be proven, I'll still continue the sieving and will probably reserve it to PRP to n=100K myself. Who knows--maybe I'll hit the jackpot and knock out all three k's before 100K. :wink: Max :smile: |
Riesel base 52 has been tested to n=1k. 664 ks left.
I'm sieving to n=10k. |
Sierp. base 33 has now completed sieving for n=25K-100K. :smile: I'll now reserve this base to PRP test for the same range.
|
[quote=mdettweiler;157780]@Gary regarding the overall plan you presented: okay, that sounds good. :smile: One thing I'm sort of confused about, though: are you saying that we should only put them into PRPnet for n>100K? Because PRPnet can handle stuff much lower than that, and it would be a waste to not utilize it for lower stuff because of an arbitrary limit. :smile:
Max :smile:[/quote] No, not at all. Check out group 3. We'll have plenty of n>=10K and n>=25K tests for the PRPnet servers for bases where there are up to 35 k's remaining. What I'm saying is that for the bases that are close to being proven, we should individually test them to n=100K before putting them into a team "proving" server, i.e. the group 1 server. What I brought up there was just a brain dump that keeps us from getting overly complex with the servers. Imagine if you ran a team server for base 33 and then someone else wanted to do one for base 37 because it only has 4 k's remaining at n=25K, and then another because it has only 2 k's remaining, etc. We'd have servers all over the place. The idea of the group 1 server is to put some LONG tests in it for perhaps a total of ~40 k's on ~20 bases, i.e. bases with 1-3 k's remaining at n=100K or higher. (Actually by the time we get it going, many bases < 32 that have 1-3 k's remaining will be at n=250K or higher so we may want a special 4th group server for them.) Regardless, as a brain dump, nothing is set in stone there. It was just me throwing out some generalities about how to load the servers without going too overboard with them. Keep in mind that as an admin here, I can't stop anyone from doing anything. I can only attempt to coordinate efforts and keep them from being overly complex. If people strongly prefer having one server for each base for n>=10K or 25K, then who am I to stop them? If that is the case, I'll do my best to make things the least complex that they can be. Everyone, please give your opinions on how to divide up the bases for loading into a limited # of PRPnet servers; perhaps 2-5 of them. In asking for the opinions, please note that existing team drives are completely separate then the aforementioned "group" servers. Good luck with base 33! I have this funny feeling that you'll find 2 k's with primes for n=25K-100K and that we'll have, yet again, a base with one k remaining. Personally, I was glad when k=36 fell at n=~23.6K. k's that are perfect squares are frequently problem children and it gave me hope that the base could be proven in a reasonable amount of time. Edit: Feel free to set up personal PRPnet servers for yourself or others on my machines. If that one machine has enough servers on it right now, go ahead and use another. I don't count those as "official CRUS" team or group servers because they are only a temporary way to help automate one's personal reservations. Gary |
[quote=gd_barnes;158035]No, not at all. Check out group 3. We'll have plenty of n>=10K and n>=25K tests for the PRPnet servers for bases where there are up to 35 k's remaining. What I'm saying is that for the bases that are close to being proven, we should individually test them to n=100K before putting them into a team "proving" server, i.e. the group 1 server.
What I brought up there was just a brain dump that keeps us from getting overly complex with the servers. Imagine if you ran a team server for base 33 and then someone else wanted to do one for base 37 because it only has 4 k's remaining at n=25K, and then another because it has only 2 k's remaining, etc. We'd have servers all over the place. The idea of the group 1 server is to put some LONG tests in it for perhaps a total of ~40 k's on ~20 bases, i.e. bases with 1-3 k's remaining at n=100K or higher. (Actually by the time we get it going, many bases < 32 that have 1-3 k's remaining will be at n=250K or higher so we may want a special 4th group server for them.) Regardless, as a brain dump, nothing is set in stone there. It was just me throwing out some generalities about how to load the servers without going too overboard with them. Keep in mind that as an admin here, I can't stop anyone from doing anything. I can only attempt to coordinate efforts and keep them from being overly complex. If people strongly prefer having one server for each base for n>=10K or 25K, then who am I to stop them? If that is the case, I'll do my best to make things the least complex that they can be. Everyone, please give your opinions on how to divide up the bases for loading into a limited # of PRPnet servers; perhaps 2-5 of them. In asking for the opinions, please note that existing team drives are completely separate then the aforementioned "group" servers. Good luck with base 33! I have this funny feeling that you'll find 2 k's with primes for n=25K-100K and that we'll have, yet again, a base with one k remaining. Personally, I was glad when k=36 fell at n=~23.6K. k's that are perfect squares are frequently problem children and it gave me hope that the base could be proven in a reasonable amount of time. Edit: Feel free to set up personal PRPnet servers for yourself or others on my machines. If that one machine has enough servers on it right now, go ahead and use another. I don't count those as "official CRUS" team or group servers because they are only a temporary way to help automate one's personal reservations. Gary[/quote] Ah, okay, that makes sense now--sounds like a pretty good plan to me. :smile: |
I've have no way of knowing if this is easy, hard or something in between and I probably won't understand the maths anyway but:
While fiddling with Riesel base 39, I found lots of ks that have algebraic/trivial/whatever factors for odd and even n and can be removed. These form a pattern. Who can tell me that pattern and show me why it exists? (No cheating to get the pattern like I had to!) edit: I don't mean k = = 1 mod 2 and k = = 1 mod 19. These weren't tested. (Some ks in the pattern above were excluded because of this.) |
[quote=Flatlander;158561]I've have no way of knowing if this is easy, hard or something in between and I probably won't understand the maths anyway but:
While fiddling with Riesel base 39, I found lots of ks that have algebraic/trivial/whatever factors for odd and even n and can be removed. These form a pattern. Who can tell me that pattern and show me why it exists? (No cheating to get the pattern like I had to!) edit: I don't mean k = = 1 mod 2 and k = = 1 mod 19. These weren't tested. (Some ks in the pattern above were excluded because of this.)[/quote] I've done no factoring using Alpertron's site nor testing on this base but if you look at [URL="http://www.mersenneforum.org/showpost.php?p=153696&postcount=1"]this thread[/URL] by me, it states the following for all b == 4 mod 5 on the Riesel side: [quote] algebraic factors on even-n combine with a numeric factor on odd-n in the following scenario: k=m^2 and m==(2 or 3 mod 5) Factors to: for even-n, let n=2q: (m*b^q-1)*(m*b^q+1) -and- odd-n: factor of 5 [/quote] Therefore, I suspect that the following k's have algebraic factors on even-n that combine with a factor of 5 on odd-n to eliminate them: k=2^2 = 4 k=8^2 = 64 k=12^2 = 144 (note k=18^2 = 324 is not considered because k == 1 mod 19 and so all n-values have a trivial factor of 19) k=22^2 = 484 k= 28^2 = 784 (etc. if k not == 1 mod 19) Note that we don't include k=3^2, 7^2, 13^2, 17^2, etc. in this algebraic factor analysis because they are odd-k with a trivial factor of 2 on all n-values. But if you look closely at them and discount the factor of 2, you'll see that they still have the same pattern of algebraic factors on even-n and a factor of 5 on odd-n. This situation is why I posted that thread. If the above is correct here, it will show that I have generallized the factors correctly (for this case anyway) in the other thread. :smile: Gary |
[quote=gd_barnes;158626]...
k=2^2 = 4 k=8^2 = 64 k=12^2 = 144 (note k=18^2 = 324 is not considered because k == 1 mod 19 and so all n-values have a trivial factor of 19) k=22^2 = 484 k= 28^2 = 784 (etc. if k not == 1 mod 19) :smile: Gary[/quote] Perfecto!!! |
Status sierpinski base 63:
all k<=10.2M has been tested to n=1000. Approximately 55,000 k's remain for further testing. Also I expect this conjecture to be proven with n<=1,000,000,000 as the highest n-value. My current statistical prediction suggests that there should remain 220 k's approximately at n=1,024,000. The prediction for n=25000 is approximately 10,000 k's remaining. Also on a side note this conjecture should yield at least 439 Megaprimes :smile: Regards KEP |
[quote=KEP;158710]Status sierpinski base 63:
all k<=10.2M has been tested to n=1000. Approximately 55,000 k's remain for further testing. Also I expect this conjecture to be proven with n<=1,000,000,000 as the highest n-value. My current statistical prediction suggests that there should remain 220 k's approximately at n=1,024,000. The prediction for n=25000 is approximately 10,000 k's remaining. Also on a side note this conjecture should yield at least 439 Megaprimes :smile: Regards KEP[/quote] The conjecture is 37565868; 3.7 times as high as what you have tested hence there should be nearly 200,000 k's remaining at n=1000 when the entire k-range is tested. So you're telling me that base as large as 63, even though it's a 2^q-1 base, can drop 95% of its k's remaining between n=1000 and n=25000? This I have to see. Can you show how you came up with your calculations? Base 31, a very prime base like all 2^q-1 bases, has been dropping ~40-45% of it's k's for every doubling of the n-range up to n=10K; 1934 k's now remain. For base 63 to do what you're saying, it would have to continue dropping nearly half of it's k's for each doubleing of the n-range. That would be most unusual for a base so high to continue up to n=25000 and for it to be even more prime than base 31. What I've found is that my prior calculations aren't quite accurate. I had assumed a consistent percentage reduction in k's with a set multiplier increase in n-value. That is not quite true. As you go higher, more low-weight k's remain; hence the percentage drops also. So where you might see a 50% drop in k's remaining from n=10K-20K, you might only see a 45% drop from 20K-40K and a 40% drop from 40K-80K. For this reason, I expect that base 63 won't be proven until n>1e12 or much higher. Gary |
[QUOTE=gd_barnes;158803]The conjecture is 37565868; 3.7 times as high as what you have tested hence there should be nearly 200,000 k's remaining at n=1000 when the entire k-range is tested. So you're telling me that base as large as 63, even though it's a 2^q-1 base, can drop 95% of its k's remaining between n=1000 and n=25000?
This I have to see. Can you show how you came up with your calculations? Base 31, a very prime base like all 2^q-1 bases, has been dropping ~40-45% of it's k's for every doubling of the n-range up to n=10K; 1934 k's now remain. For base 63 to do what you're saying, it would have to continue dropping nearly half of it's k's for each doubleing of the n-range. That would be most unusual for a base so high to continue up to n=25000 and for it to be even more prime than base 31. What I've found is that my prior calculations aren't quite accurate. I had assumed a consistent percentage reduction in k's with a set multiplier increase in n-value. That is not quite true. As you go higher, more low-weight k's remain; hence the percentage drops also. So where you might see a 50% drop in k's remaining from n=10K-20K, you might only see a 45% drop from 20K-40K and a 40% drop from 40K-80K. For this reason, I expect that base 63 won't be proven until n>1e12 or much higher. Gary[/QUOTE] Well the 55000 k's remaining I came up to using a spreadsheet where I removed every k mod 31 = 30. This "operation" removed ~3/4 of all candidates showing as remaining at n<=1,000 in the NOprimes.out file. My prediction for n<=1,000,000,000 I came up with using a 50% reduction, since I remember that you suggested this regarding the base 3 conjecture, as a reasonable reduction. I might have been wrong on this estimate, however the future will only really be able to tell. For my n<=1,000,000,000 prediction I used an estimate of 10,000 k's remaining at n=25K and 225,000 k's remaining at n<=1K. Both calculations had <1 k remaining for n<=1,000,000,000 Here is the top n's for each calculation: 225K k's remaining: n<=943.372.658 10K k's remaining: n<=737.009.889 I guess you may be right Gary that the reduction will not be as steady around 50%, so we just has to leave it to the future to prove this conjecture to. On a side note, riesel base 3 k=3677878 was on my dual core testing around 343K as of yesterday. However I hoped to be able to gain some progress and some speed using Proth. But sadly proth version 0.65 was 10% longer to do a single test compared to LLR, so no gain using proth, just really hopes that Proth can do faster than LLR once we start testing Sierp base 63 higher than n<=25K or whenever I decide to abandone this conjecture :smile: Regards KEP |
[quote=KEP;158824]On a side note, riesel base 3 k=3677878 was on my dual core testing around 343K as of yesterday. However I hoped to be able to gain some progress and some speed using Proth. But sadly proth version 0.65 was 10% longer to do a single test compared to LLR, so no gain using proth, just really hopes that Proth can do faster than LLR once we start testing Sierp base 63 higher than n<=25K or whenever I decide to abandone this conjecture :smile:[/quote]
Hmm...were you using *Phrot* or *Proth* for your tests? Because whereas Phrot is usually faster than LLR, the much older Proth.exe program is waaaaaaay slower. :smile: |
[QUOTE=mdettweiler;158833]Hmm...were you using *Phrot* or *Proth* for your tests? Because whereas Phrot is usually faster than LLR, the much older Proth.exe program is waaaaaaay slower. :smile:[/QUOTE]
I was using Phrot version 0.65 published at Geoffs site. It was actually using ~2700 seconds per test compared to LLRs ~2500 seconds per test, so it was a loss of speed of approximately (give and take) 10% per test for k=3677878 for Riesel base 3. I suspects that it may have something to do with the FFT boundrys, since the the k value were transformed to several trillion (if my memory doesen't play me a trick) :smile: On the good side only one test were carried out using phrot version 0.65 before switching back to LLR version 3.7.1 so only a small amount of time was waisted. Also I actually obtained an LLR residual, so the tests weren't completely a waist after all. Regards KEP |
[quote=KEP;158847]I was using Phrot version 0.65 published at Geoffs site. It was actually using ~2700 seconds per test compared to LLRs ~2500 seconds per test, so it was a loss of speed of approximately (give and take) 10% per test for k=3677878 for Riesel base 3. I suspects that it may have something to do with the FFT boundrys, since the the k value were transformed to several trillion (if my memory doesen't play me a trick) :smile:
On the good side only one test were carried out using phrot version 0.65 before switching back to LLR version 3.7.1 so only a small amount of time was waisted. Also I actually obtained an LLR residual, so the tests weren't completely a waist after all. Regards KEP[/quote] Hmm...that is weird. I'd suggest posting about it in the [url=http://www.mersenneforum.org/showthread.php?t=11264]Phrot Announcments[/url] thread, so Rogue can take a look at it and see what may be causing this slowdown. |
[QUOTE=mdettweiler;158848]Hmm...that is weird. I'd suggest posting about it in the [url=http://www.mersenneforum.org/showthread.php?t=11264]Phrot Announcments[/url] thread, so Rogue can take a look at it and see what may be causing this slowdown.[/QUOTE]
It might have something to do with Geoff's build. If you can give me a couple of examples of where LLR is faster, I can investigate. |
I have experienced the same thing. For my current "squares" test of both Riesel and Sierp base 3, I am using LLR for that reason.
I have found Phrot to be slower for base 3 but faster for all the other bases that I have tested that are not powers of 2. Kenneth, there is a BIG different between Proth and Phrot! Gary |
[quote=KEP;158824]Well the 55000 k's remaining I came up to using a spreadsheet where I removed every k mod 31 = 30. This "operation" removed ~3/4 of all candidates showing as remaining at n<=1,000 in the NOprimes.out file.
My prediction for n<=1,000,000,000 I came up with using a 50% reduction, since I remember that you suggested this regarding the base 3 conjecture, as a reasonable reduction. I might have been wrong on this estimate, however the future will only really be able to tell. For my n<=1,000,000,000 prediction I used an estimate of 10,000 k's remaining at n=25K and 225,000 k's remaining at n<=1K. Both calculations had <1 k remaining for n<=1,000,000,000 Here is the top n's for each calculation: 225K k's remaining: n<=943.372.658 10K k's remaining: n<=737.009.889 I guess you may be right Gary that the reduction will not be as steady around 50%, so we just has to leave it to the future to prove this conjecture to. On a side note, riesel base 3 k=3677878 was on my dual core testing around 343K as of yesterday. However I hoped to be able to gain some progress and some speed using Proth. But sadly proth version 0.65 was 10% longer to do a single test compared to LLR, so no gain using proth, just really hopes that Proth can do faster than LLR once we start testing Sierp base 63 higher than n<=25K or whenever I decide to abandone this conjecture :smile: Regards KEP[/quote] Base 63 is not base 3. The 50% reduction method was ONLY for base 3. Each base has it's own percentage reduction. (Actually, for base 3, it's closer to 60% for n=25K-100K but I used 50% to make the example easy.) You need to use the specific reduction that is applicable to your base. For most higher bases, it's closer to 20% although for a 2^q-1 base 63, it might be 40-50%. I can tell you for your base 255 that I am just now completing to n=5000, it is slightly under 20% and that is very high for such a huge base! Many bases > 200 will be 10% or less. Here's what you need to do: 1. Look at the # of k's remaining at n=500 after removing all k==30 mod 31. 2. Look at the # of k's remaining at n=1000 after removing all k==30 mod 31. See what the percentage reduction in k's is there and then you'll have a reasonable estimate for base 63. BTW, the drop in the percentage reduction is quite small especially at the low n-ranges. For instance, if you find that you drop 40% of remaining k's for n=500-1000, you might drop 39% of remaining k's for n=1000-2000, 38% for n=2000-4000, etc. It's only as you get down to very few k's remaining that the percentage drops greatly upon each doubling of then-range. That's why finding primes for the last 1-2 k's is frequently so difficult...frequently because they are much lower weight than any of the rest. For base 63, we might have 2 k's remaining at n=10^12 but not find a prime on them for 3 more powers of 10 up to n=10^15. (Highly possible; not that we're likely to ever know. lol) Gary |
Kenneth,
I ran a quickie test on Sierp base 63 for k<2000 up to n=3200. A good percentage reduction in k's remaining for every doubling of the n-value on base 63 is ~37%. With base 3 at ~60% and base 31 at ~48-50%, that is about what I would expect for base 63, another very prime 2^q-1 base. Gary |
@Gary:
Wow that was a lot of very insightfull answers. I'll try in a couple of months, to find a way to put the amount of candidates removed and remaining in to a spreadsheet for following n's: n=1 n=2 n=3 to 4 n=5 to 8 n=9 to 16 n=17 to 32 n=33 to 64 n=65 to 128 n=129 to 256 n=257 to 512 By finding out how many candidates is removed and remaining for each doubeling in n, eventually a more accurate prediction will be able to be projectured for Sierp. base 63. However as you state, none of us is likely to ever know if our predictions for a highest completion n, is ever correct estimated. But it will be a couple of months before I can make this kind of prediction. Now I'll go dig up the n value for base 3 to Rogue, so he can start his investigation :smile: Kenneth! |
[QUOTE=rogue;158857]It might have something to do with Geoff's build. If you can give me a couple of examples of where LLR is faster, I can investigate.[/QUOTE]
@Rogue: LLR test: 3677878*3^342573-1 (2580.474 s) Phrot test: 3677878*3^342656-1 (2751.30 s) As you can see Geoff, though there is only an increase in n by 83 the time increases using Phrot with almost 171 seconds. The next test and a bit higher, using LLR is still faster than the single mentioned Phrot test. @Gary: I know that there is a difference between Phrot and Proth. Unfortunantly I've had a hard time learning to spell to Phrot since I find it much easier for some reasons to spell Proth everytime I'm actually talking about Phrot :smile: But thanks for pointing out the differences, since I've actually done some testings with Proth, however I didn't seem to be able to make it work so I abandoned it again, however if Phrot appears to be faster at base 63 on sierp side, then I'll use it for n>1000 :smile: Regards Kenneth |
[QUOTE=KEP;159008]@Rogue:
LLR test: 3677878*3^342573-1 (2580.474 s) Phrot test: 3677878*3^342656-1 (2751.30 s) [/QUOTE] Can you tell me what phrot says WRT the line "Actually Testing"? |
[QUOTE=rogue;159033]Can you tell me what phrot says WRT the line "Actually Testing"?[/QUOTE]
Input 3677878*3^342656-1 : Actually testing 24130557558*531441^28554-1 (witness =3 28556/57344 limbs) My own suggestion as to why it takes so considerablely longer to do a Phrot test compared to an LLR test may be that it relys to or has something to do with the k value. A k value of 24G must also have a high FFT boundry, so therefor it will be slower to test. |
The problem of being slower using phrot appears to happen for base 63 also
k tested: 888 n tested: 25000 LLR time: 888*63^25000+1 is not prime. RES64: 9FE7B73F28056F20. OLD64: CD7C598FA045F9E4 Time: 127.730 sec. Phrot time: Input 888*63^25000+1 is composite LLR64=9fe7b73f28056f20. (t=133.40s) Input 888*63^25000+1 : Actually testing 55944*250047^8333+1 (witness=3 8334/184 32 limbs) Hope it helps. Kenneth |
What CPU are you running this on? Is this Windows or Linux?
On a Core 2 Duo, your examples took about 1500 seconds with phrot and about 1600 seconds with LLR. |
[QUOTE=rogue;159052]What CPU are you running this on? Is this Windows or Linux?
On a Core 2 Duo, your examples took about 1500 seconds with phrot and about 1600 seconds with LLR.[/QUOTE] Running on Windows. Base 3 tests were carried out on a Core 2 Duo while the base 63 tests were done on a Q6600 quad core 2.4 GHz. Hope it helps! |
1 Attachment(s)
Sierp. base 33 k=766 is now complete to n=100K. No primes. :sad: Results are attached.
Now proceeding with k=1678 and k=1818... |
I wonder if it has anything to with running a 64-bit machine and O.S.
I run 64-bit Linux Ubuntu version 8.04 on all of my quads and only have a couple of slower 32-bit Window's machines. On base 12, Phrot, it is a full 40% faster than LLR on 64-bit Linux for exponents n>200K. I was exstatic when I first tested it. But when I've tried either base 3 or any base on a 32-bit Windows machine, LLR is usually faster my a marginal amount like what Kenneth has experienced. Gary |
[quote=KEP;159007]@Gary:
Wow that was a lot of very insightfull answers. I'll try in a couple of months, to find a way to put the amount of candidates removed and remaining in to a spreadsheet for following n's: n=1 n=2 n=3 to 4 n=5 to 8 n=9 to 16 n=17 to 32 n=33 to 64 n=65 to 128 n=129 to 256 n=257 to 512 By finding out how many candidates is removed and remaining for each doubeling in n, eventually a more accurate prediction will be able to be projectured for Sierp. base 63. However as you state, none of us is likely to ever know if our predictions for a highest completion n, is ever correct estimated. But it will be a couple of months before I can make this kind of prediction. Now I'll go dig up the n value for base 3 to Rogue, so he can start his investigation :smile: Kenneth![/quote] You don't need to take a couple of months to do it. Do it like I did. Just take a small subset like k<10000 and run it up to n=1000. (I did k<2000.) You don't have to run 30M+ k's to get a good estimate. :smile: The 37% that I got is a little lower than what I was seeing at n=1000 (~39-40%) for k<2000 but the higher k's and n's have a lower % so it's best to estimate a little lower than what you see at the low k and n-ranges. BTW, I prefer to use: n=100-200 n=200-400 n=400-800 n=800-1600 etc. It's too big of a pain to deal with so many k's and primes starting from n=1 and you don't need to do that to come up with a reasonable estimate. Gary |
[QUOTE=gd_barnes;159100]You don't need to take a couple of months to do it. Do it like I did. Just take a small subset like k<10000 and run it up to n=1000. (I did k<2000.) You don't have to run 30M+ k's to get a good estimate. :smile:
The 37% that I got is a little lower than what I was seeing at n=1000 (~39-40%) for k<2000 but the higher k's and n's have a lower % so it's best to estimate a little lower than what you see at the low k and n-ranges. BTW, I prefer to use: n=100-200 n=200-400 n=400-800 n=800-1600 etc. It's too big of a pain to deal with so many k's and primes starting from n=1 and you don't need to do that to come up with a reasonable estimate. Gary[/QUOTE] Here is the removal stats for the k's <=1M (483871 candidates): n k's rem. primes k's rem. % removed 1 483871 103654 380217 21,4% 2 380217 67082 313135 17,6% 4 313135 81042 232093 25,9% 8 232093 75792 156301 32,7% 16 156301 57897 98404 37,0% 32 98404 38437 59967 39,1% 64 59967 23771 36196 39,6% 128 36196 14346 21850 39,6% 256 21850 8553 13297 39,1% 512 13297 5039 8258 37,9% Hope this can help someone come up with a good prediction :smile: Kenneth |
[quote=gd_barnes;159099]But when I've tried either base 3 or any base on a 32-bit Windows machine, LLR is usually faster my a marginal amount like what Kenneth has experienced.[/quote]
Hmm...that's odd. What version of Phrot are you using on 32-bit Windows? |
In my testing phrot for these numbers is faster on P4 and Core 2 Duo. What CPUs are you running on? Also, IIRC you are using Geoff's build. It might be slower then the CygWin build.
|
[QUOTE=rogue;159153]In my testing phrot for these numbers is faster on P4 and Core 2 Duo. What CPUs are you running on? Also, IIRC you are using Geoff's build. It might be slower then the CygWin build.[/QUOTE]
I'm using Geoff's build, but on my Q6600 2.4 GHz Phrot was actually also slower than LLR for Sierp. base 63. Not sure if it has something to do with the build by Geoff but untill someone can come up with a .exe build that is actually faster than LLR then I'm for a fact not going to use Phrot on any of my testings. Thanks for your investigative efforts. Hope you come up with a solution eventually because it would be nice to gain some use of the 40% speed increase compared to LLR that everyone is in fact talking about :smile: Kenneth! |
[quote=rogue;159153]In my testing phrot for these numbers is faster on P4 and Core 2 Duo. What CPUs are you running on? Also, IIRC you are using Geoff's build. It might be slower then the CygWin build.[/quote]
I have used Geoff's Linux builds for all the recent Phrot versions (I didn't test his Windows builds) and they seem to be as fast as they're supposed to be. :huh: Possibly this is a problem limited to Geoff's non-Cygwin Windows build? KEP, have you tried using Rogue's Windows build? |
1 Attachment(s)
[QUOTE=mdettweiler;159162]I have used Geoff's Linux builds for all the recent Phrot versions (I didn't test his Windows builds) and they seem to be as fast as they're supposed to be. :huh:
Possibly this is a problem limited to Geoff's non-Cygwin Windows build? KEP, have you tried using Rogue's Windows build?[/QUOTE] I've attached a build that I have made with MinGW. See if there is any difference. Of note, it might be that phrot is running at a lower priority, thus is not getting as much CPU as LLR. BTW, the speed increase of phrot over LLR is related to the base. Some base are 20% faster with phrot, others only a few percent. |
[QUOTE=mdettweiler;159162]I have used Geoff's Linux builds for all the recent Phrot versions (I didn't test his Windows builds) and they seem to be as fast as they're supposed to be. :huh:
Possibly this is a problem limited to Geoff's non-Cygwin Windows build? KEP, have you tried using Rogue's Windows build?[/QUOTE] No haven't tried Rogues windows build. However I may look into it tomorrow since it is getting kind of late here where I'm seated :smile: Thanks for all your help to both you and Rogue! Hope the version Rogue has attached is actually faster because even a few percent increase in speed is going to make a huge difference in the long run :smile: KEP EDIT: For base 63 n=25000 k=888 the attached Phrot version using MingW made no difference on the Q6600 32-bit Windows Vista. It used 12 seconds more compared to LLR to do the test :( |
There is some throttling in phrot that prevents it from being more aggressive, which could trigger maxerr. Some of that throttling appears to no longer be necessary as there was a bug (integer overflow) that has been fixed. I can eliminate that throttling, but it will help only with smaller bases. With these changes I think that bases > 50 will probably be faster with LLR. I need to do some more testing before I can release a build.
|
[quote=mdettweiler;159148]Hmm...that's odd. What version of Phrot are you using on 32-bit Windows?[/quote]
64-bit version that was the most recent about a month ago. Guys, I've tried downloading the newest version Phrot, both 32-bit and 64-bit, several times for my 32-bit Windows machines. Every time LLR is faster for base 3...by just a small amount but it is slightly faster. The timings that Kenneth got are very consistent with my own...slightly faster for LLR. Max, why don't you test base 3 LLR and Phrot on your Linux machine? I haven't tried base 3 on my Linux machines yet. I have a feeling you are going to find the same thing that Kenneth and I unless it's a Window's vs. Linux (or 32-bit vs. 64-bit) thing. Machines where LLR is faster than base 3 on Phrot: 32-bit Hewlett-Packard AMD laptop 1.6 Ghz running Windows Vista. (bought in May 2007) 32-bit Dell Pentium 4 3.2 Ghz running Windows XP. (bought in April 2004) Both machines are current with O.S. updates. I really like my desktop. It totally screamed when I got it and STILL...even though it's only a single core and nearly 5 years old, that single core runs only about 15-20% slower than a single core of my new quads. It's never had a problem except when it's gotten a virus. (lol) Max or Rogue, if you want to attach the screamenest :smile: most state-of-the-art most recent version of Phrot think you think will run faster vs. LLR on base 3 on one or both of these machines, I'll give it yet another try. Gary |
[quote=gd_barnes;159185]64-bit version that was the most recent about a month ago. Guys, I've tried downloading the newest version Phrot, both 32-bit and 64-bit, several times for my 32-bit Windows machines. Every time LLR is faster for base 3...by just a small amount but it is slightly faster. The timings that Kenneth got are very consistent with my own...slightly faster for LLR.
Max, why don't you test base 3 LLR and Phrot on your Linux machine? I haven't tried base 3 on my Linux machines yet. I have a feeling you are going to find the same thing that Kenneth and I unless it's a Window's vs. Linux (or 32-bit vs. 64-bit) thing.[/quote] Hmm...interesting. I'll do a few trial runs sometime tomorrow...stay tuned. :smile: |
[B]Riesel base 39 tested to 1k.[/B]
Just 15097 ks remaining. Should be proven in the lifetime of a Pinus longaeva. It's nearly 2mb, do you want the zip file Gary? (Sorry, I haven't removed the algebraic-factor-thingys because I couldn't think of an easy way to do it.) |
[quote=Flatlander;159432][B]Riesel base 39 tested to 1k.[/B]
Just 15097 ks remaining. Should be proven in the lifetime of a Pinus longaeva. It's nearly 2mb, do you want the zip file Gary? (Sorry, I haven't removed the algebraic-factor-thingys because I couldn't think of an easy way to do it.)[/quote] Yes, please send it along. By "it's nearly 2mb", do you mean the primes file(s) and the k's remaining? If so, no problem. I definitely would not need a results file at such a low n-range. At times, I've dealt with much larger files on Sierp base 31 with a conjecture of k>6.3M. Although the web page will be quite long, I'll get the 15097 remaining k's minus k's with algebraic factors shown in the usual comma-deliminted format. Since I've already generallized the k's with algebraic factors, it will be no problem to quickly remove them all. My personal limit: I won't list anything that has more than 100,000 k's remaining on the web pages. If you are searching a base with that many remaining, you better just search it higher until less are remaining. :smile: Gary |
1 Attachment(s)
[B]Riesel base 58 tested to 10k. Unreserving.[/B]
My program I wrote for removing a list of primes from a list of candidates has broken. (How can that happen??? I've recompiled it but it gets stuck in a loop now. :huh: I won't say which program it's written in or you will all laugh. :blush:) There are three files. Primes with n <=1000, primes with n>1000 and a file of remaining ks at n=1000 (not 10,000). In other words, the primes >1000 need to be subtracted from the remaining-k file. Sorry. [edit: Reference to algebraic factors removed, wrong base!] I tested from 1 to 999, then 999 to 9999, then 9999 to 99999 then 99999 to the end, so the primes > 1000 are in a strange order. Sorry again. I'm definitely having a bad head day. :loco: |
1 Attachment(s)
[B]Riesel base 52 tested to 10k. Unreserving.
[/B]Again, the big primes need removing from the remaining-k file. Sorry. Also the following k were flagged by srsieve as having a.f.: 900, 16641, 35721, 36864, 46656. I've not been sleeping well, I'll stick to NPLB for a while, I'm safer there. lol |
1 Attachment(s)
Found one today on Sierpinski base 33:
1678*33^46632+1 is prime! (445.0087s+0.0710s) (found PRP with Phrot 0.65, proven with PFGW by N-1 test) Results for k=1678, n=25K-46623 are attached. :smile: |
Riesel Base 37
1008*37^20895-1 is prime! (287.4642s+0.0021s) 590*37^22021-1 is prime! (346.0400s+0.0024s) 5946*37^24822-1 is prime! (387.8000s+0.0025s) 4542*37^28765-1 is prime! (558.5508s+0.0030s) 6288*37^30012-1 is prime! (586.5647s+0.0031s) 2606*37^39006-1 is prime! (963.5454s+0.0045s) 3480*37^39565-1 is prime! (1112.0925s+0.0046s) 3336*37^39794-1 is prime! (1172.1690s+0.0046s) 19 Left All k's tested to n=40K continuing to n=70K |
For Riesel bases I'm not testing ks where (k mod base == 0) AND (k-1 is not prime.)
What is the rule for Sierp? edit: Aha! [quote]1) Assume that all smaller k's have been eliminated 2) when k mod base is not == 0 then you have to test for primes 3) when k mod base == 0 and (k-1) is a prime you have to test for primes 4) when k mod base == 0 and (k-1) is not a prime you do not have to test BTW, this only works for the Riesel side. [B]The last 2 above would need to be k+1 for the Sierpinski side.[/B][/quote] |
[quote=Flatlander;160688]For Riesel bases I'm not testing ks where (k mod base == 0) AND (k-1 is not prime.)
What is the rule for Sierp? edit: Aha![/quote] You will not have algebraic factors on most squared k's like you would on the Riesel side, even if the base is a perfect square. (There are a couple of notable exceptions like k=2500 on Sierp base 16; but they are rare.) That's because x^2+1 cannot be algebraicly factored whereas x^2-1 is (x-1)*(x+1). For cubed and higher power bases, there will be algebraic factors on cubed (or higher power) k's like there are on the Riesel side because x^3+1 can be algebraicly factored in a similar manner to x^3-1. There will be some GFN's to remove. For GFN's it's simple; just remove POWERS of the base; so for base 6, you would not test k=1, 6, 36, 216, etc. GFN's can only be prime if n is a power of 2; hence are not considered. Gary |
Here is what I have worked on, am currently working on, and plan to work on in the future for Sierp bases <= 100 that are not shown on the pages yet:
Previously: Base 43 to n=25K. 2 k's remain. Base 55 to n=25K. 7 k's remain. I need to figure out a way to properly show algebraic factors for a single k on this one. It's different and much trickier than usual. Currently: Base 48 and 49 to n=25K. I am currently at n=~20K on both. Base 48 is where I've found some errors in Prof. Caldwell's paper. I'll follow up with him after completing to n=25K. Plan to work on: Bases 50, 53, 54, 56, 57, 59, 62, 64, 65, 68, 69, 70, 72 thru 77, 80, 81, 83, 84, 86 thru 90, 92, 94, 98, 99, & 100. Many are small and will only take a few mins. or hours. Chris, if you want to work on Sierp bases 42 or 46, those should be good. I expect there will be 35-60 k's remaining on them at n=10K so they aren't too bad. Two others that might only have ~40 k's remaining at n=10K are bases 60 and 61. For bases with more than ~10-15 k's remaining, Prof. Caldwell's paper only lists the lowest 10-15 of them. I suspect in coming up with the info. on the paper, they did not search all of the k's on bases with high conjectures. That would have taken far too long. Extrapolating from my own testing, the k's that they did search appear to have been searched to n=~30K-40K. Using that info., I can get a reasonable estimate of the # of k's that should be remaining at n=10K or 25K on each base. Gary |
Reserving Sierp base 61.
|
1 Attachment(s)
Sierp base 61 tested to 16k.
20 ks remaining. Unreserving. (I unreserve when I report unless I say otherwise.) Testing Sierp base 42 and 46. |
1 Attachment(s)
Sierp base 42 tested to 15,000.
50 ks remaining. |
1 Attachment(s)
Sierp base 46 tested to 15,000.
34 ks remaining. |
Sierp base 48 is complete to n=25K. 16 k's remain.
Sierp base 49 is complete to n=25K. 7 k's remain. See details on the web pages. Gary |
Sierp base 43 complete to n=25K; 2 k's remain
Sierp base 55 complete to n=25K; 7 k's remain Sierp base 68 complete to n=25K; 2 k's remain See details on the web pages. |
Sierp bases 50, 54, 56, 59, 62, and 65 were easily proven and have now been added to the web pages.
|
[quote=Flatlander;161475]Sierp base 42 tested to 15,000.
50 ks remaining.[/quote] k=1, 42, & 1764 make GFNs and so are not considered. This removes k=42 from your remaining list meaning that only 49 k's remain. k's that are powers of Sierp bases can be immediately removed just like k's with trivial factors. This only has an effect on even bases. < 5 mins. testing showed that the only prime for 42^n+1 is at n=1 in a test run up to n=2^16-1 (n=65535). Therefore, k=42 is primeless to n=32767 and k=1764 is primeless to n=16383 and hence are unlikely to ever yield primes. Gary |
[quote=gd_barnes;162332]k=1, 42, & 1764 make GFNs and so are not considered. This removes k=42 from your remaining list meaning that only 49 k's remain.
k's that are powers of Sierp bases can be immediately removed just like k's with trivial factors. This only has an effect on even bases. ... Gary[/quote] Sorry, I looked for base^2 but forgot about base^1 and base^0. |
Sierp bases 69, 74, 76, and 77 were all easily proven.
Sierp base 53 is complete to n=9K. 40 k's remain. Sierp base 57 is complete to n=10K. 3 k's remain. Sierp base 72 is complete to n=6K. 6 k's remain. Continuing on all to n=25K. All info. is shown on the web pages. The only thing that I have remaining to update the CRUS pages for is Chris's Riesel base 39 effort and Micha's Riesel base 3 effort for k=560M-570M. If anyone sees anything that I have missed, please let me know. Gary |
Per Chris's testing a while back, I have now updated the web pages to show 14,894 k's remaining on Riesel base 39 at n=1000. I thought some of you might be humored to see so many numbers on one page so [URL="http://gbarnes017.googlepages.com/Riesel-conjecture-base39-reserve.htm"]here[/URL] it is. At 120 KB, it's larger than the entire Riesel conjecture reservations page for all bases and nearly 3 times as large as the Sierp conjecture reservations page for all bases!
After spending 2-3 hours to remove algebraic factors, verifying correct inclusion/exclusion of multiples of the base, confirming that all k's were accounted for, formatting them in a manner for displaying on the page, and doing a double-check to make sure that the count was accurate, this lead me to the following conclusion: If you want your k's remaining shown on the pages, there should be < 10,000 k's remaining. If there are more, I'm sorry, you'll just have to test the base some more. (lol) I had told Chris that I would be fine showing as many as 100,000 k's remaining on a base but after going through that ordeal, I changed my mind. :smile: Gary |
Thanks for all that Gary. :smile:
I won't be testing Riesel base 40 btw !!! |
[quote=Flatlander;162419]Thanks for all that Gary. :smile:
I won't be testing Riesel base 40 btw !!![/quote] Oh, darn. How disappointing! Besides, there is a better alternative: Sierp base 71. With a conjecture of k=~5.9G, I think you and KEP should tackle that one and see if you can get it down to < 10,000 k's remaining. Good luck with that! :missingteeth: Of course there's always Riesel or Sierp base 910. With a conjecture of P=~5T on both sides, it should keep you entertained for a while. But then there is Riesel base 280. That should be really fun! See if you can get that down to < 10,000 k's remaining. With a conjecture of k=~513.6T, over 1000 times greater than either side of base 3, the fun there might be to write a program that can come up with a smaller k that has a covering set. Can you say lots of small primes? BORING! :smile: Gary |
Taking Riesel base 58
|
Riesel Base 58
63677*58^10082-1
7814*58^10165-1 |
Riesel Base 58
49428*58^10244-1
66888*58^10266-1 105303*58^10366-1 9066*58^10394-1 |
Riesel Base 58
56501*58^10431-1
94611*58^10437-1 71306*58^10542-1 38916*58^10751-1 84330*58^10784-1 4608*58^10837-1 76041*58^10869-1 All k tested to 11000 and continuing |
Statii
Here are some misc. statii on various "somewhat easy" Sierp bases that I reserved or failed to reserve but tested anyway (lol) that have not previously been reported:
Bases 34, 36, 38, 41, 44, 47, and 64 are complete and were easily proven. Base 37 is complete to n=25K; 4 k's remain; unreserved. Base 53 is complete to n=17.5K; 34 k's remain; still testing to n=25K. Base 57 is complete to n=25K; 1 k remains; unreserved. Base 72 is complete to n=25K; 2 k's remain; unreserved. Base 73 is complete to n=14K; 4 k's remain; still testing to n=25K. I'm now reserving all k's on Sierp bases 42 and 46 for n=15K-25K. Sieving on base 42 is complete. I am waiting on base 53 above to complete before starting. This leaves me with the following Sierp reservations for bases 40-100: Bases 42, 46, 53, 70, 73, 75, 80, 81, 83, 84, 86 thru 90, 92, 94, 98, 99, and 100. Right now, I'm planning on taking them all to n=25K or proven but may reduce that to n=10K or 15K on some of the higher bases with more k's remaining. Many of them should be proven quickly. Essentially what I'm doing here is checking Prof. Caldwell's math paper. I've found some problems in bases 48 and 53 so I want to see if the are any other problems. Gary |
Sierp bases 83, 84, 89, 90, 92, 94, and 98 are complete and were quickly proven.
Sierp base 73 is complete to n=25K. 2 k's remain. Unreserved. Sierp base 53 is complete to n=20K. 34 k's remain. A very stubborn base with no primes found since n=14.4K. Still running to n=25K. Reservations for Sierp bases > 32 remaining: Bases 42 and 46 for n=15K-25K Base 53 for n=20K-25K Bases 70, 73, 75, 80, 81, 86, 87, 88, 99, and 100 up to n=25K. Gary |
Riesel base 58
64079*58^11080-1
3173*58^11116-1 76050*58^11122-1 32982*58^11175-1 29073*58^11226-1 55877*58^11304-1 46127*58^11432-1 60237*58^11451-1 65432*58^11455-1 12609*58^11496-1 92232*58^11580-1 81225*58^11621-1 46236*58^11650-1 90591*58^11835-1 15516*58^11850-1 18155*58^11853-1 57024*58^11880-1 23835*58^11884-1 43541*58^11890-1 Completed all k to 12000 and continuing |
Riesel Base 58
83561*58^12109-1
27059*58^12176-1 55199*58^12351-1 53601*58^12387-1 55584*58^12437-1 31817*58^12483-1 6071*58^12538-1 68142*58^12650-1 76008*58^12652-1 42420*58^12662-1 84011*58^12665-1 33324*58^12683-1 34731*58^12689-1 37167*58^12726-1 75111*58^12733-1 84219*58^12787-1 39147*58^12822-1 105197*58^12899-1 40646*58^12914-1 Completed to 13000 and continuing |
Sierp base 53 is at n=24K; 32 k's remain; continuing to n=25K.
Sierp base 75 is at n=10K; 9 k's remain; continuing to n=25K. Sierp base 86 is complete to n=25K; only k=8 remains; unreserved. Sierp base 87 is complete to n=25K; only k=32 remains; unreserved. Sierp base 99 is complete to n=25K; only k=284 remains; unreserved. In addition to bases 53 and 75, this leaves the following reservations for me for Sierp bases > 32 up to n=25K: 42, 46, 70, 80, 81, 88, and 100 Moving right along...:smile: Gary |
Riesel Base 72 complete to n=140k No primes
Unreserving |
Riesel Base 45 primes
12950*45^10809-1 is prime! (79.7642s+0.0010s)
19252*45^11431-1 is prime! (82.8969s+0.0011s) 13456*45^56781-1 is prime! (12591.4884s+0.0080s) 7246*45^59101-1 is prime! (2713.5783s+0.0085s) 2500*45^64011-1 is prime! (3594.7002s+0.0098s) 1312*45^104779-1 is prime! (10554.4852s+0.0198s) If I not mistaken, this leaves 11 k's. Almost finished to 100K |
Riesel Base 45
There are 11 k's remaining.
24, 2804, 4210, 6094, 10518, 13458, 17918 and 21274 all tested to n=100K 372, 10096, 15432 all tested to n=120K All primes reported (11) Results will be emailed shortly Unreserving all |
Sierp base 53 is complete to n=25K; 31 k's remain; unreserved.
Sierp base 75 is at n=18K; 5 k's remain; continuing to n=25K. Sierp base 42 for n=15K-25K has just started. 49 k's are being searched. Gary |
[quote=MyDogBuster;164789]There are 11 k's remaining.
24, 2804, 4210, 6094, 10518, 13458, 17918 and 21274 all tested to n=100K 372, 10096, 15432 all tested to n=120K All primes reported (11) Results will be emailed shortly Unreserving all[/quote] A huge chunk done. Nice work Ian! :smile: |
Sierpinski base 63 is at n=1000 with a total of 240131 k's remaining, sieving has just begun on 1 core and within the next 10 days the remaining half will be begun sieved on the next availeable core :smile:
KEP |
[quote=KEP;164861]Sierpinski base 63 is at n=1000 with a total of 240131 k's remaining, sieving has just begun on 1 core and within the next 10 days the remaining half will be begun sieved on the next availeable core :smile:
KEP[/quote] Cool. Now the question is: Can you get it down to < 10,000 k's remaining? That is the limit of what I have said I would show on the pages. I did make an exception for Chris on one with 14,000+ k's remainin so I'll make a similar exception here and show as many as 15,000 k's remaining for base 63. Interestingly, that might actually be possible by n=25K if you have a reduction of 50% for every doubling of the n-range. But as I recall, the reduction percentage isn't that high for base 63. I suspect that it would need to be tested to n=50K or higher, which would likely be several CPU decades of work. Gary |
[QUOTE=gd_barnes;164915]Cool. Now the question is: Can you get it down to < 10,000 k's remaining? That is the limit of what I have said I would show on the pages.
I did make an exception for Chris on one with 14,000+ k's remainin so I'll make a similar exception here and show as many as 15,000 k's remaining for base 63. Interestingly, that might actually be possible by n=25K if you have a reduction of 50% for every doubling of the n-range. But as I recall, the reduction percentage isn't that high for base 63. I suspect that it would need to be tested to n=50K or higher, which would likely be several CPU decades of work. Gary[/QUOTE] I'll see what can be done, however I will not give any promises of testing beyond n=25K, and sincerely I really don't think that it will be nescessary to test beyond n=25K in order to get Sierpinski base 63 below 15000 k's, even if the 50% reduction should not be accurate :smile: I'm btw going to sieve untill it takes ~120 seconds to remove 1 k/n pair, before start crunching. At p=53 million, the removal rate is about 150 k/n pairs each second, with ~249,225,000 pairs remaining in the sieve file :smile: KEP |
Riesel Base 58
25272*58^13090-1
50072*58^13250-1 98172*58^13259-1 19854*58^13287-1 4188*58^13378-1 72038*58^13430-1 15747*58^13650-1 21783*58^13793-1 44697*58^13920-1 71432*58^13974-1 32685*58^13992-1 Completed to 14000 and continuing |
[quote=KEP;164932]I'll see what can be done, however I will not give any promises of testing beyond n=25K, and sincerely I really don't think that it will be nescessary to test beyond n=25K in order to get Sierpinski base 63 below 15000 k's, even if the 50% reduction should not be accurate :smile:
I'm btw going to sieve untill it takes ~120 seconds to remove 1 k/n pair, before start crunching. At p=53 million, the removal rate is about 150 k/n pairs each second, with ~249,225,000 pairs remaining in the sieve file :smile: KEP[/quote] Holy smokes! All that I can say is: Good luck! An ABCD version of that file must be several hundred MB. If you were able to get this base to n=25K, I would be amazed. For me, it would come down to the boredom factor. To do it, I'd just have to put several quads off in a corner somewhere and let them crunch for months or years without even looking at them other than to make sure they are still running and checking their status every couple of weeks. BTW, if you are going to sieve until it takes 120 secs. to remove a pair, since your current rate is 150 pairs/sec. and you are at P=53G, my estimate of your sieve depth would be: 150 * 120 * 53G = 954T or almost 1 quadrillion or 10^15!! As difficult as it will be with a monsterous sieve file, you might want to break off some of the lower n-ranges and do primality testing on them before sieving so far. Since you'll find a lot of primes at the lower n-ranges, you'll be able to remove a lot of k's from the sieve file, which will make it a little more manageable in size. As an example: You might consider doing testing on n=1000-2500 after sieving to around P=1T. While it technically may not be the most efficient way CPU-wise in the long run, it may take less of your personal time in the long run not having to mess with such a huge file. We are quite happy to let you do the really "tough" bases. :smile: Gary |
[QUOTE=gd_barnes;165021]Holy smokes! All that I can say is: Good luck! An ABCD version of that file must be several hundred MB.
If you were able to get this base to n=25K, I would be amazed. For me, it would come down to the boredom factor. To do it, I'd just have to put several quads off in a corner somewhere and let them crunch for months or years without even looking at them other than to make sure they are still running and checking their status every couple of weeks. BTW, if you are going to sieve until it takes 120 secs. to remove a pair, since your current rate is 150 pairs/sec. and you are at P=53G, my estimate of your sieve depth would be: 150 * 120 * 53G = 954T or almost 1 quadrillion or 10^15!! As difficult as it will be with a monsterous sieve file, you might want to break off some of the lower n-ranges and do primality testing on them before sieving so far. Since you'll find a lot of primes at the lower n-ranges, you'll be able to remove a lot of k's from the sieve file, which will make it a little more manageable in size. As an example: You might consider doing testing on n=1000-2500 after sieving to around P=1T. While it technically may not be the most efficient way CPU-wise in the long run, it may take less of your personal time in the long run not having to mess with such a huge file. We are quite happy to let you do the really "tough" bases. :smile: Gary[/QUOTE] 1. I'm happy to take the big bases, though I can say with a 100% guarantee that this will be the final base and the final CRUS work I'm ever gonna complete 2. I'm going to sieve the remaining k's from n=1001-25000 on 2 cores. The remaining 2 cores I'll keep busy doing my own Mega-prime project and get that started really good, and then once I feel like there has been sieve deep enough, then I will convert the ABCD files to NewPGen files and start PRP testing on the Dual core and then use the entire Quad on my MegaPrime project. 3. Current ABCD file availeable takes up 1.46 GB of data, and currently ~70 pairs is removed every second :) Leaving 236.6 million pairs remaining in sieve file... KEP |
Sierp base 75 is complete to n=25K; 5 k's remain; unreserved.
Sierp base 42 is at n=17.5K; 47 k's remain; continuing to n=25K. Now working on Sierp base 70 to n=25K. |
[quote=KEP;164932]I'll see what can be done, however I will not give any promises of testing beyond n=25K, and sincerely I really don't think that it will be nescessary to test beyond n=25K in order to get Sierpinski base 63 below 15000 k's, even if the 50% reduction should not be accurate :smile:
I'm btw going to sieve untill it takes ~120 seconds to remove 1 k/n pair, before start crunching. At p=53 million, the removal rate is about 150 k/n pairs each second, with ~249,225,000 pairs remaining in the sieve file :smile: KEP[/quote] I'm not sure where you got a 50% reduction for base 63. I only used that as the simplest possible example for base 3, which is much more prime than just about any other base. Besides, for base 3, 60% is more accurate. I found my prior post where I had calculated the approximate percentage reduction for base 63 with each doubling of the n-value. It is about 37%. Therefore, we have: n=1000; 240131 k's remaining n=2000; 151283 k's remaining n=4000; 95308 k's remaining n=8000; 60044 k's remaining n=16000; 37828 k's remaining n=32000; 23831 k's remaining n=64000; 15014 k's remaining So...it's looking like you'd need to test it to n>64K to get it down to < 15000 k's remaining. And further: I expect the above to be a little low on the k's remaining because the percentage gradually drops as the n-range gets higher because the remaining k's have a lower average weight as the higher-weight k's get eliminated. Since this is such a huge base, if you're willing to put in the effort to get it up to at n=10K, perhaps I'll make another exception and show as many as 60000 k's remaining on a web page. It will be a BIG page though! :-) BTW, it looks like there would be 27000-30000 k's remaining at n=25K. Gary |
@ Gary:
It's nice to know that you're willing to make another exception, because I'm sieving to n<=25K and that in it self is a huge task, so it would deffinently be nice not to have commitment all the way to n=25K, since I may eventually like to use my entire Quad for something else :smile: I just guessed the 50%, but if what you're guessing is more accurate, then I guess that you'll deffinently need to publish several thousands more than just the 15,000 k's remaining. But we will see, only time can tell how deep I get to sieve and how high n-value I test, though it's going to be a nice task that I can put on my dual core, since it will not require much attention for a long period of time :smile: Regards KEP |
why not just have a .txt file with the list of sequences remaining in it
|
[quote=KEP;165079]@ Gary:
It's nice to know that you're willing to make another exception, because I'm sieving to n<=25K and that in it self is a huge task, so it would deffinently be nice not to have commitment all the way to n=25K, since I may eventually like to use my entire Quad for something else :smile: I just guessed the 50%, but if what you're guessing is more accurate, then I guess that you'll deffinently need to publish several thousands more than just the 15,000 k's remaining. But we will see, only time can tell how deep I get to sieve and how high n-value I test, though it's going to be a nice task that I can put on my dual core, since it will not require much attention for a long period of time :smile: Regards KEP[/quote] I'm confused. Several months ago, you guessed 50% based on an example that I gave that was not intended for any specific base. Now you think that I am guessing at 37%. And before the most recent discussion, you continued to use 50% to conclude that you'll be down to 15000 k's remaining at n=25K even after I previously stated 37%. Have you forgotten [URL="http://www.mersenneforum.org/showpost.php?p=158880&postcount=291"]this post[/URL] and [URL="http://www.mersenneforum.org/showpost.php?p=158915&postcount=292"]this post[/URL] that contain my previous discussion about this? The ~37% is not a guess. I did actual testing on k<2000 up to n=3200 to get a relatively accurate estimate. Also, you can look in your own k's remaining and primes. I'm sure it will show that you're not coming in anywhere near 50%. Do some quick and easy math on it and you don't have to guess. Please stop the guessing. Trust me on this, the percentage reduction will likely come in within 1-5% of 37%. [quote=henryzz;165081]why not just have a .txt file with the list of sequences remaining in it[/quote] It's not the conversion of so many k's to comma-delimited format that takes so long. It's verifying that nothing is missed, k's with algebraic and trivial factors are removed, correct k's that are multiples of the base are removed, etc. and that the # of k's to start with minus the primes found equals the k's remaining. It's that balancing act that takes so long. Showing all the k's remaining on the pages is trivial compared to balancing stuff for huge conjectures. Gary |
Riesel B
25755*58^14125-1
9395*58^14261-1 65310*58^14338-1 13892*58^14348-1 96584*58^14445-1 21239*58^14456-1 54161*58^14478-1 46293*58^14500-1 104927*58^14616-1 54629*58^14696-1 27602*58^14882-1 Completed to 15000 and continuing |
Riesel Base 37 all k's tested to n=70K
Primes posted s/b 17 k's left Unreserving Results emailed |
Riesel Base 37
1842*37^41606-1 is prime! (1244.8672s+0.0049s) 5262*37^60498-1 is prime! (2675.3231s+0.0082s) |
Riesel Base 58
47100*58^15090-1
59981*58^15125-1 63737*58^15306-1 45488*58^15520-1 61833*58^15573-1 3866*58^15574-1 52509*58^15676-1 104133*58^15716-1 57924*58^15784-1 96954*58^15857-1 71009*58^15872-1 Complete to 16000 and continuing |
Sierp base 42 is at n=22K; 46 k's remaining; continuing to n=25K. An extremely stubborn base that has only had 3 primes out of 49 k's remaining for n=15K-22K.
Sierp base 70 is complete to n=25K; 6 k's remaining; now unreserved. Sierp base 100 is at n=12K; 8 k's remaining; continuing to n=25K. After these are done, that will leave Sierp bases 46, 80, 81, & 88 remaining to take up to n=25K. After that, I'll likely work on getting more of the Riesel bases < 100 up to n=25K. Gary |
| All times are UTC. The time now is 09:03. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.