mersenneforum.org PFGW 3.8.3 (with gwnum v28.7) Released
 Register FAQ Search Today's Posts Mark Forums Read

 2019-08-10, 20:46 #408 henryzz Just call me Henry     "David" Sep 2007 Cambridge (GMT/BST) 16EE16 Posts My guess is that it can't cope with recursive functions. Also the nth prime function is p(n) not P(n)
2019-08-10, 21:45   #409
Dylan14

"Dylan"
Mar 2017

2×172 Posts

Quote:
 Originally Posted by paulunderwood Does the nth prime P(n) function work in scripts? I don't understand the recursive function of yours called "gaporial". What does it return when i is 2? Does it always return 0? Code: int gaporial(int n) { if (n == 0) { return 0; } else { return gaporial(n-1).(P(n+1)-P(n)); } } int i; int q; int num; int num2; for(i=1; i<=10000; i+=1) { num = gaporial(i); num2 = num+1; q = PRP(num2, -f); if(q == 1) { print(i); } }
The gaporial function is supposed to compute the product of prime gaps, starting with the first one (the one between 2 and 3, which is 1) up to the nth gap (the one between the nth and (n+1)th prime). See A081411.

I believe I see the problem in the code above. If i = 2, then the code would then need to evaluate

gaporial(1)*(5-3)

which in turn requires us to evaluate

gaporial(0)*(3-2).

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*(3-2)=1*1=1
gaporial(2) = 1*(5-3)=1*2=2
gaporial(3) = 2*(7-5)=2*2=4
etc.
which is what I expect. Of course fixing that doesn't fix the error I have.
Quote:
 Originally Posted by henryzz My guess is that it can't cope with recursive functions. Also the nth prime function is p(n) not P(n)
That might be the issue - which seems strange since we use a C-like 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.

 2019-08-10, 21:50 #410 paulunderwood     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 3-PRP! (0.0000s+0.0010s) 12806790724213976503626296721408001 is 3-PRP! (0.0000s+0.0023s) 307362977381135436087031121313792001 is 3-PRP! (0.0000s+0.0015s) Last fiddled with by paulunderwood on 2019-08-10 at 22:45
 2019-08-11, 00:40 #411 Dylan14     "Dylan" Mar 2017 2×172 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. However, I get the following instead: Code: 2 3 5 17 257 12289 14155777 169869313 4076863489 32318253138475745281 12806790724213976503626296721408001 (longer ones as well which are not included here for brevity) So it prints the primes to the log file (which is expected) but not the i value, which could be useful for generating a sequence.
 2019-12-02, 19:48 #412 bchaffin   Sep 2010 Portland, OR 22·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^n-1)/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^210731-1)/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!
 2019-12-02, 19:58 #413 paulunderwood     Sep 2002 Database er0rr 367710 Posts The Repunit Prime Project You might not be aware of this project for repunits. It has reached R(2,500,000).
2019-12-02, 20:33   #414
rogue

"Mark"
Apr 2003
Between here and the

142528 Posts

Quote:
 Originally Posted by bchaffin 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^n-1)/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^210731-1)/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!
You can always find the latest pfgw executable at https://sourceforge.net/projects/openpfgw/. The thread title is not correct.

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.

2019-12-02, 23:04   #415
bchaffin

Sep 2010
Portland, OR

22·3·31 Posts

Quote:
 Originally Posted by rogue You can always find the latest pfgw executable at https://sourceforge.net/projects/openpfgw/. The thread title is not correct. 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.
Sure, see below. I'm running Ubuntu 18.04 on an i9-9980XE, which is a Skylake core. The pfgw64 binary is from Sourceforge, I didn't build it myself.

Here's the special reduction output (this was run with -r, but it makes no difference):

Code:
pfgw64 -r -V '-q(10^210731-1)/9'
PFGW Version 4.0.0.64BIT.20190528.x86_Dev [GWNUM 29.8]

Special modular reduction using AVX-512 FFT length 40K, Pass1=128, Pass2=320, clm=1 on 10^210731-1
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 AVX-512 FFT length 48K, Pass1=128, Pass2=384, clm=1 on 10^210731-1
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 AVX-512 FFT length 56K, Pass1=128, Pass2=448, clm=1 on 10^210731-1
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 AVX-512 FFT length 60K, Pass1=192, Pass2=320, clm=1 on 10^210731-1
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 AVX-512 FFT length 64K, Pass1=128, Pass2=512, clm=1 on 10^210731-1
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 AVX-512 FFT length 72K, Pass1=192, Pass2=384, clm=1 on 10^210731-1
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^210731-1)/9 ERROR DURING PROCESSING! (878.9319s+0.0013s)
And here's the output when running the generic routine:

Code:
pfgw64 -r -V '-qR(210731)'
PFGW Version 4.0.0.64BIT.20190528.x86_Dev [GWNUM 29.8]

Generic modular reduction using generic reduction AVX-512 FFT length 72K, Pass1=192, Pass2=384, clm=1 on A 700034-bit number
R(210731) is composite: RES64: [780BD8CCB26C7E56] (661.1415s+0.0012s)
Thanks!

 2019-12-03, 13:27 #416 rogue     "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.
2019-12-03, 15:00   #417
ryanp

Jun 2012
Boulder, CO

28010 Posts

Quote:
 Originally Posted by bchaffin Sure, see below. I'm running Ubuntu 18.04 on an i9-9980XE, which is a Skylake core. The pfgw64 binary is from Sourceforge, I didn't build it myself. Here's the special reduction output (this was run with -r, but it makes no difference):
I can confirm similar output on a Linux machine with a Xeon Gold 6154 CPU.

Code:
./pfgw64 -r -V '-q(10^210731-1)/9'
PFGW Version 4.0.0.64BIT.20190528.x86_Dev [GWNUM 29.8]

Special modular reduction using AVX-512 FFT length 40K, Pass1=128, Pass2=320, clm=1 on 10^210731-1
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 AVX-512 FFT length 48K, Pass1=128, Pass2=384, clm=1 on 10^210731-1
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

 2019-12-03, 15:38 #418 Prime95 P90 years forever!     Aug 2002 Yeehaw, FL 22·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.

 Similar Threads Thread Thread Starter Forum Replies Last Post Batalov Software 77 2015-04-14 09:01 rogue Software 94 2010-09-14 21:39 rogue Software 10 2009-10-28 07:07 rogue Software 20 2009-08-23 12:14 rogue Software 5 2009-08-10 01:43

All times are UTC. The time now is 17:29.

Tue May 18 17:29:46 UTC 2021 up 40 days, 12:10, 0 users, load averages: 1.25, 1.81, 2.14