|
[CODE][B]$ ./xyyxsieve -P 1e8 -x 300e3 -X 301e3 -y 150e3 -Y 151e3 -s '+' -o ryanp.txt[/B]
xyyxsieve v1.8.1, a program to find factors numbers of the form x^y+y^x or x^y-y^x Quick elimination of terms info (in order of check): 0 because y >= x 501001 because the term is even 95143 because x and y have a common divisor Sieve started: 3 < p < 1e8 with 405857 terms (300000 <= x <= 301000, 150000 <= y <= 151000) (expecting 381651 factors) Decreasing worksize to 2528 since each chunk needs more than 5 seconds to test Increasing worksize to 10112 since each chunk is tested in less than a second Decreasing worksize to 5056 since each chunk needs more than 5 seconds to test p=55030691, 3.592K p/sec, 383736 factors found at 1.879 f/sec (last 1 min), 55.0% done. ETC 2023-06-22 14:55 Increasing worksize to 20224 since each chunk is tested in less than a second Decreasing worksize to 10112 since each chunk needs more than 5 seconds to test p=99688909, 3.769K p/sec, 384391 factors found at 0.49 sec per factor (last 20 min), 99.6% done. ETC 2023-06-22 14:53 Sieve completed at p=100000037. CPU time: 1533.52 sec. (0.04 sieving) (1.00 cores) 21464 terms written to ryanp.txt Primes tested: 5761456. Factors found: 384393. Remaining terms: 21464. Time: 1528.32 seconds. [B]$ ./xyyxsievecl -P 1e10 -i ryanp.txt -o ryanp2.txt -g 84 -H -O ryanp.factors[/B] xyyxsieve v1.8.1, a program to find factors numbers of the form x^y+y^x or x^y-y^x GPU primes per worker is 1806336 Sieve started: 100000037 < p < 1e10 with 21464 terms (300000 <= x <= 301000, 150001 <= y <= 151000) (expecting 4292 factors) p=9928036067, [U]332.5K p/sec[/U], 4244 factors found at 1.582 f/sec (last 22 min), 99.2% done. ETC 2023-06-22 15:18 Sieve completed at p=10011193811. CPU time: 1354.18 sec. (3.49 sieving) (1.00 cores) GPU time: 1345.37 sec. 17212 terms written to ryanp2.txt Primes tested: 449777664. Factors found: 4252. Remaining terms: 17212. Time: 1349.22 seconds.[/CODE] Much better, no? |
[QUOTE=ryanp;632792]I'm doing some simple tests with [C]xyyxsievecl[/C], and would like to understand the output:
Why does [C]p[/C] stay at 0 for a while, then suddenly jump up, drop back down, etc (and occasionally remain stuck for a while at the same value)? Is this expected behavior, something to do with GPU threading, or a legitimate bug? (Note: this is on an A100 GPU, and the overall speed isn't remotely close to what I'd expect.)[/QUOTE] p is supposed to represent the largest p where we know that all p less than that value have been tested. If I had to guess, some workers have no work so the largest p they have tested is still 0. I can adjust the code to avoid workers with no work when determining p. I am more concerned that p decreased in the middle of the run, that is definitely a bug. |
Another bug... after a while, it crashes with:
[CODE] p=4685491913, 19.71K p/sec, 3838 factors found at 1.78 sec per factor (last 56 p=4685491913, 19.37K p/sec, 3892 factors found at 1.78 sec per factor (last 57 p=4737217409, 19.69K p/sec, 3982 factors found at 1.77 sec per factor (last 58 p=4737217409, 19.36K p/sec, 4026 factors found at 1.78 sec per factor Fatal Error: Something is wrong. Counted terms (272597) != expected terms (276672)[/CODE] |
Is this with the same command line? Or are you using something with -W or -G?
|
[QUOTE=kruoli;632827]Is this with the same command line? Or are you using something with -W or -G?[/QUOTE]
The fatal error above was with [C]-g 84 -H[/C] per your suggestion. I did not pass -G, -W, or -M. |
Thanks for the clarification!
In your case (A100) I meant to suggest -g 108 (number of SMs), my example was with my 3090Ti, which has 84 SMs. -H was for increased verbosity. |
One more... *hopefully* my last bug report for today.
There also seems to be an issue with the "sparse vs non-sparse" logic. This apparently causes memory corruption when reading lines with [C]-i[/C]. For example, I'll see: [CODE]$ ./xyyxsieve -i ./xyyx_1.5M.txt -o test -P 1e12 -W 32 xyyxsieve v2.0, a program to find factors numbers of the form x^y+y^x or x^y-y^x Fatal Error: Line 30p46y 557402 is malformed[/CODE] even though the file itself is perfectly fine. It apparently happens during the second read of [C]ProcessInputTermsFile()[/C]; I worked around it by commenting out the "if" block here: [CODE] ProcessInputTermsFile(false); // If there are multiple x per y and multiple y per x, then we can use a > /* if (il_TermCount > ii_MaxX - ii_MinX && il_TermCount > ii_MaxY - ii_Min> { iv_Terms.resize(il_TermCount); std::fill(iv_Terms.begin(), iv_Terms.end(), false); } else { */ // Otherwise we use a map ib_Sparse = true; ip_Terms = (term_t *) xmalloc((1+il_TermCount) * sizeof(term_t)); // } il_TermCount = 0; ProcessInputTermsFile(true);[/CODE] |
The resize() call should be this in the if condition:
iv_Terms.resize(GetXCount() * GetYCount()); Regarding this error: Fatal Error: Something is wrong. Counted terms (272597) != expected terms (276672) Was that after starting with -i? I wonder if they are related. I ask because I don't see anything obviously wrong in the code. I will consider adding a command line switch to allow the end user to force the sparse logic. I think I know the cause of your first bug report and have a fix, but it needs to be tested. |
[QUOTE=rogue;632836]The resize() call should be this in the if condition:
iv_Terms.resize(GetXCount() * GetYCount()); Regarding this error: Fatal Error: Something is wrong. Counted terms (272597) != expected terms (276672) Was that after starting with -i? I wonder if they are related.[/QUOTE] Yes, that was also a run with [C]-i[/C]. |
[QUOTE=ryanp;632837]Yes, that was also a run with [C]-i[/C].[/QUOTE]
Could you run two tests? First with my code change when using -i. Does it still crash after an hour? Second with your code change. Does it crash after an hour? If neither crash, then the fix I provided most likely addresses the problem. |
For testing, where would you change the time of one hour to a lower value?
|
You're right, it does seem to crash after exactly 1 hour.
[CODE]$ ./xyyxsievecl -P 1e12 -g 108 -i ./xyyx_1.5M.txt -o out.txt -H xyyxsieve v2.0, a program to find factors numbers of the form x^y+y^x or x^y-y^x GPU primes per worker is 2985984 Sieve started: 2009105977 <= p <= 1e12 with 295337 terms (300000 <= x <= 302000, 150001 <= y <= 159999) (expecting 66376 factors) p=0, 0.000 p/sec, 140 factors found at 1.222 f/sec (last 1 min) p=0, 0.000 p/sec, 317 factors found at 1.378 f/sec (last 2 min) p=2073126071, 16.37K p/sec, 471 factors found at 1.374 f/sec (last 3 min) p=2073126071, 12.26K p/sec, 640 factors found at 1.399 f/sec (last 4 min) ... p=3435438343, 18.25K p/sec, 7301 factors found at 1.018 f/sec (last 59 min), 0 Fatal Error: Something is wrong. Counted terms (280490) != expected terms (287868)[/CODE] |
One hour is the time when the output file is written for the first time. After the file is written, the data is compared to that was is in memory. If there is a problem with synchronising, it will output the error you have gotten.
|
[QUOTE=ryanp;632842]You're right, it does seem to crash after exactly 1 hour.
[CODE]$ ./xyyxsievecl -P 1e12 -g 108 -i ./xyyx_1.5M.txt -o out.txt -H xyyxsieve v2.0, a program to find factors numbers of the form x^y+y^x or x^y-y^x GPU primes per worker is 2985984 Sieve started: 2009105977 <= p <= 1e12 with 295337 terms (300000 <= x <= 302000, 150001 <= y <= 159999) (expecting 66376 factors) p=0, 0.000 p/sec, 140 factors found at 1.222 f/sec (last 1 min) p=0, 0.000 p/sec, 317 factors found at 1.378 f/sec (last 2 min) p=2073126071, 16.37K p/sec, 471 factors found at 1.374 f/sec (last 3 min) p=2073126071, 12.26K p/sec, 640 factors found at 1.399 f/sec (last 4 min) ... p=3435438343, 18.25K p/sec, 7301 factors found at 1.018 f/sec (last 59 min), 0 Fatal Error: Something is wrong. Counted terms (280490) != expected terms (287868)[/CODE][/QUOTE] Can you use -O to capture factors, then check to see if the number of rows in that file equals starting count - counted terms (when it terminated)? Can you also check to see if it removed terms in the -o file that don't have factors in the -O file? This will help me narrow it down. I suspect there might be in overflow in the BIT() macro. To verify that you can add a printf() to print BIT(ii_MinX, ii_MinY) at the end of ValidateOptions(). If it returns a value less than 2^32, then that is definitely a problem. If it "the problem", I won't until I can spend more time in the code. |
Ryan, I have not been able to reproduce the xyyxsievecl issue. I did make that change that I specified when starting with an old file. If you still have issues, then I will need some more help from you to track down the cause.
|
I have tracked down and resolved the issue with Legendre tables in srsieve2. That being written I have released mtsieve 2.5.0. Here are the changes:
[code] framework: Fix how max p tested is computed as it could be wrong when running many workers. srsieve2/srsieve2cl: version 1.7.2 Reverted part of the change for algebraic factorizations as it excluded too many. Fix issue when using Legendre tables where factors would be missed. twinsieve: version 1.6.2 Fixed issue with base 2 where even k are factored even though even k are not used. The same issue can occur with odd bases. xyyxsieve/xyyxsievecl: version 2.1 Added -Z to allow user to force sparse logic, which can be faster or slower depending upon the density of x and y. Fixed an issue when starting with -i that can lead to a crash. [/code] |
[QUOTE=rogue;632884]Ryan, I have not been able to reproduce the xyyxsievecl issue. I did make that change that I specified when starting with an old file. If you still have issues, then I will need some more help from you to track down the cause.[/QUOTE]
Let me send you my input file in a PM. I can repro it pretty consistently. |
[QUOTE=ryanp;632894]Let me send you my input file in a PM. I can repro it pretty consistently.[/QUOTE]
Okay. Is this with 2.1? Can you include the command line arguments you use? |
[QUOTE=rogue;632901]Okay. Is this with 2.1? Can you include the command line arguments you use?[/QUOTE]
I hadn't tried 2.1 yet; just did an [C]svn up[/C] and I'm trying it now. So far, at least, the input file reading is fixed: [CODE]$ ./xyyxsievecl -P 1e12 -g 108 -i ./xyyx_1.5M.txt -o out.txt xyyxsieve v2.1, a program to find factors numbers of the form x^y+y^x or x^y-y^x GPU primes per worker is 2985984 Sieve started: 2009105977 <= p <= 1e12 with 295337 terms (300000 <= x <= 302000, 150001 <= y <= 159999) (expecting 66376 factors)[/CODE] We'll see what happens after an hour. |
It looks like you fixed srsieve2. Now we have increase in speed since we can use Legendre tables, and still all factors are found :)
Good work! and thanks! |
[QUOTE=rogue;632887]I have tracked down and resolved the issue with Legendre tables in srsieve2. That being written I have released mtsieve 2.5.0.[/QUOTE]
Looking good here. I replaced the v1.6.9 I was using with my R78 sieve. 63 sequences with 315K terms. It will get a good workout. I deleted the Legendre tables the old one was using and had the new one recreate them. There is somewhat of a speed difference. 1.6.9 was running 210K p/sec. 1.7.2 is running 160K p/sec. If this is a result of error corrections, then this is the way it will be. I have no problems with it. Many thanks! :smile: |
With [C]xyyxsievecl[/C] 2.1, both the file reading bug and the "Fatal Error" crash after 1 hour appear to be fixed.
[CODE] p=11285155907, 22.40K p/sec, 22114 factors found at 1.67 sec per factor (last 303 min), 0.9% done. ETC 2023-07-16 20:51 [/CODE] |
Srsieve2 1.7.2 fails on algebraic factor removal similar to how versions 1.7.0 and prior did.
It is removing algebraic factors that it should not be when the k and base are different perfect powers. Therefore primes could be subsequently missed. This was fixed in version 1.7.1 at the expense of having it not remove some algebraic factors that it should. Unfortunately it is now removing more than it should. Examples: 9*8^n-1: It removes all terms. It should only remove terms divisible by 2. 27*32^n-1: It removes all terms. It should only remove terms divisible by 3. 32*125^n-1: It removes all terms. It should only remove terms divisible by 5. As best as I can tell, this is only happening on the Riesel side at this time. On the Sierpinski side, it is still missing some algebraic factors but that would have no affect on future primes found. For anyone using 1.7.2 for the extra speed because it is no longer missing factors when using the Legendre tables, you should be OK if your base is not a power. Storm and Pepi, this means you will be OK. Your bases 78 and 773 are not powers so this error will not affect them. I will Email Mark the test cases for this later this morning. |
Ok thanks Gary
|
[QUOTE=ryanp;632938]With [C]xyyxsievecl[/C] 2.1, both the file reading bug and the "Fatal Error" crash after 1 hour appear to be fixed.
[CODE] p=11285155907, 22.40K p/sec, 22114 factors found at 1.67 sec per factor (last 303 min), 0.9% done. ETC 2023-07-16 20:51 [/CODE][/QUOTE] Awesome! |
[QUOTE=gd_barnes;632949]Srsieve2 1.7.2 fails on algebraic factor removal similar to how versions 1.7.0 and prior did.
It is removing algebraic factors that it should not be when the k and base are different perfect powers. Therefore primes could be subsequently missed. This was fixed in version 1.7.1 at the expense of having it not remove some algebraic factors that it should. Unfortunately it is now removing more than it should. Examples: 9*8^n-1: It removes all terms. It should only remove terms divisible by 2. 27*32^n-1: It removes all terms. It should only remove terms divisible by 3. 32*125^n-1: It removes all terms. It should only remove terms divisible by 5.[/QUOTE] For these cases it can remove terms because k=x^f, but it can also try to remove terms because k=x^f and b=y^g, but it should only remove terms if gcd(f,g) > 0. It is likely failing that. I hope to take a look at it this weekend. The speed loss is due to the fixed code. |
[QUOTE=ryanp;632938][CODE] p=11285155907, 22.40K p/sec, 22114 factors found at 1.67 sec per factor (last 303 min), 0.9% done. ETC 2023-07-16 20:51[/CODE][/QUOTE]
Is this with more candidates than the inital try? If not, 22.40K p/sec is still pretty slow. |
[QUOTE=kruoli;632974]Is this with more candidates than the inital try? If not, 22.40K p/sec is still pretty slow.[/QUOTE]
No, same input file as the first try (~295K input terms). I'm using [C]-g 108[/C], and not passing [C]-G[/C] or [C]-W[/C]. |
Have you double checked that it is running on the correct device with [C]nvidia-smi[/C]? Which driver version are you using? What does [C]./xyyxsievecl -h[/C] give for OpenCL devices? Example:
[CODE]List of available platforms and devices Platform 0 is a NVIDIA Corporation NVIDIA CUDA, version OpenCL 3.0 CUDA 12.1.68 Device 0 is a NVIDIA Corporation NVIDIA GeForce RTX 3090 Ti Device 1 is a NVIDIA Corporation NVIDIA GeForce RTX 3090 Ti[/CODE] |
[QUOTE=kruoli;632980]Have you double checked that it is running on the correct device with [C]nvidia-smi[/C]? Which driver version are you using? What does [C]./xyyxsievecl -h[/C] give for OpenCL devices? Example:
[CODE]List of available platforms and devices Platform 0 is a NVIDIA Corporation NVIDIA CUDA, version OpenCL 3.0 CUDA 12.1.68 Device 0 is a NVIDIA Corporation NVIDIA GeForce RTX 3090 Ti Device 1 is a NVIDIA Corporation NVIDIA GeForce RTX 3090 Ti[/CODE][/QUOTE] There is only one GPU device on this system, and [C]nvidia-smi[/C] shows it 100% utilized. [CODE]Sat Jun 24 14:11:10 2023 +---------------------------------------------------------------------------------------+ | NVIDIA-SMI 530.30.02 Driver Version: 530.30.02 CUDA Version: 12.1 | |-----------------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | | | | MIG M. | |=========================================+======================+======================| | 0 NVIDIA A100-SXM4-40GB On | 00000000:00:04.0 Off | 0 | | N/A 54C P0 245W / 400W| 443MiB / 40960MiB | 100% Default | | | | Disabled | +-----------------------------------------+----------------------+----------------------+ +---------------------------------------------------------------------------------------+ | Processes: | | GPU GI CI PID Type Process name GPU Memory | | ID ID Usage | |=======================================================================================| | 0 N/A N/A 63836 C ./xyyxsievecl 440MiB | +---------------------------------------------------------------------------------------+ [/CODE] |
[QUOTE=gd_barnes;632949]...For anyone using 1.7.2 for the extra speed because it is no longer missing factors when using the Legendre tables, you should be OK if your base is not a power. Storm and Pepi, this means you will be OK. Your bases 78 and 773 are not powers so this error will not affect them...[/QUOTE]
Very well. Thanks for the update. |
I'm still seeing this with [C]xyyxsievecl[/C]:
[CODE]p=4764640901, 43.89K p/sec, 4310 factors found at 22.46 sec per factor p=4764640901, 44.81K p/sec, 4391 factors found at 22.87 sec per factor Fatal Error: Something is wrong. Counted terms (142382) != expected terms (146771)[/CODE] rogue, I can send you an input file via PM if you want. |
twinsieve issue
Hi, I've been experimenting with twinsieve and seem to have run into an issue when resuming a file. It seems to work fine if I start from scratch, but if I try to resume a sieve file it doesn't work. I have tried all formats and files created with twinsieve or newpgen doesn't seem to matter. Newpgen format doesn't give an error but just silently dies.
[CODE] twinsieve v1.6.2, a program to find factors of k*b^n+1/-1 numbers for fixed b and n and variable k Fatal Error: Line 1 exponents in ABCD input file twin.txt do not match[/CODE] |
[QUOTE=k0r3;633109]Hi, I've been experimenting with twinsieve and seem to have run into an issue when resuming a file. It seems to work fine if I start from scratch, but if I try to resume a sieve file it doesn't work. I have tried all formats and files created with twinsieve or newpgen doesn't seem to matter. Newpgen format doesn't give an error but just silently dies.
[CODE] twinsieve v1.6.2, a program to find factors of k*b^n+1/-1 numbers for fixed b and n and variable k Fatal Error: Line 1 exponents in ABCD input file twin.txt do not match[/CODE][/QUOTE] What command line arguments did you use to start (not continue) the sieve? What is the first line of the ABCD file? |
[QUOTE=rogue;633113]What command line arguments did you use to start (not continue) the sieve? What is the first line of the ABCD file?[/QUOTE]
I have tried many different combinations of command line arguments and have not been able to get a file that works, here is my most recent one [CODE].\twinsieve.exe -P 1e10 -o out.txt -k1 -K99999 -b2 -n12345 -t1[/CODE] Here's the ABCD and Newpgen first lines I tried most recently. [CODE]ABCD $a*2^12345+1 & $a*2^12345-1 [3339] // Sieved to 10000000019 9650251852537:T:0:2:3 1293 333330[/CODE] |
[QUOTE=k0r3;633115]I have tried many different combinations of command line arguments and have not been able to get a file that works, here is my most recent one
[CODE].\twinsieve.exe -P 1e10 -o out.txt -k1 -K99999 -b2 -n12345 -t1[/CODE] Here's the ABCD and Newpgen first lines I tried most recently. [CODE]ABCD $a*2^12345+1 & $a*2^12345-1 [3339] // Sieved to 10000000019 9650251852537:T:0:2:3 1293 333330[/CODE][/QUOTE] Problem found and fixed in sourceforge |
[QUOTE=ryanp;633106]I'm still seeing this with [C]xyyxsievecl[/C]:
[CODE]p=4764640901, 43.89K p/sec, 4310 factors found at 22.46 sec per factor p=4764640901, 44.81K p/sec, 4391 factors found at 22.87 sec per factor Fatal Error: Something is wrong. Counted terms (142382) != expected terms (146771)[/CODE] rogue, I can send you an input file via PM if you want.[/QUOTE] Problem found and fixed in sourceforge. |
[QUOTE=gd_barnes;632949]Srsieve2 1.7.2 fails on algebraic factor removal similar to how versions 1.7.0 and prior did.
It is removing algebraic factors that it should not be when the k and base are different perfect powers. Therefore primes could be subsequently missed. This was fixed in version 1.7.1 at the expense of having it not remove some algebraic factors that it should. Unfortunately it is now removing more than it should. Examples: 9*8^n-1: It removes all terms. It should only remove terms divisible by 2. 27*32^n-1: It removes all terms. It should only remove terms divisible by 3. 32*125^n-1: It removes all terms. It should only remove terms divisible by 5. As best as I can tell, this is only happening on the Riesel side at this time. On the Sierpinski side, it is still missing some algebraic factors but that would have no affect on future primes found. For anyone using 1.7.2 for the extra speed because it is no longer missing factors when using the Legendre tables, you should be OK if your base is not a power. Storm and Pepi, this means you will be OK. Your bases 78 and 773 are not powers so this error will not affect them. [/QUOTE] I changed the code to address the case where it is "removing all terms", but it will still miss algebraic factors. In order for me to address that I would need examples of algebraic factors that are missed. Note that I am only focused on c = +1 and -1 sequences where d = 1. Algebraic factors for other c and d are not covered. |
[QUOTE=rogue;633152]Problem found and fixed in sourceforge[/QUOTE]
Thanks for the quick fix. It still seems to have some issues with Newpgen format though. [CODE].\twinsieve.exe -i newpgen.txt -o out2.txt twinsieve v1.6.3, a program to find factors of k*b^n+1/-1 numbers for fixed b and n and variable k Sieve started: 9650251852537 <= p <= 2^62 with 465320 terms[/CODE] It dies right after that, here is the first lines of the file I'm trying [CODE]9650251852537:T:0:2:3 1293 333330[/CODE] |
[QUOTE=k0r3;633160]Thanks for the quick fix. It still seems to have some issues with Newpgen format though.[/QUOTE]
Fixed now |
[QUOTE=rogue;633169]Fixed now[/QUOTE]
Seems to be working now, thanks! |
[QUOTE=rogue;633156]I changed the code to address the case where it is "removing all terms", but it will still miss algebraic factors. In order for me to address that I would need examples of algebraic factors that are missed. Note that I am only focused on c = +1 and -1 sequences where d = 1. Algebraic factors for other c and d are not covered.[/QUOTE]
On Sierpinski bases where both k and base are equal powers >= 3, it is only removing n's divisible by the power of the k. It should remove all n's. Below are some test cases. It should have removed all terms on these: 343*8^n+1 only removed terms divisible by 3. 125*216^n+1 only removed terms divisible by 3. 243*32^n+1 only removed terms divisible by 5. 3125*1024^n+1 only removed terms divisible by 5. This is for version 1.7.2 from the last update of mtsieve a few days ago. I did not see a new executable at SourceForge for your latest fix. I only saw where the source for AlgebraicFactorHelper.cpp had been changed earlier today. Maybe I'm missing something. |
[QUOTE=gd_barnes;633196]On Sierpinski bases where both k and base are equal powers >= 3, it is only removing n's divisible by the power of the k. It should remove all n's.
Below are some test cases. It should have removed all terms on these: 343*8^n+1 only removed terms divisible by 3. 125*216^n+1 only removed terms divisible by 3. 243*32^n+1 only removed terms divisible by 5. 3125*1024^n+1 only removed terms divisible by 5. This is for version 1.7.2 from the last update of mtsieve a few days ago. I did not see a new executable at SourceForge for your latest fix. I only saw where the source for AlgebraicFactorHelper.cpp had been changed earlier today. Maybe I'm missing something.[/QUOTE] I have not posted it yet. In short if we have k*b^n+1 where k = x^g and b = y^g and g is odd, then all terms would be GFN as they could be written as (x*y)^(g*n)+1. This is what I need to do to derive algebraic factorizations. |
[QUOTE=rogue;633201]I have not posted it yet.
In short if we have k*b^n+1 where k = x^g and b = y^g and g is odd, then all terms would be GFN as they could be written as (x*y)^(g*n)+1. This is what I need to do to derive algebraic factorizations.[/QUOTE] Coding specifically for g is odd wouldn't work. There's always powers of 6, 10, 12, etc. Those would reduce to a cube, 5th power, and cube respectively where all terms should be removed. More specifically, all terms should be removed if: g has an odd prime factor where itself counts as a prime factor Stated in a different way, all terms should be removed if: g is not a power of 2 Maybe you were getting at this but I wasn't clear on it. |
I misstated. Hopefully this is correct. If k = x^f and b = y^g and gcd(f,g) > 1 then k*b^n+1 can only be prime if k*b^n+1 is a GFN. srsieve2 is not intended for sieving GFNs.
|
[QUOTE=rogue;633221]I misstated. Hopefully this is correct. If k = x^f and b = y^g and gcd(f,g) > 1 then k*b^n+1 can only be prime if k*b^n+1 is a GFN. srsieve2 is not intended for sieving GFNs.[/QUOTE]
Although that makes sense I'm unclear how we got off on the topic of GFNs and how it pertains to the original problem. If as you state k = x^f and b = y^g and gcd (f,g) > 1 make a GFN, I would add additional qualifications that must be there in order to remove all n-values, which is where we were going with it. Specifically on the Sierpinski side, all n-values should be removed if: ( f = g and f,g >= 3 -and- f,g are not a power-of-2 ) -or- ( f,g >= 3 and gcd(f,g) >= 3 ) This expands on what I stated earlier, which wasn't inclusive enough. I had stated that the powers (f & g) had to be equal. But that's not enough. They can be unequal if they have a gcd >= 3. I hope that covers all of the cases of the form x^f*(y^g)^n+1 where all n-values should be removed. But I wouldn't be surprised if there's something more out there. |
It is my mistake if we are talking past one another. This algebraic factor stuff can be quite confusing.
If k = x^f and b = y^g and x = y and c = +1, then it is GFN. This is already handled. Regarding your case I need to identify the divisors and dump them to the alg.txt file so they can be independently verified by pfgw (to ensure no coding errors in srsieve2. This is not handled: If k = x^f and b = y^g and gcd(x,y) > 2 and gcd(x,y) != 2^n for any n > 0 and c = +1, then each term has the factor of x*y+1. These are handled: If k = x^f and c = +1 and f is odd then each term where n%f = 0 has the factor x*b^(n/f)+1. If k = x^f and c = -1 then each term where n%f = 0 has the factor x*b^(n/f)-1. k = x^f and b = y^g and gcd(x,y) > 2 and c = -1 is handled incorrectly in the current release causing it to remove all terms but output a divisor that is equal to the term itself. This is how it should be handled: If k = x^f and b = y^g and gcd(x,y) > 2 and c = -1, then each term has the factor of x*y^n-1. |
[QUOTE=rogue;633234]If k = x^f and b = y^g and gcd(x,y) > 2 and c = -1, then each term has the factor of x*y^n-1.[/QUOTE]
Not quite. if gcd(x,y) = m then x^(f/m)*y^(g/m)^n-1 is a factor. For example for 64*36^n-1 we have factors of the form 8*6^n-1 I am in the process of testing to verify that no invalid factors are found for all b <= 1001 and all k <=1001 for a small range of n. Testing higher b and k will have to be done on a case-by-case basis. |
With [C]xyyxsievecl[/C] v2.2, with an input terms file of ~120K terms, I'm able to pull about:
[CODE] p=19700696761, 67.20K p/sec[/CODE] on an A100. This is using [C]-g 108[/C] and without specifying [C]-G[/C] or [C]-W[/C]. Wondering if that's the best fine-tuning I can do... |
The testing is looking good. No invalid factors for what I have tested. I have committed changes to sourceforge, but I have not made a build available yet. The new code is much easier for me to work with.
An example of the output for Sierpinski is: (s) Sequence has algebraic factorization: 512*8^n+1 -> k = 2^9 and b = 2^3 and gcd(9,3) > 1 Riesel looks pretty much the same except for (r) instead of (s). These are the first algebraic factor tests. None of the others are applied if either of these removes all terms for a sequence. That helps clean up the output a little. To help with my testing I added a -a command line switch. When used srsieve2 will terminate immediately after checking for algebraic factors. |
All sounds great, Mark! I look forward to running the new version through my myriad of test cases and then some.
Clarification: You continue to use gcd > 1 when referencing the powers (i.e. f & g) for the removal of all n's on the Sierpinski side. That's not quite right. It would be correct for Riesel bases but it should be gcd > 2 for Sierpinski bases. Example: k = x^6 and b = y^10, i.e. f = 6 and g = 10 per your previous examples. x^6*(y^10)^n+1 would only have algebraic factors where n is divisible by 3 [since x^6 = (x^2)^3]. Since the gcd of (f,g) = (6,10) is only 2, all terms cannot be removed. That contradicts your gcd > 1 statement. (Perhaps we are talking past each other again. :smile:) Onto your latest example: It could more simply state: (s) Sequence has algebraic factorization: 512*8^n+1 -> k = 8^3 and b = 2^3 That way, there's no need to reference gcd. But if you left it the way you did, to be mathematically accurate you'd need to say gcd > 2 since it's a Sierpinski form. Taking this a step further, when srsieve2 writes output to the screen of the nature you described, you could always state k and b in such a way that the powers are always equal. When the gcd is > 2 (> 1 for Riesel), that would always be the case. That way you could avoid mention of gcd altogether. If you stated it that way, it would be easier to understand for the less-algebraically inclined people. |
To me, it feels logical for algebraic factorizations to be output to a file in a format such as:
9*2^(2*n)-1 = (3*2^n-1)*(3*2^n+1) 25*2^(2*n)-1 = (5*2^n-1)*(5*2^n+1) If all the formulas are output like this it should be fairly easy to check that the factorizations make sense. It still wouldn't be 100% trivial for the number of ks that srbsieve ends up with at times for large conjectures but it is a good start. The output rouge mentioned probably contains the needed information but it is rather obtuse. |
All algebraic factors are written to a file that can then be input to pfgw to verify that factor.
srsieve2 generates output like this to the screen: (r) Sequence has algebraic factorization: 125*1000^n-1 -> k = 5^3 and b = 10^3 and gcd(3,3) > 1 (r) Sequence 125*1000^n-1 has 100 terms removed due to algebraic factors of the form 5*10^n*-1 (s) Sequence has algebraic factorization: 125*1000^n+1 -> k = 5^3 and b = 10^3 and gcd(3,3) > 2 (s) Sequence 125*1000^n+1 has 100 terms removed due to algebraic factors of the form 5*10^n*+1 (cr) Sequence has algebraic factorization: 729*1002^n-1 -> 729*1002^6 = (3^6*2^3*167^3)^2 (cr) Sequence 729*1002^n-1 has 0 terms removed due to algebraic factors of the form (3^6*2^3*167^3)*1002^((n-6)/2)-1 (kp) Sequence has algebraic factorization: 841*1002^n-1 -> (29^2)*1002^n-1 (kp) Sequence 841*1002^n-1 has 50 terms removed due to algebraic factors of the form 29*1002^(n/2)-1 (b2) Removed 25 algebraic factors for 81*512^n+1 of the form (3^2)*2^(n/2)-3*2^((n+2)/4))+1 when n%4=2 (p4) Removed 100 algebraic factors for 4*81^n+1 of the form (2*(3^2)^n+2*(3^1)^n+1) The algebraic factors follow the form that you see on that second line. (s) for Sierpinski also requires that gcd(x,y) != 2^n for some n > 0. It doesn't output that condition to the console. Note that I did change the text for the gcd to be > 2 for Sierpinski. Regarding Gary's example it outputs this for Riesel: (r) Sequence has algebraic factorization: 729*1024^n-1 -> k = 3^6 and b = 2^10 and gcd(6,10) > 1 (r) Sequence 729*1024^n-1 has 100 terms removed due to algebraic factors of the form 27*32^n*-1 and this for Sierpinski: (kp) Sequence has algebraic factorization: 729*1024^n+1 -> (9^3)*1024^n+1 (kp) Sequence 729*1024^n+1 has 33 terms removed due to algebraic factors of the form 9*1024^(n/3)+1 |
I have released 2.5.1. Here are the changes:
[code] twinsieve: version 1.6.3 Fix issue when continuing a sieve from an input file. xyyxsieve/xyyxsievecl: version 2.2 Fix issue when using sparse terms where terms are not counted correctly. srsieve2/srsieve2cl: version 1.7.3 Refactored algebraic factorization code to avoid issues that plagued previous builds. [/code] |
MTSIEVE\TEST1>srsieve2.exe -P 1000000000 -n 500000 -N 1000000 -W 8 -l 5e9 -s"3*10^n+1" -s"4*10^n+1" -s"8*10^n+1" -s"9*10^n+1" -f B
[B][COLOR="Red"]srsieve2 v1.7.3[/COLOR][/B], a program to find factors of k*b^n+c numbers for fixed b and variable k and n (p4) Removed 125001 algebraic factors for 4*10^n+1 of the form (2*10^(n/2)+2*10^(n/4)+1) (kp) Sequence has algebraic factorization: 8*10^n+1 -> (2^3)*10^n+1 (kp) Sequence 8*10^n+1 has 166667 terms removed due to algebraic factors of the form 2*10^(n/3)+1 Sieving with generic logic for p >= 3 Sieve started: 3 <= p <= 1e9 with 1708336 terms (500000 <= n <= 1000000, k*10^n+1) (expecting 1617771 factors) Sequence 8*10^n+1 removed as all terms have a factor Sieving with multi-sequence c=1 logic for p >= 257 BASE_MULTIPLE = 2, POWER_RESIDUE_LCM = 720, LIMIT_BASE = 720 Split 3 base 10 sequences into 108 base 10^60 sequences. Legendre summary: Approximately 14 bytes needed for Legendre tables 3 total sequences 3 are eligible for Legendre tables 0 are not eligible for Legendre tables 2 have Legendre tables in memory 1 cannot have Legendre tables in memory 0 have Legendre tables loaded from files 2 required building of the Legendre tables And just exit.... Without -l option works ok! |
[QUOTE=pepi37;633331]MTSIEVE\TEST1>srsieve2.exe -P 1000000000 -n 500000 -N 1000000 -W 8 -l 5e9 -s"3*10^n+1" -s"4*10^n+1" -s"8*10^n+1" -s"9*10^n+1" -f B
[B][COLOR="Red"]srsieve2 v1.7.3[/COLOR][/B], a program to find factors of k*b^n+c numbers for fixed b and variable k and n (p4) Removed 125001 algebraic factors for 4*10^n+1 of the form (2*10^(n/2)+2*10^(n/4)+1) (kp) Sequence has algebraic factorization: 8*10^n+1 -> (2^3)*10^n+1 (kp) Sequence 8*10^n+1 has 166667 terms removed due to algebraic factors of the form 2*10^(n/3)+1 Sieving with generic logic for p >= 3 Sieve started: 3 <= p <= 1e9 with 1708336 terms (500000 <= n <= 1000000, k*10^n+1) (expecting 1617771 factors) Sequence 8*10^n+1 removed as all terms have a factor Sieving with multi-sequence c=1 logic for p >= 257 BASE_MULTIPLE = 2, POWER_RESIDUE_LCM = 720, LIMIT_BASE = 720 Split 3 base 10 sequences into 108 base 10^60 sequences. Legendre summary: Approximately 14 bytes needed for Legendre tables 3 total sequences 3 are eligible for Legendre tables 0 are not eligible for Legendre tables 2 have Legendre tables in memory 1 cannot have Legendre tables in memory 0 have Legendre tables loaded from files 2 required building of the Legendre tables And just exit....[/QUOTE] I'll look into this. |
[QUOTE=pepi37;633331]MTSIEVE\TEST1>srsieve2.exe -P 1000000000 -n 500000 -N 1000000 -W 8 [B][U]-l 5e9[/U][/B] -s"3*10^n+1" -s"4*10^n+1" -s"8*10^n+1" -s"9*10^n+1" -f B
[COLOR="Gray"][B]srsieve2 v1.7.3], a program to find factors of k*b^n+c numbers for fixed b and variable k and n (p4) Removed 125001 algebraic factors for 4*10^n+1 of the form (2*10^(n/2)+2*10^(n/4)+1) (kp) Sequence has algebraic factorization: 8*10^n+1 -> (2^3)*10^n+1 (kp) Sequence 8*10^n+1 has 166667 terms removed due to algebraic factors of the form 2*10^(n/3)+1 Sieving with generic logic for p >= 3 Sieve started: 3 <= p <= 1e9 with 1708336 terms (500000 <= n <= 1000000, k*10^n+1) (expecting 1617771 factors) Sequence 8*10^n+1 removed as all terms have a factor Sieving with multi-sequence c=1 logic for p >= 257 BASE_MULTIPLE = 2, POWER_RESIDUE_LCM = 720, LIMIT_BASE = 720 Split 3 base 10 sequences into 108 base 10^60 sequences.[/COLOR] Legendre summary: Approximately 14 bytes needed for Legendre tables 3 total sequences 3 are eligible for Legendre tables 0 are not eligible for Legendre tables 2 have Legendre tables in memory 1 cannot have Legendre tables in memory 0 have Legendre tables loaded from files 2 required building of the Legendre tables And just exit.... Without -l option works ok![/QUOTE] I have seen this before also. It happens when I do not allocate enough memory for the "building" of the tables. You have 5e9 in your command line. Increase it to 50e9. If it still fails, keep increasing it. |
[QUOTE=henryzz;633293]The output rouge mentioned probably contains the needed information but it is rather obtuse.[/QUOTE]
I'm not sure obtuse is the word you're looking for there. I don't think it is being annoyingly insensitive or irritatingly slow to understand. Perhaps it's used a little differently across the pond. :-) I feel like obscure fits a bit better. It's maybe a bit obscure for a non-math person. ...anyway, off on my grammar rambling for the day. |
[QUOTE=pepi37;633331]MTSIEVE\TEST1>srsieve2.exe -P 1000000000 -n 500000 -N 1000000 -W 8 -l 5e9 -s"3*10^n+1" -s"4*10^n+1" -s"8*10^n+1" -s"9*10^n+1" -f B
[/QUOTE] A small hint, you could put all sequences in an inputfile like remain.txt srsieve2.exe -P 1000000000 -n 500000 -N 1000000 -W 8 -l 5e9 -sremain.txt -f B |
The new issues with srsieve2 (which has been around a while) is fixed in sourceforge.
|
[QUOTE=rogue;633394]The new issues with srsieve2 (which has been around a while) is fixed in sourceforge.[/QUOTE]
Thanks now it is working, with l increased to 5e13 |
[QUOTE=pepi37;633397]Thanks now it is working, with l increased to 5e13[/QUOTE]
The bug had nothing to do with the value specified by -l. When it runs it tells you how much memory it actually used. In your case it won't need that much memory and would fail if it tried to allocate more than what is physically available on your system. Think of it this way. If you don't want srsieve2 to use all available memory on your system, then use -l to limit how much it can use. If you don't care, use a large enough value with -l so that it can hold the tables without running out of system memory. |
[QUOTE=rogue;633402]The bug had nothing to do with the value specified by -l. When it runs it tells you how much memory it actually used. In your case it won't need that much memory and would fail if it tried to allocate more than what is physically available on your system.
Think of it this way. If you don't want srsieve2 to use all available memory on your system, then use -l to limit how much it can use. If you don't care, use a large enough value with -l so that it can hold the tables without running out of system memory.[/QUOTE] Only thing that is "problem " is less speed. I download latest tree from SVN, compile it and it works but in around half speed of your compiled exe... ( or maybe it is not connected to all) your exe [CODE]srsieve2.exe -P 10000000000 -n 500000 -N 1000000 -W 8 -l 5e13 -s"4*767^n+1" -s"16*767^n+1" -s"52*767^n+1" -f B srsieve2 v1.7.3, a program to find factors of k*b^n+c numbers for fixed b and variable k and n Increasing worksize to 400000 since each chunk is tested in less than a second Increasing worksize to 2000000 since each chunk is tested in less than a second p=4856215739, [B][COLOR="Red"]3.887M p/sec[/COLOR][/B], 1336231 factors found at 164.2 f/sec (last 1 min), 48.6% done. ETC 2023-06-30 17:37 [/CODE] my exe latest revision [CODE]srsieve2.exe -P 10000000000 -n 500000 -N 1000000 -W 8 -l 5e13 -s"4*767^n+1" -s"16*767^n+1" -s"52*767^n+1" -f B srsieve2 v1.7.3, a program to find factors of k*b^n+c numbers for fixed b and variable k and n Increasing worksize to 400000 since each chunk is tested in less than a second p=1428220663, [B][COLOR="red"]1.198M p/sec[/COLOR][/B], 1333856 factors found at 160.4 f/sec (last 1 min), 14.3% done. ETC 2023-06-30 17:51 [/CODE] I also noticed my exe file is around double size of your ( different compiler)? |
[QUOTE=pepi37;633404]Only thing that is "problem " is less speed. I download latest tree from SVN, compile it and it works but in around half speed of your compiled exe... ( or maybe it is not connected to all)
your exe [CODE]srsieve2.exe -P 10000000000 -n 500000 -N 1000000 -W 8 -l 5e13 -s"4*767^n+1" -s"16*767^n+1" -s"52*767^n+1" -f B srsieve2 v1.7.3, a program to find factors of k*b^n+c numbers for fixed b and variable k and n Increasing worksize to 400000 since each chunk is tested in less than a second Increasing worksize to 2000000 since each chunk is tested in less than a second p=4856215739, [B][COLOR="Red"]3.887M p/sec[/COLOR][/B], 1336231 factors found at 164.2 f/sec (last 1 min), 48.6% done. ETC 2023-06-30 17:37 [/CODE] my exe latest revision [CODE]srsieve2.exe -P 10000000000 -n 500000 -N 1000000 -W 8 -l 5e13 -s"4*767^n+1" -s"16*767^n+1" -s"52*767^n+1" -f B srsieve2 v1.7.3, a program to find factors of k*b^n+c numbers for fixed b and variable k and n Increasing worksize to 400000 since each chunk is tested in less than a second p=1428220663, [B][COLOR="red"]1.198M p/sec[/COLOR][/B], 1333856 factors found at 160.4 f/sec (last 1 min), 14.3% done. ETC 2023-06-30 17:51 [/CODE] I also noticed my exe file is around double size of your ( different compiler)?[/QUOTE] I use llvm-mingw-20220323-ucrt-x86_64 |
[QUOTE=rogue;633416]I use llvm-mingw-20220323-ucrt-x86_64[/QUOTE]
Changed to your compiler, reduce file size, but speed, remain slow. I will wait your release :) |
[QUOTE=pepi37;633423]Changed to your compiler, reduce file size, but speed, remain slow.
I will wait your release :)[/QUOTE] I have no explanation. Are the file sizes the same? Is the speed as slow as with your build using the other compiler? |
[QUOTE=rogue;633426]I have no explanation. Are the file sizes the same? Is the speed as slow as with your build using the other compiler?[/QUOTE]
After installing GMP got same speed as your build Thanks |
[QUOTE=pepi37;633428]After installing GMP got same speed as your build
Thanks[/QUOTE] That's weird. Not certain why. GMP isn't used by srsieve2. |
[QUOTE=rogue;633446]That's weird. Not certain why. GMP isn't used by srsieve2.[/QUOTE]
First I have to say sorry if I was boring. I try to learn to compile so I made many errors, since I was tired, etc etc... I have many errors in compile process, but as always be ,morning is smarter then evening :) Today I try many llmv compilers, and as you say, some one is working someone is not. I found that llvm-mingw-20220323-ucrt-x86_64-3.543.zip , llvm-mingw-20220906-ucrt-x86_64-386.zip and llvm-mingw-20230320-ucrt-x86_64-326.zip working ok, create srsieve2 ok and have same speed as your build. Maybe fastest build was from llvm-mingw-20220906-ucrt-x86_64-386 (386 at the end show 3.86 MP/sec) Also I confirm that MSYS64 create double size exe file but doesnot have speed as build from llvm Also MSYS64 show this warning ( not error) [CODE]sierpinski_riesel/GenericSequenceHelper.cpp:114:13: warning: variable 'A' set but not used [-Wunused-but-set-variable] 114 | uint32_t A[9], P[9], M[9], i, k, t;[/CODE] And last my error: why I dont have speed from your build, I forget to add -l switch to command to start srsieve2 :) P.S and as you say I dont need GMP at all, I make test build without GMP dir and speed is same. |
gcwsieve bug
[code]
gcwsieve -W16 -P10e14 -Ogcwfactors.txt -n299830 -N299840 -b145 -s- gcwsieve v1.5.2, a program to find factors numbers of the form n*b^n+1 and n*b^n-1 5 terms removed because the term is even Sieve started: 3 <= p <= 1e15 with 6 terms (299830 <= n <= 299840, n*145^n-1) (expecting 6 factors) Increasing worksize to 1600000 since each chunk is tested in less than a second Increasing worksize to 160000000 since each chunk is tested in less than a second Decreasing worksize to 10000000 since each chunk needs more than 5 seconds to test p=59305138787, 42.31M p/sec, 4 factors found at 216 sec per factor (last 1 min), 0.0% done. ETC 2023-07-13 10:13 [/code] One of the remaining terms (299832) has a small factor 7 which the program does not detect. |
[QUOTE=Citrix;633467][code]
gcwsieve -W16 -P10e14 -Ogcwfactors.txt -n299830 -N299840 -b145 -s- gcwsieve v1.5.2, a program to find factors numbers of the form n*b^n+1 and n*b^n-1 5 terms removed because the term is even Sieve started: 3 <= p <= 1e15 with 6 terms (299830 <= n <= 299840, n*145^n-1) (expecting 6 factors) Increasing worksize to 1600000 since each chunk is tested in less than a second Increasing worksize to 160000000 since each chunk is tested in less than a second Decreasing worksize to 10000000 since each chunk needs more than 5 seconds to test p=59305138787, 42.31M p/sec, 4 factors found at 216 sec per factor (last 1 min), 0.0% done. ETC 2023-07-13 10:13 [/code] One of the remaining terms (299832) has a small factor 7 which the program does not detect.[/QUOTE] I will look into it. |
[QUOTE=rogue;633300](b2) Removed 25 algebraic factors for 81*512^n+1 of the form (3^2)*2^(n/2)-3*2^((n+2)/4))+1 when n%4=2
[/QUOTE] I have seen these pop out of srsieve2 before and am always somewhat amazed by the Aurifeuillean factorizations that eliminate only n==(2mod4). It is a very cool example of the implementation of such factors. I'm thinking out loud to convince myself of this. Maybe it'll help others think through it too. Aurifeuillean factors would make the form k*b^n+1 always composite if k = 4*f^4 and b = g^4. 2500*16^n+1 is an example. For 81*512^n+1, then k = f^4 and b = 2*g^4, which doesn't quite fit the bill for all n. Since k is already a 4th power and is unaffected by n then we can simply set k=1 and the rest of the form must be 4*g^4+1 for such factors to be there. So with k=1, we have: n=1: (2*g^4)^1 + 1 = 2g^4 + 1 nope n=2: (2*g^4)^2 + 1 = 4g^8 + 1 = 4*(g^2)^4 + 1 there we go! n=3: (2^g^4)^3 + 1 = 8g^12 + 1 = 4*(2^1)*(g^3)^4 + 1 nope n=4: (2^g^4)^4 + 1 = 16g^16 + 1 = 4*(2^2)*(g^4)^4 + 1 nope n=5: (2^g^4)^5 + 1 = 32g^20 + 1 = 4*(2^3)*(g^5)^4 + 1 nope n=6: (2^g^4)^6 + 1 = 64g^24 + 1 = 4*(2^4)*(g^6)^4 + 1 there it is! n == (2 mod 4) does the trick! Very nice. :smile: |
I'm happy to report that after much testing, srsieve2 1.7.3 looks correct for all algebraic factorizations. :smile:
|
[QUOTE=gd_barnes;633488]I'm happy to report that after much testing, srsieve2 1.7.3 looks correct for all algebraic factorizations. :smile:[/QUOTE]
Hip hip hooray :bow: :bow: :bow: |
I found the cause of the gcwsieve issue Citrix found. It only impacts the second term in the range. It occurs because an index is decremented twice before entering a loop rather than once.
|
I just released 2.5.2. Here are the changes:
[code] framework: Fixed factor rate calculation to exclude time used prior to sieving. gcwsieve/gcwsivecl: version 1.5.3 Fix bug where the second term is skipped when testing small primes. srsieve2/srsieve2cl: version 1.7.4 Added -a to output algebraic factorizations and terminate without sieving. Add support for 'p' at the end of the -n argument to limit n to primes between min and max n. [/code] -a was actually added to 1.7.3, but I forgot to include in the release notes. The other change for srsieve2 is to better support generalized repunits in the form (b^n-1)/(b-1) and (b^n+1)/(b+1). For example for base 10 you would use this command line: srsieve2 -s"(1*10^n-1)/9" -n1e6p -N1e7 -P1e10 Unfortunately I ran into a new bug when using Legendre tables with both +1 and -1 concurrently. I will eventually fix that. Either work fine by themselves. Both work fine when not using Legendre tables |
[QUOTE=rogue;633572]Unfortunately I ran into a new bug when using Legendre tables with both +1 and -1 concurrently. I will eventually fix that. Either work fine by themselves. Both work fine when not using Legendre tables[/QUOTE]
This is fixed in sourceforge. It can cause srsieve2 to terminate with an invalid factor or cause srsieve2 to miss factors, but this only applies to using Legendre tables with multiple sequences. For this test it was about 25% faster than sr2sieve, but I alse see that it is missing about 1% of the factors that sr2sieve finds. I need to investigate that. Sigh! |
[QUOTE=rogue;633584]This is fixed in sourceforge. It can cause srsieve2 to terminate with an invalid factor or cause srsieve2 to miss factors, but this only applies to using Legendre tables with multiple sequences.
For this test it was about 25% faster than sr2sieve, but I also see that it is missing about 1% of the factors that sr2sieve finds. I need to investigate that. Sigh![/QUOTE] Clarification: It only misses factors with Legendre tables if it is sieving multiple sequences of both -1 and +1 forms but it does not miss factors if only sieving -1 sequences by themselves or if it is only sieving +1 sequences by themselves. Is that correct? |
[QUOTE=gd_barnes;633604]Clarification: It only misses factors with Legendre tables if it is sieving multiple sequences of both -1 and +1 forms but it does not miss factors if only sieving -1 sequences by themselves or if it is only sieving +1 sequences by themselves. Is that correct?[/QUOTE]
All I know is that it is an issue with multiple sequences when using Legendre tables. Could it be because +1 and -1 are combined? Possibly, but I don't know at this time. |
Mark does you know if any prime is found using k1b2sieve and kbbsieve?
|
[QUOTE=pepi37;633671]Mark does you know if any prime is found using k1b2sieve and kbbsieve?[/QUOTE]
k1b2sieve is a a specialized sieve for fkbnsieve. Most PRPs found using k1b2sieve cannot be proven prime with today's algorithms/technology. I do not know if anyone has found primes with kbbsieve. |
[QUOTE=rogue;633584]I also see that it is missing about 1% of the factors that sr2sieve finds. I need to investigate that. Sigh![/QUOTE]
This bug only impacts sequences where d > 1. The source is fixed in sourceforge. |
So now to take latest source, compile it, and have bugfree app for sieving with full speed and leng tables 😀
|
| All times are UTC. The time now is 04:17. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2023, Jelsoft Enterprises Ltd.