Prime95 version 29.4

[GP2]

Originally Posted by theonetruepath

So I'm hoping Microsoft will come to the party with a hotfix to enable AVX-512 in Windows 7...

I think that is a forlorn hope.

"Mainstream support" for Windows 7 ended in January 2015, and it is now on "extended support" until January 2020.

"Extended support", in Microsoft-speak, means they aren't adding any new features.

[PhilF]

In case it hasn't already been reported, I noticed that while performing Fermat ECM work that the program will stop the worker to perform needed benchmarks, but then not perform any, then immediately restart the worker.

[kriesel]

Originally Posted by GP2

I think that is a forlorn hope.

"Mainstream support" for Windows 7 ended in January 2015, and it is now on "extended support" until January 2020.

"Extended support", in Microsoft-speak, means they aren't adding any new features.

When Microsoft proclaimed Windows X forever, they erred by 3.

[MrRepunit]

Hi, I just noticed that the PRP test in prime95/mprime seems to be broken since version 29.4 (at least on Linux 64 Bit).
Test cases for the worktodo.txt (all should be prime):

PRP=1,10,19,-1,"9"
PRP=1,10,23,-1,"9"
PRP=1,10,317,-1,"9"
PRP=1,10,1031,-1,"9"
PRP=1,10,49081,-1,"9"
PRP=1,10,86453,-1,"9"
PRP=1,10,109297,-1,"9"
PRP=1,10,270343,-1,"9"

latest 29.3 works fine, 29.4b8 and 29.5b5 give composites as results with the following example output:

10^270343-1/9 is not prime.  Type-5 RES64: 8E38E38E38E38E39

My guess is an off-by-one error in the iteration count.

[GP2]

Originally Posted by MrRepunit

Hi, I just noticed that the PRP test in prime95/mprime seems to be broken since version 29.4 (at least on Linux 64 Bit).

Type 5 residues don't work in 29.4, except for Wagstaff (and for Mersenne, type 1 and type 5 are the same thing). I reported the problem a while ago.

Type 1 residues do work, and since there is no Gerbicz error checking for repunits other than Mersenne (b=2) and Wagstaff (b=−2), there is no advantage to using type 5 for any bases other than Mersenne and Wagstaff.

You can get type 1 residues with PRP base = 3 by specifying, for example:

PRP=1,10,19,-1,"9",99,0,3,1

For type 5 you can change the ,99,0,3,1 to ,99,0,3,5 or just omit it entirely.


The drawback is that the numerical value of a non-zero type-1 residue will be entirely different from the non-zero type-5 residue for the same composite Mersenne number. So you can't mix and match results for the two residue types.



In 29.4, for the exponent 19 I got the type 5 residue 0x7B5BAD595E238E39, which is 8888888888888888889 in decimal.

By reverse engineering, I figured out what mprime 29.4 is actually calculating when it calculates residues:

zero = mpz(0)
one = mpz(1)
minus_two = mpz(-2)

b = mpz(args.repunit)              # 10
a = mpz(args.prp_base)             # 3

t = args.bit_length                # 64
pow2_t = mpz(1<<t)

        if b > zero:
            mp_numer = b**p - one
            mp_denom = b - one
            mp_ratio = mp_numer // mp_denom
            if args.residue_type == 1:
                res = pow(a, mp_ratio - one, mp_ratio) % pow2_t
            elif args.residue_type == 5:
                res = pow(a, mp_ratio - one, mp_numer) % pow2_t
        else:
            mp_numer = (-b)**p + one
            mp_denom =  -b + one
            mp_ratio = mp_numer // mp_denom
            if args.residue_type == 1:
                res = pow(a, mp_ratio - one, mp_ratio) % pow2_t
            elif args.residue_type == 5 and b != minus_two:
                res = pow(a, mp_ratio - one, mp_numer) % pow2_t
            elif args.residue_type == 5 and b == minus_two:
                res = pow(a, mp_numer - one, mp_numer) % pow2_t

[PhilF]

Hmmm. While doing a 50M double check, I just got a Jacobi error. After it was finished checking through backup files, it reported the chances of a good test as "fair".

The test is 50% done. After I investigate and decide the hardware is fixed, should I start the test over and lose 5 days for sure, or should I let it finish and lose 10 days, but only if the test turns out to be bad?

[Mark Rose]

Originally Posted by PhilF

Hmmm. While doing a 50M double check, I just got a Jacobi error. After it was finished checking through backup files, it reported the chances of a good test as "fair".

The test is 50% done. After I investigate and decide the hardware is fixed, should I start the test over and lose 5 days for sure, or should I let it finish and lose 10 days, but only if the test turns out to be bad?

With one error, I'd let it run. If you see multiple errors in a run, I'd switch the machine to PRP work.

[Uncwilly]

That is what DC's are for, checking on machines.

[Prime95]

Originally Posted by Mark Rose

I'd switch the machine to PRP work.

Switch the machine to PRP testing for all future tests.

[LaurV]

Originally Posted by PhilF

The test is 50% done.<...> should I start the test over and lose 5 days for sure, or should I let it finish and lose 10 days, but only if the test turns out to be bad?

The "confidence" of the check is 50%, so your chances are equal, either way. You have 100% lose 5 days or 50% lose 10 days, hehe.You don't know what happens if you start again, it may repeat some error (the chances are not 100% to be successful, you may lose the 5 days, plus some other in the future, but of course, that was only a joke, because it sounded funny).


I would let it finish. And after, switch to PRP testing (where the error check is more robust), at least for next few exponents, to be sure the hardware is really fixed.

[GP2]

I can't remember if I asked this before, but...

We can't do PRP base 2 for Mersenne or Wagstaff testing, so by default we choose PRP base 3.

However, for other choices of b in k*b^n+c, we could use PRP base 2.

For instance, for repunits using b=10, we could use either PRP base 2 or base 3 (or others).

Would there be any speed advantage to using PRP base 2 over base 3?