20141215, 22:15  #12 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
19·23^{2} Posts 
gp> (log(1024)+ log(3)*1877301 )/log(10)
895703.21890643365300834531519767847000 895704 is correct. After some discussions with Prof.Caldwell, he indeed revived the number. I put the comment there that summarizes the evidence gathered so far. It seems something is going on with AVX portion of GWNUM lib, but the PRP test implementation in the latest P95 is not affected! maybe LLR and PFGW are not initializing something correctly up to the latest API? (like setting max mulitplier or something comes to mind) Just a note added in proof: all tests were done on ECCendowed computers, so we can rule out bad memory or memory communications. Last fiddled with by Batalov on 20141215 at 22:24 
20141215, 22:18  #13  
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
10051_{10} Posts 
Quote:
He used 3.7.7 with 27.9 gwnum, iirc, but I didn't save a screenshot. PFGW was called with t (so it is BLS N1 without preliminary PRP test) and without a1 or a2, but a bit later C.C. reported that those runs returned 'composite' too. 

20141215, 22:23  #14 
Sep 2002
Database er0rr
10607_{8} Posts 

20141215, 22:57  #15 
"Mark"
Apr 2003
Between here and the
1B30_{16} Posts 
Which version of pfgw is showing this as composite? Do you know which FFT size it selected?

20141215, 23:50  #16 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
10011101000011_{2} Posts 
It is hard to say the FFT size (the v option doesn't increase verboseness, it is for other use).
But here's my most recent run with the freshly minted PFGW (and a1): Code:
PFGW Version 3.7.8.64BIT.20141125.x86_Dev [GWNUM 28.5] Output logging to file pfgw.out Primality testing 1024*3^1877301+1 [N1, BrillhartLehmerSelfridge] Running N1 test using base 5 1024*3^1877301+1 is prime! (12669.4555s+0.0219s) Here's something we can use: my kernel data is: Linux ws2 2.6.32.120.7default #1 SMP 20100520 11:14:20 +0200 x86_64 x86_64 x86_64 GNU/Linux model name : Intel(R) Xeon(R) CPU X5660 @ 2.80GHz stepping : 2 cpu MHz : 2792.602 cache size : 12288 KB (Note: 2.6.32 means that AVX is enabled; need >= 2.6.18) EDIT: never mind that it may be enabled  this CPU is from 2010; it doesn't have AVX. Let's see what UTM Xeon server has... (e.g. using very recent data here) Using: Xeon 4c+4c 3.5GHz < Hmmm, local lingo Command: /home/caldwell/client/pfgw/pfgw64 t q"2378*3^960224+1" 2>&1 PFGW Version 3.7.7.64BIT.20130722.x86_Dev [GWNUM 27.11] Primality testing 2378*3^960224+1 [N1, BrillhartLehmerSelfridge] ... The same version was used on the last number. Last fiddled with by Batalov on 20141216 at 03:46 
20141216, 02:50  #17 
"Mark"
Apr 2003
Between here and the
1101100110000_{2} Posts 
Try V instead of v.

20141216, 03:22  #18 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
19×23^{2} Posts 
On my comp, the nonAVX 256K size is used:
Code:
Primality testing 1024*3^1877301+1 [N1, BrillhartLehmerSelfridge] Running N1 test using base 5 Special modular reduction using allcomplex Pentium4 FFT length 256K, Pass1=256, Pass2=1K on 1024*3^1877301+1 I am almost done with nonAVX LLR runs in four bases and with FFT two sizes (256K and 288K). Will update here, in an hour: Code:
1024*3^1877301+1 may be prime, but N divides 3^((N1)/3))1, restarting with a=5 Time : 9560.093 sec. Base prime factor(s) taken : 3 Starting N1 prime test of 1024*3^1877301+1 1024*3^1877301+1 may be prime, trying to compute gcd's 5^((N1)/3)1 is coprime to N! 1024*3^1877301+1 is prime! (895704 decimal digits) Time : 9524.973 sec. Base prime factor(s) taken : 3 Starting N1 prime test of 1024*3^1877301+1 1024*3^1877301+1 may be prime, trying to compute gcd's 7^((N1)/3)1 is coprime to N! 1024*3^1877301+1 is prime! (895704 decimal digits) Time : 9521.660 sec. Base prime factor(s) taken : 3 Starting N1 prime test of 1024*3^1877301+1 1024*3^1877301+1 may be prime, trying to compute gcd's 11^((N1)/3)1 is coprime to N! 1024*3^1877301+1 is prime! (895704 decimal digits) Time : 9519.687 sec. Base prime factor(s) taken : 3 Starting N1 prime test of 1024*3^1877301+1 1024*3^1877301+1 may be prime, trying to compute gcd's 1024*3^1877301+1 may be prime, but N divides 17^((N1)/3))1, restarting with a=19 Time : 9514.177 sec. Restarting N1 prime test of 1024*3^1877301+1 ... and the same results with FFT_Increment=1 (i.e. 288K FFT), only longer times, obviously Last fiddled with by Batalov on 20141216 at 04:33 Reason: nonAVX branches work fine in modern versions of code 
20141217, 20:29  #19 
Sep 2002
Database er0rr
7·641 Posts 
I get a mismatch of RES64's:
Code:
./pfgw_ver_12_linux q"2*3^90420+1" PFGW Version 1.2.0 for Pentium and compatibles [FFT v23.8] 2*3^90420+1 is composite: [3756EDC5668626CF] (47.7282s+0.0011s) Code:
./pfgw64 q"2*3^90420+1" PFGW Version 3.7.7.64BIT.20130722.x86_Dev [GWNUM 27.11] 2*3^90420+1 is composite: RES64: [7756EDC5668626CF] (8.2449s+0.0047s) Code:
./pfgw_ver_12_linux q"2*3^90421+1" PFGW Version 1.2.0 for Pentium and compatibles [FFT v23.8] ^C I get these mismatches too: Code:
./pfgw64 q"2*3^90419+1" PFGW Version 3.7.8.64BIT.20141125.x86_Dev [GWNUM 28.5] 2*3^90419+1 is composite: RES64: [17F958B71309C04A] (10.0592s+0.0003s) Code:
./pfgw64 q"2*3^90419+1" PFGW Version 3.7.7.64BIT.20130722.x86_Dev [GWNUM 27.11] 2*3^90419+1 is composite: RES64: [03FBCEF4D1C55728] (10.5805s+0.0003s) Last fiddled with by paulunderwood on 20141217 at 21:09 
20141217, 21:46  #20 
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
10051_{10} Posts 
1. Mark would appreciate if you add V to the command lines.
(Then the FFT size and AVX / nonAVX would be easily seen.) 2. By adding InterimResidues=N to llr.ini, I've found that interim residues are simply incompatible! Incompatible between different FFT sizes, and incompatible between AVX / nonAVX runs.* That is: even if the result is correct and a test is run to the end and returns "P" for e.g. 4096*3^208687+1, the interim residues are all different. The last matching row is "bit 28" (in these tests, not iterations, but bits of the exponents are being numbered). Before bit 28, the small interim residues are trivially correct, e.g. if FermatBase=5, they start with 25, 625, 390625, etc in hex. For 3, the familiar values of 9, 81, etc (or depending on the input number, one can see small odd powers of the FermatBase)... but after bit 28, all becomes incompatible (yet, of course, reproducible,  if you run the same, twice). I had not enough time last night to understand why interim residues don't match. 3. Parallel line of investigation: does Prime95based PRP work on AVX CPUs for this particular debug case (1024*3^1877301+1 **)? (In other words, is the bug simply in GWNUM, or is it in how GWNUM is used.) The answer is: yes! Prime95based PRP works fine in bases 3,5,7,11 both AVX / nonAVX. In other words, the library FFT for 224K, 256K, 288K sizes is not trivially (say a typo) broken. This is what I know so far. ______________ *Footnote: in the region of interest, that is at least above 90,000 digits input sizes. For small inputs, miraculously, interim residues are exactly identical (for numbers in the FFT ranges 3K, 4K, 5K). **I searched for a smaller example of numbers of form 2^m*3^n+1 (m<=16, n large) that would fail LLR test and didn't find. I had found these to test: 16384*3^24093+1 65536*3^200115+1 4096*3^208687+1 2048*3^229654+1 65536*3^232379+1  they all pass LLR, PFGW, Prime95 just fine; AVX or nonAVX Last fiddled with by Batalov on 20141217 at 22:00 Reason: closed paren, added more details to item 2 
20141218, 01:35  #21  
"Serge"
Mar 2008
Phi(4,2^7658614+1)/2
19×23^{2} Posts 
An additional test of George's idea is in progress.
Quote:
Indeed, LLR runs 30 rounds of guarded/careful squares in the Proth test (see line 10669 in Llr.c); I upped this number to 60 and I am rerunning. 30 and Nlen30 (and variations, e.g. 31) are used in other tests as well; all of them may need to be increased as the average sizes of prime candidates increased over last years. EDIT: this idea was a dead end; the result is the same (30 or 60 guarded iterations). What is more depressing the final "RES64" is different for different FFT sizes. Maybe I'll try to go a3, a4, a5 and so on. (in llr.ini, FFT_Increment=3,4,5...) Last fiddled with by Batalov on 20141218 at 04:36 

