Compiling Phrot

[rogue]

Originally Posted by mdettweiler

Hmm...I see. So, when it reduces the base due to a rounding error, does that mean that it's not doing a base 3 test any more, and thus the final result won't be compatible with LLR?

BTW, the "reducing base" message is an 0.51 feature, not a 0.50 feature. 0.50 will finish the test even though the maxerr has reached 0.5000. 0.51 will stop immediately.

phrot is saying that the maxerr exceeded 0.5000 and that it has to reduce the base (from 1594323 to 531441 to 177147, which are all powers of 3) to get the error under 0.5000. If the maxerr reaches 0.5000, then the PRP test will be considered a failure, i.e. incorrect final result. In my experiences with phrot, this is only an issue with bases that are powers of 2 and I would guess that when k is a power of 2 that it also has an issue. The best option might be to just have phrot not perform the test in these circumstances. You can get it to work, but you need to adjust the value for -a to reduce that base. Personally I would rather not screw around trying to get phrot to work (for these numbers) and would use LLR instead.

Phil has not spent much time on the issue. I suspect the bug really lies in YEAFFT (an undetected overflow or underflow), but Guillermo has never responded to my inquiries. Phil is probably the most capable person to find the real cause of the problem and fix it.

[Cruelty]

Here's a final summary:

PRP
2*3^395004-1 is not prime.  RES64: 9C449D92F2BA7CC8.  OLD64: C214EADD85530CF4
2*3^395006-1 is not prime.  RES64: CAEC92FA11986CAC.  OLD64: 60C5B8EE34C94601

LLR
2*3^395004-1 is not prime.  RES64: 9C449D92F2BA7CC8.  OLD64: C214EADD85530CF4  Time : 1888.625 sec.
2*3^395006-1 is not prime.  RES64: CAEC92FA11986CAC.  OLD64: 60C5B8EE34C94601  Time : 1877.681 sec.

Phrot
2*3^395004-1 [-765338,-352545,278355,-34009] is composite LLR64=8dab4c98fe311ea5. (t=1377.47s)
2*3^395006-1 [482334,680402,-572288,-554118] is composite LLR64=14fad53b089f5bbc. (t=1407.36s)

Phrot -a1
2*3^395004-1 [-765338,-352545,278355,-34009] is composite LLR64=8dab4c98fe311ea5. (t=1359.25s)
2*3^395006-1 [482334,680402,-572288,-554118] is composite LLR64=14fad53b089f5bbc. (t=1357.48s)

Phrot -a2
2*3^395004-1 [-765338,-352545,278355,-34009] is composite LLR64=8dab4c98fe311ea5. (t=1376.84s)
2*3^395006-1 [482334,680402,-572288,-554118] is composite LLR64=14fad53b089f5bbc. (t=1373.75s)

PRP and LLR residues match, and Phrot regardless of the options used generates bad residue.

[axn]

Hmm... Explicitly running the "reduced" form in 0.50

phrot.50.exe -b=3 -q "486*177147^35909-1"
Actually testing 486*177147^35909-1 (35910/73728 limbs)
486*177147^35909-1 [-59983,508,76549,-40851] is composite LLR64=9C449D92F2BA7CC8. (e=0.27984 (0.00550104~4.7058e-14@1.955) t=3338.61s)

[rogue]

Originally Posted by axn1

Hmm... Explicitly running the "reduced" form in 0.50

phrot.50.exe -b=3 -q "486*177147^35909-1"
Actually testing 486*177147^35909-1 (35910/73728 limbs)
486*177147^35909-1 [-59983,508,76549,-40851] is composite LLR64=9C449D92F2BA7CC8. (e=0.27984 (0.00550104~4.7058e-14@1.955) t=3338.61s)

I've sent an e-mail to Phil. We'll see if he has anything to offer on this issue.

[mdettweiler]

Originally Posted by rogue

BTW, the "reducing base" message is an 0.51 feature, not a 0.50 feature. 0.50 will finish the test even though the maxerr has reached 0.5000. 0.51 will stop immediately.

phrot is saying that the maxerr exceeded 0.5000 and that it has to reduce the base (from 1594323 to 531441 to 177147, which are all powers of 3) to get the error under 0.5000. If the maxerr reaches 0.5000, then the PRP test will be considered a failure, i.e. incorrect final result. In my experiences with phrot, this is only an issue with bases that are powers of 2 and I would guess that when k is a power of 2 that it also has an issue. The best option might be to just have phrot not perform the test in these circumstances. You can get it to work, but you need to adjust the value for -a to reduce that base. Personally I would rather not screw around trying to get phrot to work (for these numbers) and would use LLR instead.

Phil has not spent much time on the issue. I suspect the bug really lies in YEAFFT (an undetected overflow or underflow), but Guillermo has never responded to my inquiries. Phil is probably the most capable person to find the real cause of the problem and fix it.

Ah, I get it now--it seems that there are a number of different contexts in which the word "base" is used to describe various aspects of PRP testing, that was the source of my confusion.

[geoff]

phrot-0.51-bin.zip includes the error-checking (*_e) executables too.

[Cruelty]

Is it OK to assume that running the error-checking version of Phrot is safe in terms of getting correct results? In my case (2*3^n-1 and 4*3^n-1) it is still faster than LLR/PRP by ~6% and results are OK too

[rogue]

Originally Posted by Cruelty

Is it OK to assume that running the error-checking version of Phrot is safe in terms of getting correct results? In my case (2*3^n-1 and 4*3^n-1) it is still faster than LLR/PRP by ~6% and results are OK too

If running 0.51, yes, but not 0.50. I modified the error checking version of 0.51 to consider maxerr over 0.40 to be a bad test rather than the customary 0.50. That is because I was getting invalid results when maxerr was > 0.40 and < 0.50. I don't know what the true lower bound for a bad test is, but I presume that it was closer to 0.45 or a little higher. I probably decided to be too cautious, but I would rather error on the side of caution than not.

[nuggetprime]

I've managed to compile phrot myself on my quad and it seems to don't produce the reported errors.My version is also ~28 percent faster than Geoff's port.

--nuggetprime

[Flatlander]

Originally Posted by nuggetprime

I've managed to compile phrot myself on my quad and it seems to don't produce the reported errors.My version is also ~28 percent faster than Geoff's port.

--nuggetprime

Would it be possible to compile it with a StopOnPRP option? It could then be used instead of cLLR here:
http://mersenneforum.org/showthread.php?t=10864

[nuggetprime]

Originally Posted by Flatlander

Would it be possible to compile it with a StopOnPRP option? It could then be used instead of cLLR here:
http://mersenneforum.org/showthread.php?t=10864

let me experiment...

--nuggetprime