20190810, 20:46  #408 
Just call me Henry
"David"
Sep 2007
Cambridge (GMT/BST)
16EE_{16} Posts 
My guess is that it can't cope with recursive functions. Also the nth prime function is p(n) not P(n)

20190810, 21:45  #409  
"Dylan"
Mar 2017
2×17^{2} Posts 
Quote:
I believe I see the problem in the code above. If i = 2, then the code would then need to evaluate gaporial(1)*(53) which in turn requires us to evaluate gaporial(0)*(32). But gaporial(0) = 0, so gaporial(1) = 0 and so would gaporial(2) (and consequently, for general n). When in actuality the OEIS sequence goes 1, 2, 4, 16, etc. So I need gaporial(0) to be 1 (the empty product). Then we get gaporial(1) = 1*(32)=1*1=1 gaporial(2) = 1*(53)=1*2=2 gaporial(3) = 2*(75)=2*2=4 etc. which is what I expect. Of course fixing that doesn't fix the error I have. That might be the issue  which seems strange since we use a Clike construct for the input file for the perl script. And the scriptify documentation says we use "P" for the nth prime, not p, which is used for pfgw itself. 

20190810, 21:50  #410 
Sep 2002
Database er0rr
3,677 Posts 
You might have invent a stack by way of dimensioning an array and store gaporial(1) in element 1 and so on. Then you can incrementally iterate through the array.
Hmm does this work: Code:
int i; int q; int num = 1; int gap = 1; for(i=1; i<=10000; i+=1) { num = gap * ( P(i+1)  P(i) ); gap = num; num = num+1; q = PRP(num); if(q == 1) { print(i); } } The above stops printing the index "i" in the output when switching to GMP/GWNUM  is this a bug? Code:
./pfgw64 f Dylan_script.txt PFGW Version 4.0.0.64BIT.20190528.x86_Dev [GWNUM 29.8] Script File 2 is trivially prime!: 2 1 3 is trivially prime!: 3 2 5 is trivially prime!: 5 3 17 is trivially prime!: 17 4 257 is trivially prime!: 257 7 12289 is trivially prime!: 12289 10 14155777 is trivially prime!: 14155777 15 169869313 is trivially prime!: 169869313 17 4076863489 is trivially prime!: 4076863489 19 Switching to Exponentiating using GMP 32318253138475745281 is 3PRP! (0.0000s+0.0010s) 12806790724213976503626296721408001 is 3PRP! (0.0000s+0.0023s) 307362977381135436087031121313792001 is 3PRP! (0.0000s+0.0015s) Last fiddled with by paulunderwood on 20190810 at 22:45 
20190811, 00:40  #411 
"Dylan"
Mar 2017
2×17^{2} Posts 
I can confirm the same behavior as well using the script paulunderwood provided in the previous post  it stops printing i to the screen as soon as GMP is called (it doesn't return after GWNUM is called).
In addition, per the scriptify docs, print is supposed to print to the log file, as per section 3.3.5: Code:
The print function takes a single integer variable and writes it to both the screen and the PFGW log file, appending a new line. Code:
2 3 5 17 257 12289 14155777 169869313 4076863489 32318253138475745281 12806790724213976503626296721408001 (longer ones as well which are not included here for brevity) 
20191202, 19:48  #412 
Sep 2010
Portland, OR
2^{2}·3·31 Posts 
Odd results testing repunits with pfgw 4.0.0
I couldn't find a thread on the release of PFGW v4.0.0, so posting this here  please redirect me if there is a more recent discussion.
I noticed that testing R(n) uses the generic modular reduction, while testing (10^n1)/9 uses the much faster special modular reduction. In general they give the same residue. However in a few cases, such as n=210731, running on (10^2107311)/9 gets repeated roundoff errors all the way up through a5 and fails, while R(210731) is correctly found to be composite. Is this expected? Which leads me to a second question: what is the recommended method to ensure trustable results for a number determined to be composite? The documentation seems to suggest that every check must be run twice, without a and then with a1. Is that really necessary? Is running with r sufficient? Any help appreciated. And thanks for providing a fantastic tool! 
20191202, 19:58  #413 
Sep 2002
Database er0rr
3677_{10} Posts 
The Repunit Prime Project
You might not be aware of this project for repunits. It has reached R(2,500,000).

20191202, 20:33  #414  
"Mark"
Apr 2003
Between here and the
14252_{8} Posts 
Quote:
Can you post the output from the various a options when using special modular reduction? That is probably specific to your CPU as I do not see any roundoff errors with that candidate using special modular reduction on my laptop. 

20191202, 23:04  #415  
Sep 2010
Portland, OR
2^{2}·3·31 Posts 
Quote:
Here's the special reduction output (this was run with r, but it makes no difference): Code:
pfgw64 r V 'q(10^2107311)/9' PFGW Version 4.0.0.64BIT.20190528.x86_Dev [GWNUM 29.8] Special modular reduction using AVX512 FFT length 40K, Pass1=128, Pass2=320, clm=1 on 10^2107311 Detected in MAXERR>0.45 (round off check) in prp_using_gwnum Iteration: 700001/700030 ERROR: ROUND OFF 0.5>0.45 PFGW will automatically rerun the test with a1 Special modular reduction using AVX512 FFT length 48K, Pass1=128, Pass2=384, clm=1 on 10^2107311 Detected in MAXERR>0.45 (round off check) in prp_using_gwnum Iteration: 700001/700030 ERROR: ROUND OFF 0.5>0.45 PFGW will automatically rerun the test with a2 Special modular reduction using AVX512 FFT length 56K, Pass1=128, Pass2=448, clm=1 on 10^2107311 Detected in MAXERR>0.45 (round off check) in prp_using_gwnum Iteration: 700001/700030 ERROR: ROUND OFF 0.5>0.45 PFGW will automatically rerun the test with a3 Special modular reduction using AVX512 FFT length 60K, Pass1=192, Pass2=320, clm=1 on 10^2107311 Detected in MAXERR>0.45 (round off check) in prp_using_gwnum Iteration: 700001/700030 ERROR: ROUND OFF 0.49999>0.45 PFGW will automatically rerun the test with a4 Special modular reduction using AVX512 FFT length 64K, Pass1=128, Pass2=512, clm=1 on 10^2107311 Detected in MAXERR>0.45 (round off check) in prp_using_gwnum Iteration: 700001/700030 ERROR: ROUND OFF 0.49999>0.45 PFGW will automatically rerun the test with a5 Special modular reduction using AVX512 FFT length 72K, Pass1=192, Pass2=384, clm=1 on 10^2107311 Detected in MAXERR>0.45 (round off check) in prp_using_gwnum Iteration: 700001/700030 ERROR: ROUND OFF 0.49999>0.45 PFGW will automatically rerun the test with a6 (10^2107311)/9 ERROR DURING PROCESSING! (878.9319s+0.0013s) Code:
pfgw64 r V 'qR(210731)' PFGW Version 4.0.0.64BIT.20190528.x86_Dev [GWNUM 29.8] Generic modular reduction using generic reduction AVX512 FFT length 72K, Pass1=192, Pass2=384, clm=1 on A 700034bit number R(210731) is composite: RES64: [780BD8CCB26C7E56] (661.1415s+0.0012s) 

20191203, 13:27  #416 
"Mark"
Apr 2003
Between here and the
2×7×11×41 Posts 
I'll reach out to George on this as this could be in the gwnum library and not pfgw.

20191203, 15:00  #417  
Jun 2012
Boulder, CO
280_{10} Posts 
Quote:
Code:
./pfgw64 r V 'q(10^2107311)/9' PFGW Version 4.0.0.64BIT.20190528.x86_Dev [GWNUM 29.8] Special modular reduction using AVX512 FFT length 40K, Pass1=128, Pass2=320, clm=1 on 10^2107311 Detected in MAXERR>0.45 (round off check) in prp_using_gwnum Iteration: 700001/700030 ERROR: ROUND OFF 0.5>0.45 PFGW will automatically rerun the test with a1 Special modular reduction using AVX512 FFT length 48K, Pass1=128, Pass2=384, clm=1 on 10^2107311 Detected in MAXERR>0.45 (round off check) in prp_using_gwnum Iteration: 700001/700030 ERROR: ROUND OFF 0.5>0.45 PFGW will automatically rerun the test with a2 

20191203, 15:38  #418 
P90 years forever!
Aug 2002
Yeehaw, FL
2^{2}·1,873 Posts 
Prime95 29.8 has no issues:
PRP=N/A,1,10,210731,1,75,0,3,1,"9" Since the problem occurs in the last few iterations I suspect the issue may be PFGW not using square_carefully in the last few iterations. 
Thread Tools  
Similar Threads  
Thread  Thread Starter  Forum  Replies  Last Post 
A possible bug in LLR/PFGW while using GWNUM (no bug in P95)  Batalov  Software  77  20150414 09:01 
PFGW 3.2.0 has been Released  rogue  Software  94  20100914 21:39 
PFGW 3.2.3 has been Released  rogue  Software  10  20091028 07:07 
PFGW 3.2.2 has been Released  rogue  Software  20  20090823 12:14 
PFGW 3.2.1 has been released  rogue  Software  5  20090810 01:43 