Bug with LLR !! - Page 4

T.Rex · 2010-01-16, 23:05

Quote:

Originally Posted by Cruelty

On the development page I can see the 3.80 version dated 14-th of January - anyone tried it already?

I tried it: seems good ! However, Jean said that he will officialy deliver this version next week. He has some more testing to do and some more documentation to write.
Wait till he says: GO !
Tony

jrk · 2010-01-17, 04:45

Did this bug affect only Wagstaff numbers, or is it more general?

Is there a way to determine which results may be bad and need to be re-tested?

T.Rex · 2010-01-17, 07:49

Quote:

Originally Posted by jrk

Did this bug affect only Wagstaff numbers, or is it more general?

Is there a way to determine which results may be bad and need to be re-tested?

The problem was in gwnum. So it depends how the FFT computation of any number comes into the RED zone...
It's enough to add: ErrorCheck=1 in the llr.ini file. (and ... yes ! we did not use it.)
It seems that LLR does not have a ErrorCheck of result every N steps, like Prime95 has.
Tony

philmoore · 2010-01-19, 06:37

If the problem was in gwnum, it probably also affected prime95 and pfgw as well. Prime95 catches some of these errors through intermittent error checking, but others probably got through. It would be helpful to know the ranges (and FFT sizes) where this happened.

I was confused earlier where you said LLR was producing random residues. I took this to mean that the residue was different each time you ran the test, but I think you meant simply that LLR was producing incorrect residues, no?

mdettweiler · 2010-01-19, 06:46

Quote:

Originally Posted by philmoore

If the problem was in gwnum, it probably also affected prime95 and pfgw as well. Prime95 catches some of these errors through intermittent error checking, but others probably got through. It would be helpful to know the ranges (and FFT sizes) where this happened.

BTW, I think PFGW does similar intermittent error checking.

T.Rex · 2010-01-19, 09:00

Quote:

Originally Posted by philmoore

It would be helpful to know the ranges (and FFT sizes) where this happened.

(2^3251251+1)/3 - (2^3473747+1)/3

Quote:

the residue was different each time you ran the test ?

YES !

T.Rex · 2010-01-19, 09:01

Quote:

Originally Posted by mdettweiler

BTW, I think PFGW does similar intermittent error checking.

LLR did not. It will now, said Jean.

philmoore · 2010-01-19, 12:31

Good work, Tony, and good luck with your retesting!

Cruelty · 2010-02-01, 00:04

Any idea when the new LLR version will become... official?

T.Rex · 2010-02-01, 18:43

Last news is that Jean delivered a stable 3.8.0 version.
He is now working on the documentation. A lot of work, he said. I should read his work before publishing it, I proposed, and he accepted.
Wait some more.
T.

2010-01-17, 04:45	#35
jrk May 2008 3·5·73 Posts	Did this bug affect only Wagstaff numbers, or is it more general? Is there a way to determine which results may be bad and need to be re-tested?

2010-01-19, 06:37	#37
philmoore "Phil" Sep 2002 Tracktown, U.S.A. 45F₁₆ Posts	If the problem was in gwnum, it probably also affected prime95 and pfgw as well. Prime95 catches some of these errors through intermittent error checking, but others probably got through. It would be helpful to know the ranges (and FFT sizes) where this happened. I was confused earlier where you said LLR was producing random residues. I took this to mean that the residue was different each time you ran the test, but I think you meant simply that LLR was producing incorrect residues, no?

2010-01-19, 12:31	#41
philmoore "Phil" Sep 2002 Tracktown, U.S.A. 3×373 Posts	Good work, Tony, and good luck with your retesting!

2010-02-01, 00:04	#42
Cruelty May 2005 2³·7·29 Posts	Any idea when the new LLR version will become... official?

2010-02-01, 18:43	#43
T.Rex Feb 2004 France 2²·229 Posts	Last news is that Jean delivered a stable 3.8.0 version. He is now working on the documentation. A lot of work, he said. I should read his work before publishing it, I proposed, and he accepted. Wait some more. T.