Compiling Phrot

[rogue]

Originally Posted by mdettweiler

Hmm...yet it still performs the test just fine, and records the LLR residuals without any further error. Maybe this is actually benign? (I would certainly hope so, since that error was only outputted on the console, and much of it has since scrolled off and I thus have absolutely no idea which of the numbers in the file would need to potentially be re-tested.)

How about next time I see that error pop up, I re-run the same test with LLR to find out if I get the same residual?

I made a mistake, this message is produced AFTER the PRP test has completed. In that case, I suspect that the residue will not be match LLR's

[mdettweiler]

Originally Posted by rogue

I made a mistake, this message is produced AFTER the PRP test has completed. In that case, I suspect that the residue will not be match LLR's

Okay, I tried re-testing one of the ones that I got this error for, with LLR:

Tested with phrot:
61703482*3^25451-1 [153006,-5552,662012,385981] is composite LLR64=300e26fb1af35c68. (t=8.42s)

Tested with LLR:
61703482*3^25451-1 is not prime. RES64: 300E26FB1AF35C68. OLD64: 902A74F150DA1535 Time : 16.703 sec.

Interesting...it seems to match just fine. Maybe this error is actually benign after all?

[rogue]

Originally Posted by mdettweiler

Okay, I tried re-testing one of the ones that I got this error for, with LLR:

Tested with phrot:
61703482*3^25451-1 [153006,-5552,662012,385981] is composite LLR64=300e26fb1af35c68. (t=8.42s)

Tested with LLR:
61703482*3^25451-1 is not prime. RES64: 300E26FB1AF35C68. OLD64: 902A74F150DA1535 Time : 16.703 sec.

Interesting...it seems to match just fine. Maybe this error is actually benign after all?

That is a question that only Phil can answer.

[Cruelty]

How to compare PRP residue with Phrot?

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

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

BTW: for the example given above Phrot is ~21% faster than PRP.

[mdettweiler]

Originally Posted by Cruelty

How to compare PRP residue with Phrot?

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

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

BTW: for the example given above Phrot is ~21% faster than PRP.

You need to run phrot with the "-b=3" command line flag--that tells it to use PRP base 3, which is compatible with residuals from LLR, Prime95 v25, and PRP v3.

[Cruelty]

That's what I did, and the above is output of it... no match unfortunately

[mdettweiler]

Originally Posted by Cruelty

That's what I did, and the above is output of it... no match unfortunately

Hmm...that's weird. The only thing I can think of is an unstable machine; maybe a stress test would reveal more information here?

[Cruelty]

Machine is 100% stable
Here's what I've found in LLR readme:

-To avoid any confusion, the output line for composite numbers now shows
of which algorithm the residue is the result :

RES64: "xxxxxxxxxxxxxxxx" (PRP test)
LLR RES64: "xxxxxxxxxxxxxxxx" (LLR test)
Proth RES64: "xxxxxxxxxxxxxxxx" (Proth test)

I think I have read somewhere that PRP and LLR output were not compatible...

[mdettweiler]

Originally Posted by Cruelty

Machine is 100% stable
Here's what I've found in LLR readme:
I think I have read somewhere that PRP and LLR output were not compatible...

Well, LLR uses PRP's base code for PRP tests (i.e., non-k*2^n+-1), so they should be exactly compatible. However, maybe what you're thinking of is that PRP 2.0 and earlier is not compatible with PRP 3.0 (and, by extension, LLR)--instead, they produce residuals compatible with PRP3/LLR's "OLD64".

Theoretically, all Phrot residuals produced when run with the -b=3 switch should be exactly compatible with those produced by PRP 3.0 or LLR (that is, the "RES64", not the "OLD64"--I really have no idea what the OLD64 thing is. Maybe it's for a different PRP base?). I can't think of any plausible explanation for why your residuals aren't matching those produced by PRP.

Oh, I just thought of one possibility: where did you get your Phrot binaries? Are you using Geoff's builds, or did you compile them yourself? If you compiled them yourself, then maybe you should try Geoff's build to see if that matches up correctly--maybe something went wrong with your build for whatever reason.

[rogue]

Originally Posted by mdettweiler

Well, LLR uses PRP's base code for PRP tests (i.e., non-k*2^n+-1), so they should be exactly compatible. However, maybe what you're thinking of is that PRP 2.0 and earlier is not compatible with PRP 3.0 (and, by extension, LLR)--instead, they produce residuals compatible with PRP3/LLR's "OLD64".

Theoretically, all Phrot residuals produced when run with the -b=3 switch should be exactly compatible with those produced by PRP 3.0 or LLR (that is, the "RES64", not the "OLD64"--I really have no idea what the OLD64 thing is. Maybe it's for a different PRP base?). I can't think of any plausible explanation for why your residuals aren't matching those produced by PRP.

Oh, I just thought of one possibility: where did you get your Phrot binaries? Are you using Geoff's builds, or did you compile them yourself? If you compiled them yourself, then maybe you should try Geoff's build to see if that matches up correctly--maybe something went wrong with your build for whatever reason.

In some cases, such as those where k=2 or a power of 2, you will probably need to use a version with error checking. For example, when I use one compiled with error checking, I get:

./phrot.g5_e -b3 -q 2*3^395004-1
Input 2*3^395004-1 Actually testing 1062882*1594323^30384-1 (witness=3 30386/65536 limbs)
Reducing base due to rouding error. Actually testing 2*531441^32917-1 (witness=3 32918/73728 limbs)
Reducing base due to rouding error. Actually testing 486*177147^35909-1 (witness=3 35910/73728 limbs)

I expect a similar thing would happen on x86.

[mdettweiler]

Originally Posted by rogue

In some cases, such as those where k=2 or a power of 2, you will probably need to use a version with error checking. For example, when I use one compiled with error checking, I get:

./phrot.g5_e -b3 -q 2*3^395004-1
Input 2*3^395004-1 Actually testing 1062882*1594323^30384-1 (witness=3 30386/65536 limbs)
Reducing base due to rouding error. Actually testing 2*531441^32917-1 (witness=3 32918/73728 limbs)
Reducing base due to rouding error. Actually testing 486*177147^35909-1 (witness=3 35910/73728 limbs)

I expect a similar thing would happen on x86.

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?