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

2020-02-23, 22:27   #463
Happy5214

"Alexander"
Nov 2008
The Alamo City

3·131 Posts

Quote:
 Originally Posted by storm5510 This is my major peeve with PFGW, and one of the reasons I do not use it. The other, members working the Riesel prime search strongly urged using LLR. PRP vs LL. I understand their reasons.
PFGW can do a deterministic (i.e. proven prime rather than probably prime) P+1 test on Riesel candidates by passing the -tp argument to it. However, said algorithm is not as efficient as LLR, and I generally only use PFGW on Riesel candidates when the numbers are small (n < 10,000), where the cost of writing the LLR log to disk slows it down considerably versus PFGW (which only writes when a prime is found).

 2020-03-04, 22:27 #464 japelprime     "Erling B." Dec 2005 7·11 Posts I also found a big speed difference llr in favor for thouse old cpu I am using. I stick to llr at the moment doing Riesel numbers. Thanks for all the help here. Last fiddled with by japelprime on 2020-03-04 at 22:32
2020-03-05, 00:08   #465
paulunderwood

Sep 2002
Database er0rr

3,449 Posts

Quote:
 Originally Posted by japelprime I also found a big speed difference llr in favor for thouse old cpu I am using. I stick to llr at the moment doing Riesel numbers. Thanks for all the help here.
If there is a "big speed difference" then it is most likely to be due to the different FFT sizes used.

Last fiddled with by paulunderwood on 2020-03-05 at 07:05

 2020-03-05, 00:18 #466 rogue     "Mark" Apr 2003 Between here and the 135018 Posts llr will be faster for most, if not all, numbers of the form k*b^n+/-c because it uses a different algorithm. I have purposefully not changed pfgw to use a faster algorithm because it allows for one program to verify the results of the other.
 2020-07-04, 11:29 #467 matzetoni     Feb 2019 10010102 Posts Is it possible to automatically stop pfgw once a prp is found? I read about setting number_primes in the input file, but it doesn't seem to work for me :/ Does number_primes only work with confirmed primes (ignoring prps)?
2020-07-04, 13:19   #468
rogue

"Mark"
Apr 2003
Between here and the

5,953 Posts

Quote:
 Originally Posted by matzetoni Is it possible to automatically stop pfgw once a prp is found? I read about setting number_primes in the input file, but it doesn't seem to work for me :/ Does number_primes only work with confirmed primes (ignoring prps)?
Let's assume that you have {number_primes,$a,1}. This means that for each distinct value for$a, it will stop PRP testing that value when a prime is found.

So if you have multiple values for $a, it will continue searching. Post your input file and explain what you are trying to accomplish. 2020-07-04, 13:43 #469 pepi37 Dec 2011 After milion nines:) 22·337 Posts Quote:  Originally Posted by matzetoni Is it possible to automatically stop pfgw once a prp is found? I read about setting number_primes in the input file, but it doesn't seem to work for me :/ Does number_primes only work with confirmed primes (ignoring prps)? LLR can do that 2020-07-04, 14:45 #470 matzetoni Feb 2019 2×37 Posts Quote:  Originally Posted by rogue Let's assume that you have {number_primes,$a,1}. This means that for each distinct value for $a, it will stop PRP testing that value when a prime is found. So if you have multiple values for$a, it will continue searching. Post your input file and explain what you are trying to accomplish.

I may misinterpreted the function of {number_primes,$a,1}. I'd like to search for the smallest prp larger than some 10^n and I wish to stop the program once it found it, so it doesn't search the entire sieve file then. I attached a sieve file for n=4k with candidates of the form 10^4000+c, made with fkbnsieve. So when pfgw finds 10^4000+"something" is prp, I'd like it to stop and search no further. Attached Files  out10n-4000.txt (6.3 KB, 23 views) Last fiddled with by matzetoni on 2020-07-04 at 14:46 2020-07-04, 15:34 #471 rogue "Mark" Apr 2003 Between here and the 595310 Posts Quote:  Originally Posted by matzetoni I may misinterpreted the function of {number_primes,$a,1}. I'd like to search for the smallest prp larger than some 10^n and I wish to stop the program once it found it, so it doesn't search the entire sieve file then. I attached a sieve file for n=4k with candidates of the form 10^4000+c, made with fkbnsieve. So when pfgw finds 10^4000+"something" is prp, I'd like it to stop and search no further.
I have only used number_primes with ABC format, but fkbnsieve doesn't output ABC format.

I think that you will need to use an edited to change to this format:

Code:
ABCD $a^4000+$b [10 61] // {number_primes,$a,1} 0 +50 but you might need to experiment. The 0 on the each line means "add 0 to the$a value". This means that $a will also be 10. 2020-07-04, 16:09 #472 matzetoni Feb 2019 10010102 Posts Quote:  Originally Posted by rogue I have only used number_primes with ABC format, but fkbnsieve doesn't output ABC format. I think that you will need to use an edited to change to this format: Code: ABCD$a^4000+$b [10 61] // {number_primes,$a,1} 0 +50 but you might need to experiment. The 0 on the each line means "add 0 to the $a value". This means that$a will also be 10.

That works! Thanks a lot!

 2020-07-15, 20:47 #473 bchaffin   Sep 2010 Portland, OR 7×53 Posts Another repunit which fails with special modular reduction I found another repunit which fails repeatedly when run with special modular reduction. This is using pfgw4.0.1, which uses square_carefully for the last 50 iterations. (See post https://www.mersenneforum.org/showpo...&postcount=415 for a previous case.) In this case the offender is (10^4568899-1)/9: Code: Detected in MAXERR>0.45 (round off check) in prp_using_gwnum Iteration: 15177501/15177550 ERROR: ROUND OFF 0.5>0.45 PFGW will automatically rerun the test with -a1 ... Detected in MAXERR>0.45 (round off check) in prp_using_gwnum Iteration: 15177501/15177550 ERROR: ROUND OFF 0.5>0.45 PFGW will automatically rerun the test with -a6 (10^4568899-1)/9 ERROR DURING PROCESSING! (96541.0526s+0.0304s)

 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 11:11.

Sat Oct 31 11:11:36 UTC 2020 up 51 days, 8:22, 2 users, load averages: 2.54, 2.29, 2.26