P4 SSE2 routine bug?

[Prime95]

Originally Posted by Prime95

I wouldn't worry about these "error" reports. The SUM(INPUTS) = SUM(OUTPUTS) test.

Upon investigation there are problems in the k*2^n-1 modulo routine when k is large and n is small. This problem affects all cpus not just P4s. I haven't worked out the exact formula for whether a particular (k,n) pair leads to trouble. In general, I wouldn't trust prp or llr for n<50.

From the descriptions in this thread, there is clearly another bug in llr. It is most likely in the code that picks the fft length to use on SSE2 enabled machines.

If you stay here, on the contrary, you only show that your behavior conflicts with your ideas...
Have fun, and just trust the man who started it all...

Wrong that is why I will not submit ranges(xxxxxx) with a P4, saying there are no other primes in this range, unless it is done with an athlon.
I am commited by perfection to get this bug right, and or expose it.

Upon investigation there are problems in the k*2^n-1 modulo routine when k is large and n is small. This problem affects all cpus not just P4s. I haven't worked out the exact formula for whether a particular (k,n) pair leads to trouble. In general, I wouldn't trust prp or llr for n<50.

Way more than n<50 George! Up to n<1000 and increasing as i test now.
And where is the proof of non- P4's reproducing this?
No one has posted such data.

Bull

[Prime95]

Originally Posted by TTn

Way more than n<50 George! Up to n<1000 and increasing as i test now. And where is the proof of non- P4's reproducing this?

Please read my entire post. For n<50, the core multiplication/modulo routines that both prp and llr use are suspect. Try WinPFGW to test these tiny numbers. For n<1000, my post states that llr still has a P4-specific bug. Until the bug is found there is no way to know which k,n combinations are affected - it may affect some much larger n values.

As to non-P4s reproducing a bug, read Thomas11's post:

The SUM(IN)/SUM(OUT) errors of PRP, I found earlier on a P4, are reproduced by an Athlon XP (Win98SE) too.

[trif]

Originally Posted by TTn

Way more than n<50 George! Up to n<1000 and increasing as i test now.
And where is the proof of non- P4's reproducing this?


Bull

George is referring to the Suminputs/Sumoutputs problem, I suspect, not the additional LLR problem. I have downloaded PRP from the mersenne.org site, and I will be happy to run it on any of:

Celeron 466MHz
Duron 1GHz
Barton 2500+ (clocked to 2800+ equivalent)

With a Linux version, I could add a K6-2/400 or a Celeron 1.3 GHz. I also have a Palomino 1600+ I can set up.

I need to know how to format the input file, as the readme says it takes input from newpgen.

[Xyzzy]

http://www.teamprimerib.com/jpg/bug.jpg

Just kidding... :)

I have absolute confidence we'll all get to the bottom of this, together... No mysteries... No conspiracies... No lies... Just the truth...

[Thomas11]

Originally Posted by Prime95

I wouldn't worry about these "error" reports. The SUM(INPUTS) = SUM(OUTPUTS) test was designed with million digit multiplies in mind. We are comparing two floating point values to see if they are close to each other. Obviously, when testing real tiny numbers the FFT routines need to allow more leeway in this closeness test. I'll work on a fix.

Meanwhile I have found that PRP gives negative false reports too, on both P4 (Linux) and Athlon (Win98SE):

[code:1]
31071987*2^25-1 is not prime. Res64: 000376706F96719C
31072005*2^25-1 is not prime. Res64: 000097D09D225B71
971001*2^30-1 is a probable prime.
[/code:1]

All three numbers should be prime and Proth finds them, as well as PFGW and LLR too.

Thomas.