PFGW 4.0.4 (with gwnum v30.10) Released - Page 52

kar_bon · 2023-04-23, 15:17

Please help me with this:
- downloaded the latest pfgw64 for sourceforge: pfgw_win_4.0.5.7z

it says: "PFGW Version 4.0.4.64BIT.20221214.Win_Dev [GWNUM 30.11]"
-> as mentioned above only the new gwnum lib with 4.0.4 -> ok for me

but testing the prime 428*4^428-1 with pfgw64 -tc -q"428*4^428-1" gives

pfgw64 -tc -q"428*4^428-1"
PFGW Version 4.0.4.64BIT.20221214.Win_Dev [GWNUM 30.11]
Primality testing 428*4^428-1 [N-1/N+1, Brillhart-Lehmer-Selfridge]
Running N-1 test using base 3
N-1: 428*4^428-1 1/887 mro=0

but no other output, nor giving any entry in pfgw.log or pfgw.out.

rogue · 2023-04-23, 16:31

Quote:

Originally Posted by kar_bon

Please help me with this:
- downloaded the latest pfgw64 for sourceforge: pfgw_win_4.0.5.7z

it says: "PFGW Version 4.0.4.64BIT.20221214.Win_Dev [GWNUM 30.11]"
-> as mentioned above only the new gwnum lib with 4.0.4 -> ok for me

but testing the prime 428*4^428-1 with pfgw64 -tc -q"428*4^428-1" gives

pfgw64 -tc -q"428*4^428-1"
PFGW Version 4.0.4.64BIT.20221214.Win_Dev [GWNUM 30.11]
Primality testing 428*4^428-1 [N-1/N+1, Brillhart-Lehmer-Selfridge]
Running N-1 test using base 3
N-1: 428*4^428-1 1/887 mro=0

but no other output, nor giving any entry in pfgw.log or pfgw.out.

I can reproduce on Windows, but not on OS X. And I can only reproduce with a release build, not a debug build. I suspect a compile or linking error with Visual Studio's which I cannot do much about. llr is able to do a primality test, so you can use that for these numbers. It will probably be faster than pfgw.

kar_bon · 2023-04-24, 04:44

Here're some more versions tested:
- PFGW Version 4.0.4.64BIT.20221214.Win_Dev [GWNUM 30.11] -> as shown no output
- PFGW Version 4.0.4.64BIT.20221214.Win_Dev [GWNUM 30.10] -> same, no output
- PFGW Version 4.0.3.64BIT.20220704.Win_Dev [GWNUM 29.8] -> output ok
- PFGW Version 3.8.3.64BIT.20161203.Win_Dev [GWNUM 28.6] -> output ok
- PFGW Version 3.7.7.64BIT.20130722.Win_Dev [GWNUM 27.11] -> output ok
- PFGW Version 3.7.3.64BIT.20130210.Win_Dev [GWNUM 27.8] -> output ok
- PFGW Version 3.6.0.64BIT.20111222.Win_Dev [GWNUM 26.6] -> output ok
- PFGW Version 3.5.0.64BIT.20110922.Win_Dev [GWNUM 26.6] -> output ok
- PFGW Version 3.4.0.64BIT.20100925.Win_Dev [GWNUM 26.2] -> no output after longer run!
- PFGW Version 3.3.1.20100111.Win_Dev [GWNUM 25.13] -> output ok
- PFGW Version 20090725.Win_Dev (Beta 'caveat utilitor') [GWNUM 25.12] -> output ok

rogue · 2023-05-15, 15:20

There is a bug introduced into pfgw 4.0.4 where it crashes after a PRP test of certain numbers. So far I have only seen this with Cullen numbers of base 4 and it only happens with release builds.

I do not know if this was introduced with an upgrade to gwnum, an upgrade to Visual Studio, or one of the other changes I have made to pfgw. It requires more investigation.

gd_barnes · 2023-06-05, 03:16

Seeing what I have here from WraithX and Karsten and finding the following, I would suggest that PFGW versions >= 4.0.x should not be used.

