mersenneforum.org  

Go Back   mersenneforum.org > Great Internet Mersenne Prime Search > Software

Reply
 
Thread Tools
Old 2019-08-10, 20:46   #408
henryzz
Just call me Henry
 
henryzz's Avatar
 
"David"
Sep 2007
Cambridge (GMT/BST)

16EE16 Posts
Default

My guess is that it can't cope with recursive functions. Also the nth prime function is p(n) not P(n)
henryzz is online now   Reply With Quote
Old 2019-08-10, 21:45   #409
Dylan14
 
Dylan14's Avatar
 
"Dylan"
Mar 2017

2×172 Posts
Default

Quote:
Originally Posted by paulunderwood View Post
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 View Post
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.
Dylan14 is offline   Reply With Quote
Old 2019-08-10, 21:50   #410
paulunderwood
 
paulunderwood's Avatar
 
Sep 2002
Database er0rr

3,677 Posts
Default

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
paulunderwood is offline   Reply With Quote
Old 2019-08-11, 00:40   #411
Dylan14
 
Dylan14's Avatar
 
"Dylan"
Mar 2017

2×172 Posts
Default

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.
Dylan14 is offline   Reply With Quote
Old 2019-12-02, 19:48   #412
bchaffin
 
Sep 2010
Portland, OR

22·3·31 Posts
Default 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!
bchaffin is offline   Reply With Quote
Old 2019-12-02, 19:58   #413
paulunderwood
 
paulunderwood's Avatar
 
Sep 2002
Database er0rr

367710 Posts
Default The Repunit Prime Project

You might not be aware of this project for repunits. It has reached R(2,500,000).
paulunderwood is offline   Reply With Quote
Old 2019-12-02, 20:33   #414
rogue
 
rogue's Avatar
 
"Mark"
Apr 2003
Between here and the

142528 Posts
Default

Quote:
Originally Posted by bchaffin View Post
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.
rogue is online now   Reply With Quote
Old 2019-12-02, 23:04   #415
bchaffin
 
Sep 2010
Portland, OR

22·3·31 Posts
Default

Quote:
Originally Posted by rogue View Post
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!
bchaffin is offline   Reply With Quote
Old 2019-12-03, 13:27   #416
rogue
 
rogue's Avatar
 
"Mark"
Apr 2003
Between here and the

2×7×11×41 Posts
Default

I'll reach out to George on this as this could be in the gwnum library and not pfgw.
rogue is online now   Reply With Quote
Old 2019-12-03, 15:00   #417
ryanp
 
ryanp's Avatar
 
Jun 2012
Boulder, CO

28010 Posts
Default

Quote:
Originally Posted by bchaffin View Post
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
ryanp is online now   Reply With Quote
Old 2019-12-03, 15:38   #418
Prime95
P90 years forever!
 
Prime95's Avatar
 
Aug 2002
Yeehaw, FL

22·1,873 Posts
Default

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.
Prime95 is online now   Reply With Quote
Reply

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 2015-04-14 09:01
PFGW 3.2.0 has been Released rogue Software 94 2010-09-14 21:39
PFGW 3.2.3 has been Released rogue Software 10 2009-10-28 07:07
PFGW 3.2.2 has been Released rogue Software 20 2009-08-23 12:14
PFGW 3.2.1 has been released 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

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2021, Jelsoft Enterprises Ltd.

This forum has received and complied with 0 (zero) government requests for information.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation.
A copy of the license is included in the FAQ.