Phrot announcements

[Shaopu Lin]

Testing the primality of Generalized Fermat number 824^1024+1 by Phrot 0.68, it shows that it is composite.

math@linux-0rdr:~/Desktop/other> phrot -q 1*824^1024+1
Phil Carmody's Phrot (0.68)
Input 1*824^1024+1 :  Actually testing 1*678976^512+1 (witness=3 513/1152 limbs)
1*824^1024+1 is composite LLR64=0000000000000001. (t=0.29s)

But doing the same test by LLR and pari-gp, LLR shows that it is probable prime and pari-gp shows that it is prime.

Here are the results doing by LLR with llr -q"1*824^1024+1",

824^1024+1 is a probable prime.  Time : 285.661 ms.
Please credit George Woltman's PRP for this result!

, and doing by pari-gp.

math@linux-0rdr:~/Desktop/other> gp
Reading GPRC: /home/math/.gprc ...Done.

                 GP/PARI CALCULATOR Version 2.4.3 (development)
          amd64 running linux (x86-64/GMP-4.2.3 kernel) 64-bit version
compiled: Mar 13 2009, gcc-4.3.2 [gcc-4_3-branch revision 141291] (SUSE Linux) 
                 (readline v5.2 enabled, extended help enabled)

                     Copyright (C) 2000-2008 The PARI Group

PARI/GP is free software, covered by the GNU General Public License, and comes 
WITHOUT ANY WARRANTY WHATSOEVER.

Type ? for help, \q to quit.
Type ?12 for how to get moral (and possibly technical) support.

parisize = 8000000, primelimit = 500509
(00:37) gp > isprime(1*824^1024+1)
%1 = 1
(00:38) gp >

[rogue]

Originally Posted by Shaopu Lin

Testing the primality of Generalized Fermat number 824^1024+1 by Phrot 0.68, it shows that it is composite.

math@linux-0rdr:~/Desktop/other> phrot -q 1*824^1024+1
Phil Carmody's Phrot (0.68)
Input 1*824^1024+1 :  Actually testing 1*678976^512+1 (witness=3 513/1152 limbs)
1*824^1024+1 is composite LLR64=0000000000000001. (t=0.29s)

I'll look into it. I suspect it has something to do with the form more than anything else.

[rogue]

An issue has been discovered in phrot 0.68 that causes it to produce incorrect residues and miss primes for various bases. I recommend that anyone using phrot to use the -e switch until this issue is resolved.

[gd_barnes]

Oh goodie. Now we need to rerun all of our tests where we had used Phrot 0.68. I'll have to see what version is running on my machine for bases 22 and 28. I've done a lot of n=100K-150K work there. Can you possibly isolate the specific conditions, residues, or patterns in the tests that created the incorrect residues? When I had a memory error in a laptop, I would frequently get the extremely small near-zero residues like what was found for the GFN test shown previously here. Perhaps I just need to look for residues with a whole bunch of leading zeros in them.

Does this apply to any other version of Phrot?

[rogue]

Originally Posted by gd_barnes

Oh goodie. Now we need to rerun all of our tests where we had used Phrot 0.68. I'll have to see what version is running on my machine for bases 22 and 28. I've done a lot of n=100K-150K work there. Can you possibly isolate the specific conditions, residues, or patterns in the tests that created the incorrect residues? When I had a memory error in a laptop, I would frequently get the extremely small near-zero residues like what was found for the GFN test shown previously here. Perhaps I just need to look for residues with a whole bunch of leading zeros in them.

Does this apply to any other version of Phrot?

AFAICT, there is no way to identify specific k/b/n/c values that have the issue. As far as I know it can happen in all versions.

I'm sorry that this is causing so many problems for people, but I'm working on getting it fixed.

[Flatlander]

Perhaps it's worth others looking at the code to try to narrow down the k/n/b/c?

Or perhaps run LLR and compare the residues to narrow it down?

[rogue]

Originally Posted by Flatlander

Perhaps it's worth others looking at the code to try to narrow down the k/n/b/c?

Or perhaps run LLR and compare the residues to narrow it down?

I'm investigating, but have nothing to relate at this time.

I do know that error checking does catch the issue. Unfortunately it slows phrot down when error checking is turned on.

[mdettweiler]

Originally Posted by gd_barnes

Oh goodie. Now we need to rerun all of our tests where we had used Phrot 0.68. I'll have to see what version is running on my machine for bases 22 and 28. I've done a lot of n=100K-150K work there. Can you possibly isolate the specific conditions, residues, or patterns in the tests that created the incorrect residues? When I had a memory error in a laptop, I would frequently get the extremely small near-zero residues like what was found for the GFN test shown previously here. Perhaps I just need to look for residues with a whole bunch of leading zeros in them.

Does this apply to any other version of Phrot?

Gary, if you're running your base 22 and 28 work on one of your quads, and you haven't upgraded Phrot on any of them since I set it up for you, then you're still using 0.51.

Not that will help matters much, though, considering that the bug could affect all versions...

[rogue]

Originally Posted by mdettweiler

Gary, if you're running your base 22 and 28 work on one of your quads, and you haven't upgraded Phrot on any of them since I set it up for you, then you're still using 0.51.

Not that will help matters much, though, considering that the bug could affect all versions...

If he is getting residues (i.e. error checking is turned on) AND phrot was built with the patched YEAFFT, then his results would be valid.

[mdettweiler]

Originally Posted by rogue

If he is getting residues (i.e. error checking is turned on) AND phrot was built with the patched YEAFFT, then his results would be valid.

Hmm...I could have sworn that version 0.51 had error checking built into a separate binary. I know that it was built with a fully patched (at least at the time--I don't think there were any further patches, right?) version of YEAFFT. Does this mean that he's vulnerable to errors?

[rogue]

Originally Posted by mdettweiler

Hmm...I could have sworn that version 0.51 had error checking built into a separate binary. I know that it was built with a fully patched (at least at the time--I don't think there were any further patches, right?) version of YEAFFT. Does this mean that he's vulnerable to errors?

If using 0.51 with a patched version of YEAFFT, no. There have been no new patches to YEAFFT.