Test:
2778*3^18-1 = 1076254118441 (prime):
http://factordb.com/index.php?query=2778*3%5E18-1

Output from my various runs:

Code:

LLR 4.0.3
2778*3^18-1 is prime! (13 decimal digits, APRCL test)  Time : 0.198 ms.

PFGW 3.3.6
Primality testing 2778*3^18-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 3, base 3+sqrt(3)
Calling Brillhart-Lehmer-Selfridge with factored part 76.92%
2778*3^18-1 is prime! (0.0046s+0.0017s)

PFGW 3.7.7
Primality testing 2778*3^18-1 [N+1, Brillhart-Lehmer-Selfridge]
small number, factored prime!
2778*3^18-1 is prime! (0.0165s+0.0008s)

PFGW 4.0.3
Primality testing 2778*3^18-1 [N+1, Brillhart-Lehmer-Selfridge]
small number, factored
2778*3^18-1 is factored (0.0014s+0.0005s)

PFGW 4.0.4
Primality testing 2778*3^18-1 [N+1, Brillhart-Lehmer-Selfridge]
small number, factored
2778*3^18-1 is factored (0.0017s+0.0004s)

PFGW 4.0.5
Primality testing 2778*3^18-1 [N+1, Brillhart-Lehmer-Selfridge]
small number, factored
2778*3^18-1 is factored (0.0018s+0.0004s)

PFGW 4.0.6
Primality testing 2778*3^18-1 [N+1, Brillhart-Lehmer-Selfridge]
small number, factored
2778*3^18-1 is factored (0.0013s+0.0005s)

All were run with the -tp switch for primality proof. All had the same results for both the -f0 and -f100 switches.

They came back as PRP if the -tp switch was removed.

PFGW 4.0.x keeps saying that it is a "small number, factored" but cannot provide a factor. I tried the switch -e1000000000; actual factoring to 1e9, which is overkill. It still gave the same output about it being a small number, factored but would not provide a factor.

I have not tested 4.0.1 or 4.0.2 for this because I did not see them on the sourceforge site and I see that Karsten did not test them. I can only guess that they would have the same error.

I will continue running version 3.7.7 until these issues can be ironed out. I had only recently upgraded to 4.0.3 when testing srbsieve but will now revert back.

This was the first problem that I found in a parallel test against CRUS Riesel base 3 for k<10M. I will post here if I find other differences.

gd_barnes · 2023-06-05, 03:49

I isolated the issue mentioned in the last post. I'm still running PFGW 4.0.3 testing k<10M for Riesel base 3. The following primes were all found to be "factored":

2778*3^18-1 = 1076254118441
7984*3^17-1 = 1031055061391
23668*3^16-1 = 1018829792627
23678*3^16-1 = 1019260259837
24070*3^16-1 = 1036134574469
24242*3^16-1 = 1043538610481
24484*3^16-1 = 1053955916963
25262*3^16-1 = 1087446265901
25312*3^16-1 = 1089598601951
25532*3^16-1 = 1099068880571

Same error as the last post. PFGW versions 4.0.x are specifically having difficulty with primality testing numbers in the 1e12 to 1.1e12 range.

The only reason that there were not more of these is because the process that I ran did sieving for individual n-values up to n=15 and so was not running PFGW. Otherwise, there likely would have been problems for base 3 for k=69692-76660 n=15, k=209076-229982 n=14, etc. In other words any form where the result was in the 1e12 to 1.1e12 range.

I ran primality tests for CRUS Riesel base 3 for all k<10M for 16<=n<=500 using PFGW 4.0.3. These were the only errors found for ~442000 tests up to ~246 digits.

Cybertronic · 2023-06-05, 06:52

Today, I found the smallest 8000 digit probable prime triplet to pattern 0,2,6...

PFGW Version 4.0.6.64BIT.20230424.Win_Dev [GWNUM 30.12]

