Carol / Kynea Coordinated Search - Reservations

[lalera]

hi,
I do like to reserve base=6
n=1 to 50000
for double checking

[lalera]

hi,
cksieve v1.1.0 gives out a warning - what does it means?

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

[rogue]

Originally Posted by lalera

hi,
cksieve v1.1.0 gives out a warning - what does it means?

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

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.

[axn]

Incidentally, that output also show another bug. The factor removal rate is always "0 sec/factor".

[Batalov]

...and the ETA seems way off. Or it may be in the wrong timezone (but not UTC, as one could immediately expect).

[axn]

Originally Posted by Batalov

...and the ETA seems way off. Or it may be in the wrong timezone (but not UTC, as one could immediately expect).

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).

[rogue]

Originally Posted by axn

Incidentally, that output also show another bug. The factor removal rate is always "0 sec/factor".

I noticed that too. It shouldn't be too hard to fix.

[rogue]

Originally Posted by axn

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).

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.

[rogue]

In the first post I updated to fix the factor removal rate.

[Batalov]

Originally Posted by axn

All proven primes, and available in factordb (the larger ones apparently cannot be proven in factordb, even though N+1 is adequately factored).

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 (40^40778+1)^2-2 and because this is a shorter form it sticks. And it shows as a P.

[axn]

Originally Posted by Batalov

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 (40^40778+1)^2-2 and because this is a shorter form it sticks. And it shows as a P.

This is good to know. Nothing can be done about the ones already reported, but I will use this trick for any future finds.