![]() |
hi,
I do like to reserve base=6 n=1 to 50000 for double checking |
hi,
cksieve v1.1.0 gives out a warning - what does it means? [CODE] cksieve -P20e10 -i ck.in cksieve 1.1.0 -- A sieve for Carol (b^n-1)^2-2 and Kynea (b^n+1)^2-2 numbers. Read 16432 terms for (74^n+/-c)^2-2 from ABC file `ck.in'. cksieve 1.1.0 started: 3 <= n <= 99999, 60000000000 <= p <= 200000000000 p=77153080019, 141204 p/sec, 150 factors, 12.3% done, 0 sec/factor, ETA 18 Apr 08:19 WARNING: 393216 is not a root (mod 77309411329) p=81621680057, 141347 p/sec, 190 factors, 15.4% done, 0 sec/factor, ETA 18 Apr 08:19 [/CODE] |
[QUOTE=lalera;431815]hi,
cksieve v1.1.0 gives out a warning - what does it means? [CODE] cksieve -P20e10 -i ck.in cksieve 1.1.0 -- A sieve for Carol (b^n-1)^2-2 and Kynea (b^n+1)^2-2 numbers. Read 16432 terms for (74^n+/-c)^2-2 from ABC file `ck.in'. cksieve 1.1.0 started: 3 <= n <= 99999, 60000000000 <= p <= 200000000000 p=77153080019, 141204 p/sec, 150 factors, 12.3% done, 0 sec/factor, ETA 18 Apr 08:19 WARNING: 393216 is not a root (mod 77309411329) p=81621680057, 141347 p/sec, 190 factors, 15.4% done, 0 sec/factor, ETA 18 Apr 08:19 [/CODE][/QUOTE] There is a piece of code that finds x such at x^2 = 2 (mod p). Sometimes (and I mean rarely) it returns x where x^2 = -2 (mod p). I haven't looked into. Chances are well under 1 in a million that a factor is missed because of this. |
Incidentally, that output also show another bug. The factor removal rate is always "0 sec/factor".
|
...and the ETA seems way off. Or it may be in the wrong timezone (but not UTC, as one could immediately expect).
|
[QUOTE=Batalov;431844]...and the ETA seems way off. Or it may be in the wrong timezone (but not UTC, as one could immediately expect).[/QUOTE]
ETA is fine. It is in local timezone. It is the p/sec that is quirky. I believe it is counting actual p's being processed, rather than the p-range being processed (i.e. if it crunched from p=1e9 to p=2e9, it counts it as pi(2e9)-pi(1e9) p's processed rather than a range of 1e9 processed). |
[QUOTE=axn;431832]Incidentally, that output also show another bug. The factor removal rate is always "0 sec/factor".[/QUOTE]
I noticed that too. It shouldn't be too hard to fix. |
[QUOTE=axn;431847]ETA is fine. It is in local timezone. It is the p/sec that is quirky. I believe it is counting actual p's being processed, rather than the p-range being processed (i.e. if it crunched from p=1e9 to p=2e9, it counts it as pi(2e9)-pi(1e9) p's processed rather than a range of 1e9 processed).[/QUOTE]
Correct. I treat "p/sec" as the number of primes tested per second not the size of the range sieved per second. If I were to use the latter, I wouldn't call it "p/sec" as that is misleading (IMO). ETA and removal rate should be all that one cares about. |
In the first post I updated to fix the factor removal rate.
|
[QUOTE=axn;432017]All proven primes, and available in factordb (the larger ones apparently cannot be proven in factordb, even though N+1 is adequately factored).[/QUOTE]
I noticed a kludge to get numbers > 30,000 digits (ostensibly, the default limit) proven: Step 1. We can submit e.g. (40^40778+1)^2-2 -- as (40^40778+2)*40^40778-1 Step 2. Submit for PRP test. Because it has a ...-1 form, N+1 test is also run (or at least I thin this is how it happens). Then we can query for [URL="http://factordb.com/index.php?id=1100000000834232306"](40^40778+1)^2-2[/URL] and because this is a shorter form it sticks. And it shows as a P. |
[QUOTE=Batalov;432024]I noticed a kludge to get numbers > 30,000 digits (ostensibly, the default limit) proven:
Step 1. We can submit e.g. (40^40778+1)^2-2 -- as (40^40778+2)*40^40778-1 Step 2. Submit for PRP test. Because it has a ...-1 form, N+1 test is also run (or at least I thin this is how it happens). Then we can query for [URL="http://factordb.com/index.php?id=1100000000834232306"](40^40778+1)^2-2[/URL] and because this is a shorter form it sticks. And it shows as a P.[/QUOTE] :tu: This is good to know. Nothing can be done about the ones already reported, but I will use this trick for any future finds. |
All times are UTC. The time now is 18:41. |
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2023, Jelsoft Enterprises Ltd.