10^7999+1600488488131+00 is composite: RES64: [38336FC84BC0301D] (1.3753s+0.0013s)
10^7999+1600488488131+02 is composite: RES64: [2D01830A5CA4EECD] (1.5114s+0.0015s)
10^7999+1600488488131+06 is composite: RES64: [097F448D70E76463] (1.4317s+0.0014s)

vs

PFGW Version 4.0.4.64BIT.20221214.Win_Dev [GWNUM 30.11]

10^7999+1600488488131+00 is 3-PRP! (1.4584s+0.0005s)
10^7999+1600488488131+02 is 3-PRP! (1.6590s+0.0010s)
10^7999+1600488488131+06 is 3-PRP! (1.5421s+0.0008s)

Quote:

These should be PRP...but all composite with PFGW Version 4.0.6.64BIT
10^7999+0000082749451
10^7999+0000038043481
10^7999+0000062864767
10^7999+0000034506661
10^7999+0000162200311
10^7999+0000114747451
10^7999+0000140360671
10^7999+0000136937221
10^7999+0000249862957
10^7999+0000293101207
10^7999+0000258208021
10^7999+0000257943211
10^7999+0000273025591
10^7999+0000265772347
10^7999+0000342002767
10^7999+0000358764301
10^7999+0000343280071
10^7999+0000304227631
10^7999+0000342554197
10^7999+0000352667161
10^7999+0000389691907
10^7999+0000342767377
10^7999+0000429435961
10^7999+0000429029671
10^7999+0000469889671
10^7999+0000428730967
10^7999+0000465712981
10^7999+0000484125517
... and 81000 other numbers

WraithX · 2023-06-05, 09:51

Quote:

Originally Posted by Cybertronic

Today, I found the smallest 8000 digit probable prime triplet to pattern 0,2,6...

PFGW Version 4.0.6.64BIT.20230424.Win_Dev [GWNUM 30.12]

10^7999+1600488488131+00 is composite: RES64: [38336FC84BC0301D] (1.3753s+0.0013s)
10^7999+1600488488131+02 is composite: RES64: [2D01830A5CA4EECD] (1.5114s+0.0015s)
10^7999+1600488488131+06 is composite: RES64: [097F448D70E76463] (1.4317s+0.0014s)

vs

PFGW Version 4.0.4.64BIT.20221214.Win_Dev [GWNUM 30.11]

10^7999+1600488488131+00 is 3-PRP! (1.4584s+0.0005s)
10^7999+1600488488131+02 is 3-PRP! (1.6590s+0.0010s)
10^7999+1600488488131+06 is 3-PRP! (1.5421s+0.0008s)

PFGW 4.0.6 should not be used. I was trying to help add a feature, but I haven't quite got it working correctly yet. Everyone should avoid PFGW 4.0.6 for now as it will report all inputs as composite. Sorry about this. I'll try to get my new addition fixed soon.

WraithX · 2023-06-05, 09:55

Quote:

Originally Posted by gd_barnes

I have not tested 4.0.1 or 4.0.2 for this because I did not see them on the sourceforge site and I see that Karsten did not test them. I can only guess that they would have the same error.

I have both 4.0.1 and 4.0.2 for Windows in .7z format. Do you use the Windows version? I was going to attach them to this post, but they are both about 4.8MB and the attach limit is 4.0MB. :/

If you can use the Windows binary, you can PM me and we can work out a way to get the files to you.

Or, if you post all your command lines I can test them here on my computer.

rogue · 2023-06-05, 12:05

I will look into this. I'm not certain what would cause this. For numbers this small it would be using GMP not gwnum for the test.

Cybertronic · 2023-06-05, 12:29

Also curios is my first gigantic prime triplet (2008)

Quote:

PFGW Version 4.0.6.64BIT.20230424.Win_Dev [GWNUM 30.12]
2072644824759 * 2^33333 - 1 is composite: RES64: [E44DFDDD30B05320] (3.6993s+0.0009s)
2072644824759 * 2^33333 + 1 is composite: RES64: [9B51231F6DD6E385] (3.6260s+0.0012s)
2072644824759 * 2^33333 + 5 is composite: RES64: [3A213FC4CA6032D5] (3.6277s+0.0007s)