20141218, 04:02  #22 
Sep 2002
Database er0rr
1187_{16} Posts 
Some good news:
Code:
./pfgw64 tp i V q"1024*3^1877301+1" PFGW Version 3.7.7.64BIT.20130722.x86_Dev [GWNUM 27.11] CPU Information (From Woltman v26 library code) Intel(R) Core(TM) i74770K CPU @ 3.50GHz CPU speed: 3721.69 MHz, 4 cores CPU features: RDTSC, CMOV, Prefetch, MMX, SSE, SSE2, SSE4.1, SSE4.2 L1 cache size: 32 KB L2 cache size: 256 KB, L3 cache size: 8 MB L1 cache line size: 64 bytes L2 cache line size: 64 bytes TLBS: 64 Primality testing 1024*3^1877301+1 [N+1, BrillhartLehmerSelfridge] Running N+1 test using discriminant 5, base 5+sqrt(5) Special modular reduction using allcomplex AVX FFT length 240K, Pass1=1280, Pass2=192 on 1024*3^1877301+1 1024*3^1877301+1 is Lucas PRP! (24654.3415s+0.0223s) 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
PFGW 4.0.4 (with gwnum v30.10) Released  rogue  Software  545  20230120 14:12 
LLR V3.8.2 using gwnum 26.2 is available!  Jean Penné  Software  25  20101101 15:18 
PFGW 3.3.6 or PFGW 3.4.2 Please update now!  Joe O  Sierpinski/Riesel Base 5  5  20100930 14:07 
GWNUM?  Unregistered  Information & Answers  3  20100912 19:52 
GWNUM as DLL?  Cyclamen Persicum  Software  1  20070102 20:53 