all composite AND the time 3.6s ! ...looks like 20.000 digits instead of 10.000

vs

PFGW Version 4.0.4.64BIT.20221214.Win_Dev [GWNUM 30.11]
***WARNING! file 00 may have already been fully processed.

2072644824759 * 2^33333 - 1 is 3-PRP! (1.2356s+0.0010s) <---- 1.2s
2072644824759 * 2^33333 + 1 is 3-PRP! (1.2250s+0.0018s)
2072644824759 * 2^33333 + 5 is 3-PRP! (1.2346s+0.0024s)

2023-05-15, 15:20	#565
rogue "Mark" Apr 2003 Between here and the 3×2,447 Posts	There is a bug introduced into pfgw 4.0.4 where it crashes after a PRP test of certain numbers. So far I have only seen this with Cullen numbers of base 4 and it only happens with release builds. I do not know if this was introduced with an upgrade to gwnum, an upgrade to Visual Studio, or one of the other changes I have made to pfgw. It requires more investigation. Last fiddled with by rogue on 2023-05-15 at 15:24

2023-06-05, 03:16	#566
gd_barnes "Gary" May 2007 Overland Park, KS 11000000001000₂ Posts	PFGW 4.0.x says that prime is "factored" Seeing what I have here from WraithX and Karsten and finding the following, I would suggest that PFGW versions >= 4.0.x should not be used. Test: 27783^18-1 = 1076254118441 (prime): http://factordb.com/index.php?query=27783%5E18-1 Output from my various runs: Code: LLR 4.0.3 27783^18-1 is prime! (13 decimal digits, APRCL test) Time : 0.198 ms. PFGW 3.3.6 Primality testing 27783^18-1 [N+1, Brillhart-Lehmer-Selfridge] Running N+1 test using discriminant 3, base 3+sqrt(3) Calling Brillhart-Lehmer-Selfridge with factored part 76.92% 27783^18-1 is prime! (0.0046s+0.0017s) PFGW 3.7.7 Primality testing 27783^18-1 [N+1, Brillhart-Lehmer-Selfridge] small number, factored prime! 27783^18-1 is prime! (0.0165s+0.0008s) PFGW 4.0.3 Primality testing 27783^18-1 [N+1, Brillhart-Lehmer-Selfridge] small number, factored 27783^18-1 is factored (0.0014s+0.0005s) PFGW 4.0.4 Primality testing 27783^18-1 [N+1, Brillhart-Lehmer-Selfridge] small number, factored 27783^18-1 is factored (0.0017s+0.0004s) PFGW 4.0.5 Primality testing 27783^18-1 [N+1, Brillhart-Lehmer-Selfridge] small number, factored 27783^18-1 is factored (0.0018s+0.0004s) PFGW 4.0.6 Primality testing 27783^18-1 [N+1, Brillhart-Lehmer-Selfridge] small number, factored 27783^18-1 is factored (0.0013s+0.0005s) All were run with the -tp switch for primality proof. All had the same results for both the -f0 and -f100 switches. They came back as PRP if the -tp switch was removed. PFGW 4.0.x keeps saying that it is a "small number, factored" but cannot provide a factor. I tried the switch -e1000000000; actual factoring to 1e9, which is overkill. It still gave the same output about it being a small number, factored but would not provide a factor. I have not tested 4.0.1 or 4.0.2 for this because I did not see them on the sourceforge site and I see that Karsten did not test them. I can only guess that they would have the same error. I will continue running version 3.7.7 until these issues can be ironed out. I had only recently upgraded to 4.0.3 when testing srbsieve but will now revert back. This was the first problem that I found in a parallel test against CRUS Riesel base 3 for k<10M. I will post here if I find other differences. Last fiddled with by gd_barnes on 2023-06-05 at 04:05*

2023-06-05, 03:49	#567
gd_barnes "Gary" May 2007 Overland Park, KS 2³·29·53 Posts	I isolated the issue mentioned in the last post. I'm still running PFGW 4.0.3 testing k<10M for Riesel base 3. The following primes were all found to be "factored": 27783^18-1 = 1076254118441 79843^17-1 = 1031055061391 236683^16-1 = 1018829792627 236783^16-1 = 1019260259837 240703^16-1 = 1036134574469 242423^16-1 = 1043538610481 244843^16-1 = 1053955916963 252623^16-1 = 1087446265901 253123^16-1 = 1089598601951 255323^16-1 = 1099068880571 Same error as the last post. PFGW versions 4.0.x are specifically having difficulty with primality testing numbers in the 1e12 to 1.1e12 range. The only reason that there were not more of these is because the process that I ran did sieving for individual n-values up to n=15 and so was not running PFGW. Otherwise, there likely would have been problems for base 3 for k=69692-76660 n=15, k=209076-229982 n=14, etc. In other words any form where the result was in the 1e12 to 1.1e12 range. I ran primality tests for CRUS Riesel base 3 for all k<10M for 16<=n<=500 using PFGW 4.0.3. These were the only errors found for ~442000 tests up to ~246 digits. Last fiddled with by gd_barnes on 2023-06-05 at 04:21

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.1 has been released	rogue	Software	5	2009-08-10 01:43
PFGW 3.1.0 has been Released	rogue	Software	25	2009-07-21 18:13

2023-04-23, 15:17	#562
kar_bon Mar 2006 Germany 2·1,531 Posts	Please help me with this: - downloaded the latest pfgw64 for sourceforge: pfgw_win_4.0.5.7z it says: "PFGW Version 4.0.4.64BIT.20221214.Win_Dev [GWNUM 30.11]" -> as mentioned above only the new gwnum lib with 4.0.4 -> ok for me but testing the prime 4284^428-1 with pfgw64 -tc -q"4284^428-1" gives pfgw64 -tc -q"4284^428-1" PFGW Version 4.0.4.64BIT.20221214.Win_Dev [GWNUM 30.11] Primality testing 4284^428-1 [N-1/N+1, Brillhart-Lehmer-Selfridge] Running N-1 test using base 3 N-1: 428*4^428-1 1/887 mro=0 but no other output, nor giving any entry in pfgw.log or pfgw.out.

2023-04-24, 04:44	#564
kar_bon Mar 2006 Germany 2·1,531 Posts	Here're some more versions tested: - PFGW Version 4.0.4.64BIT.20221214.Win_Dev [GWNUM 30.11] -> as shown no output - PFGW Version 4.0.4.64BIT.20221214.Win_Dev [GWNUM 30.10] -> same, no output - PFGW Version 4.0.3.64BIT.20220704.Win_Dev [GWNUM 29.8] -> output ok - PFGW Version 3.8.3.64BIT.20161203.Win_Dev [GWNUM 28.6] -> output ok - PFGW Version 3.7.7.64BIT.20130722.Win_Dev [GWNUM 27.11] -> output ok - PFGW Version 3.7.3.64BIT.20130210.Win_Dev [GWNUM 27.8] -> output ok - PFGW Version 3.6.0.64BIT.20111222.Win_Dev [GWNUM 26.6] -> output ok - PFGW Version 3.5.0.64BIT.20110922.Win_Dev [GWNUM 26.6] -> output ok - PFGW Version 3.4.0.64BIT.20100925.Win_Dev [GWNUM 26.2] -> no output after longer run! - PFGW Version 3.3.1.20100111.Win_Dev [GWNUM 25.13] -> output ok - PFGW Version 20090725.Win_Dev (Beta 'caveat utilitor') [GWNUM 25.12] -> output ok

2023-06-05, 12:05	#571
rogue "Mark" Apr 2003 Between here and the 3·2,447 Posts	I will look into this. I'm not certain what would cause this. For numbers this small it would be using GMP not gwnum for the test.