PFGW latest well-tested version
 

Hi all,

A couple of days ago, PFGW 3.2.0 was [URL="http://www.mersenneforum.org/showthread.php?t=12214"]released[/URL]. This version fixes many of the problems in 3.1.0 including the residue bug. The roundoff errors were not fully fixed with this release. Versions 3.3.0 and later correct all roundoff errors. Versions 3.3.6 and later correct all issues related to the proof of smaller PRPs. Here are links to the latest well-tested versions of PFGW:

[URL="http://sourceforge.net/projects/openpfgw/files/pfgw_win_3.4.1_20100927.zip/download"]PFGW 3.4.1 for Windows[/URL]
[URL="http://sourceforge.net/projects/openpfgw/files/pfgw_linux_3.4.0_20100925.zip/download"]PFGW 3.4.0 for Linux[/URL]
[URL="http://sourceforge.net/projects/openpfgw/files/pfgw_mac_3.4.0_20100925.zip/download"]PFGW 3.4.0 for Mac[/URL]

PFGW 3.4.0 & 3.4.1 are now the most highly recommended programs for testing at CRUS.

PRPnet 3.3.5, which likewise fixes all known bugs in PRPnet, utilizes PFGW for non-power-of-2 PRP tests if available. If you're using PRPnet, we highly recommend downloading this latest version. See [URL="http://www.mersenneforum.org/showthread.php?t=12225"]this thread[/URL] for more information.

Max :smile:

[quote=mdettweiler;183154]Hi all,

A couple of days ago, PFGW 3.2.0 was [URL="http://www.mersenneforum.org/showthread.php?t=12214"]released[/URL]. This version fixes all of the problems in 3.1.0: the residue bug, as well as the FFT roundoff errors.

Now that the residue bug in PFGW has been remedied, PFGW and Prime95 are equally recommended for non-power-of-2 PRP testing. Actually, at this time, PFGW is more highly recomended since it's fixed the FFT roundoff errors, though Prime95 v25.12 should also be released soon to fix these as well.

PRPnet 2.2.3, which likewise fixes all known bugs in PRPnet, utilizes PFGW for non-power-of-2 PRP tests if available. If you're using PRPnet, I highly recommend downloading this latest version. See [URL="http://www.mersenneforum.org/showthread.php?t=12225"]this thread[/URL] for more information. The client packages downloadable from there include the latest version of PFGW.

Max :smile:[/quote]
why doesnt it use pfgw for base 2?
ll tests have been made a little faster since gwnum 24.14 and also has speed ups for 64-bit
i suspect that those speedups will also help llr

[QUOTE=henryzz;183248]why doesnt it use pfgw for base 2?
ll tests have been made a little faster since gwnum 24.14 and also has speed ups for 64-bit
i suspect that those speedups will also help llr[/QUOTE]

Because LLR does a primality test for base 2 (both +1 and -1), not a PRP test. For the +1 side, PFGW would have to be modified to dynamically choose a base that can be used for a Proth test. By doing that the PRP test turns into a primality test. This is what LLR and phrot do. For the -1 side, PFGW would need to implement the LLR algorithm (which is in PFGW 1.4, which we don't have source for). I could "borrow" the code from LLR for the -1 test, but all we really need is for Jean to upgrade LLR. Finally, when PFGW does primality tests, it doesn't not give a residue if the result is composite.

BTW, I have not heard from Jean in a while, so I don't what's going on with him. Since LLR source is available, it would be relatively easy to upgrade it, but I would prefer to have his permission before doing so.

As for a 64-bit build, I'm working with Geoff Reynolds as there is a single asm module in PFGW that will not compile as 64-bit. I'm not an x86 asm guru, so I'm hoping that he can come up with a single module that works for both 32-bit and 64-bit environments.

I'm getting an error on PFGW with my new Sierp base 52 reservation. Here it is:

[code]
-----------------------------------------------------------------------
Error occuring in PFGW at Tue Aug 04 05:07:35 2009
Expr = 9243*52^2046+1
Failed at bit 1877 of 11676
Msg = Detected in MAXERR>0.45 (round off check) in prp_using_gwnum
Iteration: 1877/11676 ERROR: ROUND OFF 0.46875>0.45
[/code]

I'm running on a 32-bit 1.6 Ghz HP dual-core laptop under Windows Vista.

Its running without sieving up to n=5000 so I have the -f100 switch set for trial factoring. A quick check using Syd's DB found no factors up to P=10M but it is composite. So no problems caused at this point but it could cause a problem on a real prime in the future.

Can someone look into this for me?


Thanks,
Gary

[QUOTE=gd_barnes;183980]I'm getting an error on PFGW with my new Sierp base 52 reservation. Here it is:

[code]
-----------------------------------------------------------------------
Error occuring in PFGW at Tue Aug 04 05:07:35 2009
Expr = 9243*52^2046+1
Failed at bit 1877 of 11676
Msg = Detected in MAXERR>0.45 (round off check) in prp_using_gwnum
Iteration: 1877/11676 ERROR: ROUND OFF 0.46875>0.45
[/code]

I'm running on a 32-bit 1.6 Ghz HP dual-core laptop under Windows Vista.

Its running without sieving up to n=5000 so I have the -f100 switch set for trial factoring. A quick check using Syd's DB found no factors up to P=10M but it is composite. So no problems caused at this point but it could cause a problem on a real prime in the future.

Can someone look into this for me?


Thanks,
Gary[/QUOTE]

The problem is under investigation, since I got the same mistakes doing base 3 tests. In my case the problem was due to a mistake in Georges FFT tables (i think if I remember correctly). Also please be aware that PFGW skips the entire test if it fails in stead of checking it with different FFT lengths like Prime95 is. This is most likely going to be changed in the future according to words.

Regards

KEP

[QUOTE=gd_barnes;183980]I'm getting an error on PFGW with my new Sierp base 52 reservation. Here it is:

[code]
-----------------------------------------------------------------------
Error occuring in PFGW at Tue Aug 04 05:07:35 2009
Expr = 9243*52^2046+1
Failed at bit 1877 of 11676
Msg = Detected in MAXERR>0.45 (round off check) in prp_using_gwnum
Iteration: 1877/11676 ERROR: ROUND OFF 0.46875>0.45
[/code]

I'm running on a 32-bit 1.6 Ghz HP dual-core laptop under Windows Vista.

Its running without sieving up to n=5000 so I have the -f100 switch set for trial factoring. A quick check using Syd's DB found no factors up to P=10M but it is composite. So no problems caused at this point but it could cause a problem on a real prime in the future.

Can someone look into this for me?


Thanks,
Gary[/QUOTE]

This works in the upcoming release, so the problem has been resolved. It was most likely caused by gwnum being overly aggressive in choosing the FFT length. I hope to have a new release by the weekend.

While you're at it, the mouse-over pop-up for version 3.2 says version 3.1. :smile:

[quote=gd_barnes;183980]I'm getting an error on PFGW with my new Sierp base 52 reservation. Here it is:

[code]
-----------------------------------------------------------------------
Error occuring in PFGW at Tue Aug 04 05:07:35 2009
Expr = 9243*52^2046+1
Failed at bit 1877 of 11676
Msg = Detected in MAXERR>0.45 (round off check) in prp_using_gwnum
Iteration: 1877/11676 ERROR: ROUND OFF 0.46875>0.45
[/code]

I'm running on a 32-bit 1.6 Ghz HP dual-core laptop under Windows Vista.

Its running without sieving up to n=5000 so I have the -f100 switch set for trial factoring. A quick check using Syd's DB found no factors up to P=10M but it is composite. So no problems caused at this point but it could cause a problem on a real prime in the future.

Can someone look into this for me?


Thanks,
Gary[/quote]
As Mark said, it will be fixed in the next release; in the meantime, it's not a serious problem. It should work if you re-run that one number with the -a1 switch; that will force PFGW to use the next-higher FFT length which is really the correct one (and therefore it should be able to complete the test and give you a stable residual).

[QUOTE=Flatlander;183986]While you're at it, the mouse-over pop-up for version 3.2 says version 3.1. :smile:[/QUOTE]

Can you include a screen shot of that? I don't know what you are looking at.

Never mind, I think I found it.

I think it's because if you right-click and choose Properties/Version, it says version 3.1

In Windows btw.

[quote=mdettweiler;184001]As Mark said, it will be fixed in the next release; in the meantime, it's not a serious problem. It should work if you re-run that one number with the -a1 switch; that will force PFGW to use the next-higher FFT length which is really the correct one (and therefore it should be able to complete the test and give you a stable residual).[/quote]

Yeah, I figured it's something minor. I just verified that it was composite at Alpertron's site. In the mean time, I got another one:

[quote]
-----------------------------------------------------------------------
Error occuring in PFGW at Tue Aug 04 19:11:21 2009
Expr = 6385*52^3070+1
Failed at bit 40 of 17512
Msg = Detected in MAXERR>0.45 (round off check) in prp_using_gwnum
Iteration: 40/17512 ERROR: ROUND OFF 0.5>0.45
[/quote]

I also verified that this one is composite at Alpertron's site.

Nothing earth shattering but I just wanted you to know in case it helps you detect a pattern of them or their frequency. The test that found these 2 problems is for all k's that are not k==(2 mod 3) on Sierp base 52 up to k=28673 and n=5000 so the problem is very infrequent for a fairly large # of k/n pairs tested. No sieving ahead of time was done. PFGW is set to do trial factoring with the -f100 switch.


Gary

[quote=gd_barnes;184154]Yeah, I figured it's something minor. I just verified that it was composite at Alpertron's site. In the mean time, I got another one:



I also verified that this one is composite at Alpertron's site.

Nothing earth shattering but I just wanted you to know in case it helps you detect a pattern of them or their frequency. The test that found these 2 problems is for all k's that are not k==(2 mod 3) on Sierp base 52 up to k=28673 and n=5000 so the problem is very infrequent for a fairly large # of k/n pairs tested. No sieving ahead of time was done. PFGW is set to do trial factoring with the -f100 switch.


Gary[/quote]
Mark said that he and George have fixed this problem (which is in the underlying gwnum math library). The fixed math library will be used for the next version of PFGW, so hopefully these errors won't happen any more. :smile:

Yeah, you already told me that and I had already read it from Rogue. Now I've read it 3 times. lol Like I stated, I was posting in case it helped with pattern recognition of the problem.

In the mean time, I got 3 of the same error at low n-range limits on Sierp base 67 for k==(0 mod 6). Interestingly two of them were for the same exponent. They are for:

4614*67^190+1
4914*67^254+1
7104*67^254+1

All 3 were confirmed as composite. The first two have a smallest factor of 14 digits. The last one...7 digits.

I know, I know, Rogue has fixed it for the next release. lmao


Gary

[quote=gd_barnes;184182] In the mean time, I got 3 of the same error at low n-range limits on Sierp base 67 for k==(0 mod 6). Interestingly two of them were for the same exponent. They are for:[/quote]
Hey Gary, rogue has fixed that for the next release, y'know?

:missingteeth::missingteeth::missingteeth:

:deadhorse:

Does anyone have Gary's phone number? I think he should know this straight away.

i got it:

555 - 8-7-4-3-6-8-6-3-9-7 (easy to recognize -> U-R-G-E-N-T-N-E-W-S) :grin:

Oh dang it guys. Why didn't you call me about this breaking news about Mark fixing it for the next release? Blast! Max has my #. Please contact him to get it in the future.

I do not want to miss such important news! Don't ever let it happen again!

Bug in PFGW 3.2.0
 

PFGW 3.2 can`t test the divisor of Fermat number.

[CODE]
PFGW Version 20090723.Win_Dev (Beta 'caveat utilitor') [GWNUM 25.12]


Done.

[/CODE]

But PFGW 1.3 can do this.

[CODE]
PFGW Version 3.0.0 for Windows [FFT v25.10]

5*2^23473+1 is a Factor of F23471!!!! (0.452000 seconds)

Done.

[/CODE]

Both are computed with "pfgw -go{2,2}{2,2} -q5*2^23473+1".

[QUOTE=Shaopu Lin;184550]PFGW 3.2 can`t test the divisor of Fermat number.

[CODE]
PFGW Version 20090723.Win_Dev (Beta 'caveat utilitor') [GWNUM 25.12]


Done.

[/CODE]

But PFGW 1.3 can do this.

[CODE]
PFGW Version 3.0.0 for Windows [FFT v25.10]

5*2^23473+1 is a Factor of F23471!!!! (0.452000 seconds)

Done.

[/CODE]

Both are computed with "pfgw -go{2,2}{2,2} -q5*2^23473+1".[/QUOTE]

Thanks. I'll investigate.

[QUOTE=rogue;184576]Thanks. I'll investigate.[/QUOTE]

It will be fixed in the next release. It was returning the incorrect value in a subroutine. It was returning 0 instead of a set return value. That was due to a change I made to address rounding errors.

ABC $a*3^$b+1 // {number_primes,$a,1}

I'm learning PFGW (finally). Can someone point me to file that explains the
// {number_primes,$a,1} portion on the input line. I've looked in the documentation and can't find it. DUH

"abcfileformats.txt" line 32ff (of the last version)

While running PFGW 3.2.2 standalone (not wirh PRPNet) using this parameter:

ABC $a*3^$b+1 // {number_primes,$a,1}

The program did skip any subsequent tests for any k's found until I had to ctrl-c out. When I restarted the run, the checkpoint worked just fine BUT tests for any found k's were not being skipped. I fixed it by stopping the run again and inserting the PRP tests for the found k's after the checkpoint. Skipping resumed again for those k's. Shouldn't the program read the pfgw.log file (if present) when restarting to get those k's?

It's a known 'quirk'.
[URL="http://mersenneforum.org/showpost.php?p=183646&postcount=13"]http://mersenneforum.org/showpost.php?p=183646&postcount=13[/URL]
Last paragraph.

[QUOTE]
It's a known 'quirk'.
[URL="http://mersenneforum.org/showpost.php?p=183646&postcount=13"]http://mersenneforum.org/showpost.ph...6&postcount=13[/URL]
Last paragraph.
[/QUOTE]

Thanks Chris. It's only real bad news when running a large file expecting to find many primes. I actually thought it was easier to repeat the PRP tests to get the skipping working again. All I have to do is cleanup the output file and remove the duplicate primes from pfgw.log.

Good idea. I think I'll do that in the future. :tu:

Another method would be to sort your file by k instead of n. When a prime/PRP is found this would skip the rest of this k right away. This may get confusing, as we usually track n, not k.

Cheers, Willem.

I've updated the downloadable versions of PFGW in the 1st post here to version 3.2.3. Version 3.2.0 did not correct many of the roundoff errors. Apparently version 3.2.3 does. I'm testing the tough Riesel base 40 from n=1 to 1000 that had many roundoff errors in 3.2.0 to prove it.


Gary

[quote=gd_barnes;193630]I've updated the downloadable versions of PFGW in the 1st post here to version 3.2.3. Version 3.2.0 did not correct many of the roundoff errors. Apparently version 3.2.3 does. I'm testing the tough Riesel base 40 from n=1 to 1000 that had many roundoff errors in 3.2.0 to prove it.


Gary[/quote]

I figured I should provide an update here. I've now tested 1000's of k's on Sierp bases 35, 39, and 40 to n=2500 or n=10K and only encountered one roundoff error. PFGW 3.2.3 is working very well! :smile:

Were the timings the same?

I didn't check but I have no reason to think there would be any significant difference.

3.2.3 hasn't completely eliminated the roundoff errors.
Ran a few base 7 numbers with pfgw 3.2.3 and got this

-----------------------------------------------------------------------
Error occuring in PFGW at Wed Nov 25 18:13:03 2009
Expr = 7370*7^250081-1
Detected in MAXERR>0.45 (round off check) in prp_using_gwnum
Iteration: 506787/702078 ERROR: ROUND OFF 0.5>0.45

(Test aborted, try again using the -a1 switch)

Ony tested about 10 pairs or so i don't know how frequently this error would occur.

[QUOTE=PCZ;197155]3.2.3 hasn't completely eliminated the roundoff errors.
Ran a few base 7 numbers with pfgw 3.2.3 and got this

-----------------------------------------------------------------------
Error occuring in PFGW at Wed Nov 25 18:13:03 2009
Expr = 7370*7^250081-1
Detected in MAXERR>0.45 (round off check) in prp_using_gwnum
Iteration: 506787/702078 ERROR: ROUND OFF 0.5>0.45

(Test aborted, try again using the -a1 switch)

Ony tested about 10 pairs or so i don't know how frequently this error would occur.[/QUOTE]

If George (Prime95) reads this, he will probably address it in his next release of gwnum. These have become much rarer as George has really been on the ball to address them.

I will look at this in the next release which is a long way off. Almost all of the FFT code is being rewritten. This will take a while to complete.

[quote=Prime95;197162]I will look at this in the next release which is a long way off. Almost all of the FFT code is being rewritten. This will take a while to complete.[/quote]
that sounds like 26.x
am i correct?

Thanks
Seeing that error pop up was troubling.

[QUOTE=henryzz;197176]that sounds like 26.x
am i correct?[/QUOTE]

Yes.

[QUOTE=Prime95;197162]I will look at this in the next release which is a long way off. Almost all of the FFT code is being rewritten. This will take a while to complete.[/QUOTE]

Wow. That sounds like quite a large task. Would you mind sharing some of the improvements you are working on?

[QUOTE=rogue;197195]Would you mind sharing some of the improvements you are working on?[/QUOTE]

Right now the code is organized such that it can only be optimized for two different CPUs. I've reorganized so that it can be optimized for several different CPUs.

Right now it only supports one FFT style - a non-standard radix-4 with Bailey multipliers between passes. I've added a mechanism to have several different FFT styles in the same gwnum library. This lets me compare the current non-standard to a traditional radix-4, a radix-8, maybe a split-radix, etc. Some architectures might be faster with different FFT styles. For example, the Pentium 4 pays a big penalty for memory accesses so my non-standard FFT was optimized for minimum memory accesses. The Core i5/i7 has much less memory penalty - so it makes sense to do fewer complex multiplies at the cost of more memory accesses.

D.J.Bernstein's "exponent-1" FFTs which reduces the amount of memory required for sin/cos twiddles.

Some other goodies which I'll keep secret for now :)

Out of nearly 2.5 million primes verified for a part of Riesel base 3, these 6 all return PRP, return composite with -tp but no -a1, and return prime with -tp and -a1:
[code]800157112*3^64-1
800829524*3^47-1
801245282*3^50-1
802324048*3^490-1
802829672*3^59-1
804875072*3^71-1[/code]I doubt that anybody cares or that anything needs to be done, just felt like reporting that little fact. :ermm:

[QUOTE=Mini-Geek;198563]Out of nearly 2.5 million primes verified for a part of Riesel base 3, these 6 all return PRP, return composite with -tp but no -a1, and return prime with -tp and -a1:
[code]800157112*3^64-1
800829524*3^47-1
801245282*3^50-1
802324048*3^490-1
802829672*3^59-1
804875072*3^71-1[/code]I doubt that anybody cares or that anything needs to be done, just felt like reporting that little fact. :ermm:[/QUOTE]

We should keep track of failures for testing the next release of gwnum/pfgw.

I am currently testing base 7 numbers using prpnet and pfgw without issue.
Have done about 5000 pairs so far and no round off errors at all.

Seems very speedy.
Almost as fast as LLR would do a base 2 number with an equivalent number of digits.
I am keeping the k's very small though guess this helps speed things up.
So no i'm not working in the 7001 7999 range that was just a test.

In the past i have quickly abandoned any non base 2 work because the available software was so slow.

George i have a few i7's and i5's here, and a pile of work if you need a beta tester :)

PS
The error i reported earlier was caused by a PC with bad memory.
Fortunately i weeded it out quickly and no real work was lost.

Rogue.
I have prpnet loaded up with the riesels, if i add the serps as well can you forsee any issues ?.
Can i mix them in the candidates file ?

[QUOTE=PCZ;199560]I have prpnet loaded up with the riesels, if i add the serps as well can you forsee any issues ?.
Can i mix them in the candidates file ?[/QUOTE]

There shouldn't be any. Just use the correct servertype in the prpserver.ini file. You should also decide if you want to hand out by k or by length, which is set in the ini file. That feature was added in 2.4.7.

2.4.7 ?
I have 2.4.6.

Want the work handed out by value of n, smallest to largest.
Type 1 i guess.

When i added the serps using prpadmin the server started handing out work at 286k and up.
Not at 250k which is the lowest value of n.

Only after stopping and starting the server did it start handing out serps at 250k, the riesels have already been processed up to 270k.

Edit
Got 2.4.7 downloaded now.

another round off error, Version 3.2.3:

-----------------------------------------------------------------------
Error occuring in PFGW at Sun Dec 27 09:41:59 2009
Expr = 19464*19^31895+1
Detected in MAXERR>0.45 (round off check) in prp_using_gwnum
Iteration: 107198/135501 ERROR: ROUND OFF 0.5>0.45

(Test aborted, try again using the -a1 switch)

PFGW 3.2.5 has been released
 

I thought I posted this earlier, but must not have hit submit.

I have release PFGW 3.2.5. Here is a list of changes.
[list][*]Fixed b^n+1 check so that it uses fast modular reduction[*]Some prime numbers silently fail (i.e. no errors detected) when testing for primality. To address this, PFGW will tell gwnum to use an irrational FFT for all tests.[*]Added new options for PFGW scripts. It can now do primality tests. It will also differentiate between numbers that are PRP and numbers that are prime based upon those tests. Please read scriptfileformat.txt for more information on how to use these new features. Note that old PFGW scripts might not work correctly with this version of PFGW.[*]PFGW scripts can now use forms (input as strings) for the PRP test. Previous releases handled decimal expansions only. With this release PFGW scripts can take advantage of fast modular reduction.[/list]
This release has significant changes for people using PFGW scripts (such as Conjectures 'R Us). Since scripts can now pass an expression (via a string) to the PRP comment, PFGW will output that expression, not its decimal expansion.

I have not modified the scriptify perl script or the documentation for it. I will leave those items to someone who knows perl.

Here are the links:
[URL="http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_win_3.2.5_20091219.zip?view=log"]PFGW 3.2.5 for Windows[/URL]
[URL="http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_linux_3.2.5_20091219.zip?view=log"]PFGW 3.2.5 for Linux[/URL]
[URL="http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_mac_3.2.5_20091219.zip?view=log"]PFGW 3.2.5 for MacIntel[/URL]

[quote=rogue;200716]I thought I posted this earlier, but must not have hit submit.[/quote]
Hmm, I saw it too. I even downloaded the latest version as soon as it showed up, so I'm sure it wasn't a fluke. Perhaps it was in a different thread?

Edit: Ah, right, that was it. There's two "PFGW 3.2.0 released" threads: one in the Software forum and one here. You previously posted it in the Software forum.

[QUOTE=rogue;200716]Some prime numbers silently fail (i.e. no errors detected) when testing for primality. To address this, PFGW will tell gwnum to use an irrational FFT for all tests.
[/QUOTE]
I am not sure, if I understand this correctly. But how many tests are affected here? Do we have to recheck some / all tests?

Edit:
Ahhhhhhhhhh, help, what's happening here? Just upgraded from 3.2.3 to 3.2.5 and the new version does not accept my checkpoint in the ini file.. ?
[QUOTE]***WARNING! file t16_b19.prp line 779870 does not match what is expected.
Expecting: 241036*19^32634+1
File contained: 253816 32634
Starting over at the beginning of the file

[/QUOTE]and then it starts from the beginning (line 1)
[QUOTE]86634 15 trivially factors as: 3*5*31^2*601
254754 15 trivially factors as: 3*5*7*331*733
377694 15 trivially factors as: 3*5*37*68053
484654 15 trivially factors as: 5*61*131*1213
555174 15 trivially factors as: 3*5*127*151*193
746524 15 trivially factors as: 5*14930483
[/QUOTE]

The input file I am using looks like
[QUOTE]252188461193:P:1:19:257
86634 15
254754 15
377694 15
484654 15
555174 15
746524 15
299626 16
[/QUOTE]

worked fine with the previous version..

Edit 2: I think the new version "forgot" how to convert this k n pair to the right format? Has it something to do with the script changes?

[QUOTE=Xentar;200881]I am not sure, if I understand this correctly. But how many tests are affected here? Do we have to recheck some / all tests?

Edit:
Ahhhhhhhhhh, help, what's happening here? Just upgraded from 3.2.3 to 3.2.5 and the new version does not accept my checkpoint in the ini file.. ?
and then it starts from the beginning (line 1)
[/quote]

I was not aware of this, but apparently the save format is different because of the irrational FFT. I suggest deleting the pfr file before starting PFGW when upgrading. In other words, this will only affect a saved test.

[QUOTE=Xentar;200881]
worked fine with the previous version..

Edit 2: I think the new version "forgot" how to convert this k n pair to the right format? Has it something to do with the script changes?[/QUOTE]

I do not know what is causing this issue with NewPGen files, but it is most likely something I screwed up with the changes for script handling. I'll look at it tomorrow.

PFGW 3.2.6 is Released
 

There was a bug in 3.2.5 with NewPGen file handling. It has been fixed in 3.2.6, which you can get here:

[url]http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_win_3.2.6_20100105.zip?view=log[/url]

I will post Mac/Linux updates only if users have NewPGen files they needs to process on those platforms.

[quote=rogue;200953]There was a bug in 3.2.5 with NewPGen file handling. It has been fixed in 3.2.6, which you can get here:

[URL]http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_win_3.2.6_20100105.zip?view=log[/URL]

I will post Mac/Linux updates only if users have NewPGen files they needs to process on those platforms.[/quote]
in theory people should be able to change to ABC file types for most things i would have thought

[quote=rogue;200953]There was a bug in 3.2.5 with NewPGen file handling. It has been fixed in 3.2.6, which you can get here:

[URL]http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_win_3.2.6_20100105.zip?view=log[/URL]

I will post Mac/Linux updates only if users have NewPGen files they needs to process on those platforms.[/quote]


Hello, can anynoe send me the windows version to nluhn at yahoo dot de ?
Thanks.

With this page, I have ever trouble.

[QUOTE=henryzz;200959]in theory people should be able to change to ABC file types for most things i would have thought[/QUOTE]
Are there any advantages, when I use this format? (Except the last little bug :smile: )

[quote=Xentar;200988]Are there any advantages, when I use this format?[/quote]
With the ABC format you can use PFGW's special comment:
[code]A "new" addition to the comment syntax in the ABC/ABC2/ABCD/PrZ format
specification is: // {number_primes,$var,#} or // {number_comps,$var,#}
These will stop processing "matching" $var when $var is a prime.[/code]e.g. "ABC $a*2^$b+1 // {number_primes,$a,1}" will stop searching the given k ($a) when 1 prime is found for it.

It's also far easier for a human to read that "ABC $a*2^$b-1" means k*2^n-1 than that "30000000000000:M:1:2:258" does, although the latter form does have the benefit of including the sieve depth.

No further benefits/drawbacks come to mind for either format...
[quote=Cybertronic;200982]Hello, can anynoe send me the windows version to nluhn at yahoo dot de ?
Thanks.

With this page, I have ever trouble.[/quote]
Sending...

[QUOTE=Xentar;200988]Are there any advantages, when I use this format? (Except the last little bug :smile: )[/QUOTE]

I wonder who still uses NewPGen for sieving. Most forms can be handled by one of Geoff Reynold's sieving programs because they are faster.

Sorry, my mistake.. :blush:

I am using srsieve for sieving, yes. But for any reason, this one saved the file in the ABCD format (sorted by k). I kept this format for sieving and used a small .bat file to convert it with srfile.. For any other reason, I choosed PRP format (sorted by n).

I will change the format during the next days, so It's not necessary to convert it anymore, right?
Life can be so easy.. you just need to know, how :grin:

Thanks for the information!

Btw.: Can a mod please split the last few posts from this thread? It doesn't affect PFGW directly :smile:

[QUOTE=Xentar;200995]Sorry, my mistake.. :blush:

I am using srsieve for sieving, yes. But for any reason, this one saved the file in the ABCD format (sorted by k). I kept this format for sieving and used a small .bat file to convert it with srfile.. For any other reason, I choosed PRP format (sorted by n).

I will change the format during the next days, so It's not necessary to convert it anymore, right?
Life can be so easy.. you just need to know, how :grin:

Thanks for the information!

Btw.: Can a mod please split the last few posts from this thread? It doesn't affect PFGW directly :smile:[/QUOTE]

With 3.2.6, it is not an issue.

Thanks for sending me !!!

[quote=Cybertronic;200982]Hello, can anynoe send me the windows version to nluhn at yahoo dot de ?
Thanks.

With this page, I have ever trouble.[/quote]

I have the same problem with sourceforge. It can be very confusing to get the right version of what you want.

If anyone here as seen the movie "National Treasure", there's a scene where Riley says something like "Why can't they just give us a map that says 'go here for the treasure and enjoy yourself'. :smile: The same applies to sourceforge. I want to say to it: "Go to this link for Linux PFGW version xxx and download it". I remember to get the correct Linux and Windows PFGW version 3.2.3 (to put links in the 1st posting here), it took me ~15 mins. :rolleyes:


Gary

[quote=gd_barnes;201029]I have the same problem with sourceforge. It can be very confusing to get the right version of what you want.

If anyone here as seen the movie "National Treasure", there's a scene where Riley says something like "Why can't they just give us a map that says 'go here for the treasure and enjoy yourself'. :smile: The same applies to sourceforge. I want to say to it: "Go to this link for Linux PFGW version xxx and download it". I remember to get the correct Linux and Windows PFGW version 3.2.3 (to put links in the 1st posting here), it took me ~15 mins. :rolleyes:


Gary[/quote]

[URL]http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_win_3.2.6_20100105.zip[/URL]

I found a bug in scripts when passing a string (and only a string) to the PRP command. It works fine when using something that is evaluated. I'll look into it tomorrow. This seems to only affect tests where k > b.

[QUOTE=rogue;201106]I found a bug in scripts when passing a string (and only a string) to the PRP command. It works fine when using something that is evaluated. I'll look into it tomorrow. This seems to only affect tests where k > b.[/QUOTE]

I fixed the problem. I also found a problem with the new PRIMEP script function, which is also fixed. You can d/l PFGW 3.2.7 for Windows from here:

[url]http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_win_3.2.7_20100107.zip?view=log[/url]

Mac and Linux versions to follow.

[QUOTE=rogue;201161][url]http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_win_3.2.7_20100107.zip?view=log[/url][/QUOTE]

The download link is in the center of the page:
Revision 196 - (view) [B](download) [/B](as text) (annotate) - [select for diffs]
:grin:

or use this direct link:
[url]http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_win_3.2.7_20100107.zip?revision=196[/url]

PFGW 3.3.0 is released
 

There are significant behavior changes to this release of PFGW WRT to the handling of sumout/roundoff errors and the use of the -a switch.
[list][*]The -a swith no longer supports -1 and -2 as they cause problems with the gwnum library. It now support 3, 4, and 5.[*]PFGW will automatically switch to the next larger FFT size for all tests if it detects a roundoff or sumout error. This information will be displayed to the user and written to the pfgw_err.log file. As a difference from previous releases, the roundoff/sumout error will not be written to pfgw.log.[*]The GFN divisibility logic had to be significantly modified to support the changes for automatically adjusting the FFT size.[*]The PFGW server (which was Windows only) is no longer built or distributed as no users have expressed any interest in using it.[/list]
[url]http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_win_3.3.0_20100108.zip[/url]

MacIntel and Linux versions are to follow later.

[QUOTE=rogue;201487]There are significant behavior changes to this release of PFGW WRT to the handling of sumout/roundoff errors and the use of the -a switch.
[list][*]The -a swith no longer supports -1 and -2 as they cause problems with the gwnum library. It now support 3, 4, and 5.[*]PFGW will automatically switch to the next larger FFT size for all tests if it detects a roundoff or sumout error. This information will be displayed to the user and written to the pfgw_err.log file. As a difference from previous releases, the roundoff/sumout error will not be written to pfgw.log.[*]The GFN divisibility logic had to be significantly modified to support the changes for automatically adjusting the FFT size.[*]The PFGW server (which was Windows only) is no longer built or distributed as no users have expressed any interest in using it.[/list]
[url]http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_win_3.3.0_20100108.zip[/url]

MacIntel and Linux versions are to follow later.[/QUOTE]

Just for clarification, PFGW will only change the FFT size for the number that failed, not for subsequent numbers (unless they fail).

[QUOTE=rogue;201504]Just for clarification, PFGW will only change the FFT size for the number that failed, not for subsequent numbers (unless they fail).[/QUOTE]

I've just noticed, using PFGW version 3.2.7 the linenumber is no longer showing in the windows client as it used to in the previous versions. I know its a small and insignificant change or bug, but it's quite nice to know how far through the file one is exactly, without having to look at the pfgw.ini file :smile:

Regards

KEP

[QUOTE=KEP;201510]I've just noticed, using PFGW version 3.2.7 the linenumber is no longer showing in the windows client as it used to in the previous versions. I know its a small and insignificant change or bug, but it's quite nice to know how far through the file one is exactly, without having to look at the pfgw.ini file :smile:

Regards

KEP[/QUOTE]

I found the problem. This is tied to a change from 3.2.0. In that release PFGW would not consistently output the result of tests when using -q. I will find a better fix for the problem.

By the way, if someone is still interested:
Just found out (again), why I used NewPGen format for PFGW: sr2sieve doesn't support other formats. So I have to sieve using ABCD format, and then convert the file to PFGW (or NewPGen format), for the prime tests.
Any other solutions?

[QUOTE=Xentar;201532]By the way, if someone is still interested:
Just found out (again), why I used NewPGen format for PFGW: sr2sieve doesn't support other formats. So I have to sieve using ABCD format, and then convert the file to PFGW (or NewPGen format), for the prime tests.
Any other solutions?[/QUOTE]

Isn't there a -a option for sr2sieve? I do agree that a -w option would be nice.

[quote=rogue;201541]Isn't there a -a option for sr2sieve? I do agree that a -w option would be nice.[/quote]
Actually, I thought sr2sieve always used ABCD (-a) format--I don't think it's even compatible with NewPGen format. The only other format it does is the old proth_sieve/JJSieve .dat format.

sr5sieve might be able to handle NewPGen format, though don't quote me on it.

sr1sieve uses NewPGen format exclusively.

[QUOTE=mdettweiler;201545]Actually, I thought sr2sieve always used ABCD (-a) format--I don't think it's even compatible with NewPGen format. The only other format it does is the old proth_sieve/JJSieve .dat format.

sr5sieve might be able to handle NewPGen format, though don't quote me on it.

sr1sieve uses NewPGen format exclusively.[/QUOTE]

I have been using srsieve with -w. It produces ABC formatted output. It shouldn't be difficult for Geoff to propagate it to his other programs.

Currently srsieve can use and output any format, sr1sieve must have Newpgen (-G or -g) format, and sr2sieve must have ABCD format (-a). With the super-speed design of sr2sieve, I don't think it could even be changed to accept anything other than ABCD format.

Xentar, for this project and for most other projects, NewPGen is a bad word. (lol) It should almost never be used. From my perspective, it should not be used for anything except super exotic forms. It's way slower than the sr(x)sieve series of programs.

Mark, sr2sieve does not write out sieve files. It only accepts ABCD (-a) format files as input and writes out factors. srfile is then used to take those factors, remove them from the input file, and write out a sieve file in any format that you want.

Also, one more thing Mark: Have you been using srsieve to fully sieve bases with more than one k remaining? If so, not good. I'm asking because it shouldn't be necessary to write out -w formatted files using srsieve. It should only be used to write out -G or -a formatted sieve files. (See why below.) Use sr2sieve after running srsieve to a nominal P-limit. It is 2 to 10 times faster. After it writes out the factors, you can use srfile to remove them and write the file out in whatever format that you want. In your case, that would be -w since you frequently test both sides of the same base at the same time.

For both of you guys, to be more specific, here's what you need to do for sieving on this project:

If testing more than one k:
1. Run srsieve to some small P-limit and have it write out the file in -a format. I use P=100e6 for the P-limit.
2. Use the output from #1 and run sr2sieve to your optimum depth. It will write out a file of factors called factors.txt. All you need is the P-limit and file name.
3. Use srfile to remove the factors in #2 from the file in #1 and write it out in -w or -G format.
4. If running the conjectures here, be sure and change the header to use the stop-on-prime option before beginning PFGW testing.

If testing only 1 k:
1. Same as #1 above except write it out in -G format.
2. Use the output from #1 and run sr1sieve to your optimum depth. It will automatically write the file out in -G format (same as NewPGen).
3. Same as #4 above.

The bottom line:
Srsieve is faster than NewPgen.
Sr2sieve is 2 to 10 times faster than Srsieve for sieving more than one k.
Sr1sieve is 2 to 3 times faster than Sr2sieve for sieving just one k.

Therefore:
Sr1sieve is likely 10 to 15 times faster than NewPgen for sieving just one k!!


Gary

Since PFGW is now by far the most integral program to CRUS, I have changed the thread name here.

I will do my best to always have links to the latest known and well-tested Windows and Linux versions of PFGW in the 1st post here.

Latest versions will not be automatically posted until several people have extensively tested them.

Mark and Xentar,

The info. that I gave 2 posts back here was already available in the software/instructions/questions. thread.

To remove any further confusion, I have made some changes there for more modern updates as a result of the increased speed of PFGW and the new bases script, which I specifically state must be used with PFGW 3.2.3 and before. I'll remove the version once I update it to include script changes for 3.2.7 after the Linux version is available. I also tweaked a few things for the sieving instructions for clarity.


Gary

All versions of 3.3.0 are now released. Here are the links:

[url]http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_win_3.3.0_20100108.zip[/url]
[url]http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_mac_3.3.0_20100108.zip[/url]
[url]http://openpfgw.svn.sourceforge.net/viewvc/openpfgw/pfgw_linux_3.3.0_20100108.zip[/url]

OK, if a few people could run some tests on 3.3.0, that would be great. I'll download it shortly. What I might suggest to everyone on brand new releases of PFGW is to "beta" test them using a few already known ranges.

Mark, once a few people have tested it, I'll update the first post here since that is specifically intended for the latest well-tested version. Thanks for the direct links! That helps a bunch. :-)

You didn't happen to get a build for Linux 3.2.7 did you? Since that is still the latest known well-tested version, I was hoping to test updates to my script with it before running tests on later versions that aren't as well tested just yet.


Thanks,
Gary

[QUOTE=gd_barnes;201629]You didn't happen to get a build for Linux 3.2.7 did you? Since that is still the latest known well-tested version, I was hoping to test updates to my script with it before running tests on later versions that aren't as well tested just yet.[/QUOTE]

Sorry, but I did not get a Linux build for 3.2.7. Fortunately no script changes are necessary for 3.3.0.

There is one known issue. It only exists in WinPFGW and is cosmetic. The "Line in file" field is not getting updated consistently. I have a patched version ready, but I am waiting for additional testing from others before I post it. If any bugs are revealed, I will make sure that those get fixed and get a new release out there.

[quote=rogue;201633]Sorry, but I did not get a Linux build for 3.2.7. Fortunately no script changes are necessary for 3.3.0.

There is one known issue. It only exists in WinPFGW and is cosmetic. The "Line in file" field is not getting updated consistently. I have a patched version ready, but I am waiting for additional testing from others before I post it. If any bugs are revealed, I will make sure that those get fixed and get a new release out there.[/quote]

OK, thanks. No problem. I'll use 3.3.0 for testing script changes. I'll probably start working on them tomorrow. Then once you release 3.3.1 (or whatever), I'll run some quick tests with it and hopefully will be able to update the 1st post here with a new latest well-tested version. :smile:

[QUOTE=gd_barnes;201575]
If testing more than one k:
1. Run srsieve to some small P-limit and have it write out the file in -a format. I use P=100e6 for the P-limit.
2. Use the output from #1 and run sr2sieve to your optimum depth. It will write out a file of factors called factors.txt. All you need is the P-limit and file name.
3. Use srfile to remove the factors in #2 from the file in #1 and write it out in -w or -G format.
4. If running the conjectures here, be sure and change the header to use the stop-on-prime option before beginning PFGW testing.[/QUOTE]
That's exactly, what I am doing. So, there is no easier way, without converting the file format.

Thank you for the explanation. :smile:

Many roundoff errors in 3.2.7...
 

Mark,

I am getting quite a few roundoff errors in PFGW 3.2.7.

I did quite a bit of extra comparison testing between versions 3.2.3 and 3.2.7 in an attempt to help you ultimately eliminate the errors.

Here are some roundoff errors that I got in version 3.2.3 (not originally tested in 3.2.7):
1780*112^19007+1
1696*112^19080+1
1780*112^19118+1
1696*112^19136+1
1696*112^19172+1

I subsequently tested these in 3.2.7 and there were no roundoff errors. That's a good thing. :smile:

Here are some roundoff errors that I got in version 3.2.7 (not originally tested in 3.2.3):
1379*138^9373+1
9000*93^4798+1
9844*93^6369+1
8224*93^9451+1
7868*93^9500+1
6748*93^9571+1
6748*93^9603+1
344*161^15982-1
378*161^18855-1

I subsequently tested these in 3.2.3 and found that they all had the same error EXCEPT one; the very last one: 378*161^18855-1, which tested correctly. That's not a good thing. :surprised:confused::cry:

The first test where 3.2.7 corrected all of the 3.2.3 errors is what I would expect.

I was taken aback by the second test. An error that occurred in 3.2.7 did NOT occur in 3.2.3!

My question is: Does this mean that new roundoff errors are being introduced?

I've attached many different files from my testing. Naming definitions:
input-errs-3.2.x = Input files of tests with the PFGW version # that produced errors.

pfgw.out-3.2.x-errs = The pfgw.out (regular results) file for the specified PFGW version #.

pfgw.out-3.2.x-errs-run-3.2.y = The pfgw.out file for errors produced in 3.2.x ran in 3.2.y.
[Example: pfgw.out-3.2.3-errs-run-3.2.7 = These were originally 3.2.3 errors but I subsequently ran them in 3.2.7 to verify that the errors were corrected. (In this case, since it's a newer PFGW version, it correctly came up with no errors. That is it shows that all tests are composite.)]

pfgw_err-3.2.x-errs = Self-explanatory. The original pfgw_err file where the errors came to light.

The major concern is file pfgw.out-3.2.7-errs-run-3.2.3.txt. This is the regular resutls file for 3.2.7 errors ran in version 3.2.3. If you look at the very last line, you'll see:
378*161^18855-1 is composite: RES64: [6221E6A7DC82F65B] (103.0717s+0.0029s)

This tells me that potentially a new error was introduced in version 3.2.7 that wasn't in 3.2.3.

One final note: When I used the -a1 switch on all of these, it ran a good test and showed them all to be composite.

I'll download 3.3.0 in a little while and start using it for testing. I won't be looking for roundoff errors...just that it runs fine. If so, I'll update the 1st post here with both the Windows and Linux versions of it. In a little while, I'll also look to start updating the new bases script for the scripting language updates introduced in 3.2.7.

Possible suggestion: If there is a roundoff error, would it make sense to have PFGW automatically run the same test a 2nd time? Perhaps on the 2nd test, have it run the same code that is executed when the -a1 switch is used.

Question: What about always testing using the -a1 switch? Would that make the tests take much longer?


Gary

[quote=gd_barnes;202548]Possible suggestion: If there is a roundoff error, would it make sense to have PFGW automatically run the same test a 2nd time? Perhaps on the 2nd test, have it run the same code that is executed when the -a1 switch is used.[/quote]
AFAIK thats the changes in 3.3:smile:

lol, I just downloaded 3.3.0 and read the release notes. You did exactly what I suggested in the last para. on the previous post. I subsequently reran the 3.2.7 errors through it and they all tested great!

The cool part is that the error didn't show up in pfgw.out. It's nice to have a good clean results file.

Obviously you can ignore my previous post. I thought about deleting it but I figured it might be good for reference if any problems crop up in the future.

By by roundoff errors (well, at least on a 2nd test anyway).

Nice work! :smile:


Gary

[quote=henryzz;202549]AFAIK thats the changes in 3.3:smile:[/quote]

Your post came through while I was typing mine. I had already concluded what you wrote. lol

I have now posted links to all 3 versions of PFGW 3.3.0 in the 1st post here.

I think we have a keeper. :smile:

There seems to be a small quirk/bug introduced with PFGW 3.2.7:

It appears that PFGW is automatically running an extra primality test on small tests that are found to be trivially prime when using the -f factoring switch. Here is an example from the pfgw.out file:

6*172^1+1 is trivially prime!
6*172^1+1 trivially factors prime!: 1033

While I don't think this causes a problem, per se, it makes for very irritating gui screen output. I like to keep the "output verbose screen" set to "screen normal" to see PRP's as they are kicked out so that I can see at a glance where testing is at. But with this issue, 100's of messages continue scrolling out that show "xx*xx^xx+1 is trivially prime!" making it difficult to see where it is at and slowing down processing slightly.

Can this be fixed?

I confirmed that the issue did not exist in version 3.2.3.

I've just about finished my new script changes for 3.2.7/3.3.0 and thought I had a bug in my code for quite a while.

One more thing that has been a small issue since release 3.1.0: When you do a mouse-over of WinPFGW.exe, it still shows versioin 3.1.0.0 in the little white box. I didn't check if it does that in the Linux version.


Gary

[QUOTE=gd_barnes;202567]There seems to be a small quirk/bug introduced with PFGW 3.2.7:

It appears that PFGW is automatically running an extra primality test on small tests that are found to be trivially prime when using the -f factoring switch. Here is an example from the pfgw.out file:

6*172^1+1 is trivially prime!
6*172^1+1 trivially factors prime!: 1033

While I don't think this causes a problem, per se, it makes for very irritating gui screen output. I like to keep the "output verbose screen" set to "screen normal" to see PRP's as they are kicked out so that I can see at a glance where testing is at. But with this issue, 100's of messages continue scrolling out that show "xx*xx^xx+1 is trivially prime!" making it difficult to see where it is at and slowing down processing slightly.

Can this be fixed?

I confirmed that the issue did not exist in version 3.2.3.

One more thing that has been a small issue since release 3.1.0: When you do a mouse-over of WinPFGW.exe, it still shows versioin 3.1.0.0 in the little white box. I didn't check if it does that in the Linux version.[/QUOTE]

I will change the message in the next release. I have no other changes accumulated for that release, so it might be a while before there is a 3.3.2.

The last issue was fixed in 3.3.0.

Regarding the roundoff/sumout errors. I modified PFGW to use an irrational FFT because there were cases that tests would not trigger a roundoff/sumout error, yet would not have correct results unless using the -a1 switch. This was a recommendation from George. This results in some tests getting roundoff/sumout errors that did not get them before (even though they had correct output without -a1 before). The more important thing is guaranteeing that the if no error is triggered, then one knows that the output is correct.

BTW, -a1 will slow the test down by a few percent. It can vary from number to number based upon the size of the number being tested.

[quote=Mini-Geek;198563]Out of nearly 2.5 million primes verified for a part of Riesel base 3, these 6 all return PRP, return composite with -tp but no -a1, and return prime with -tp and -a1:
[code]800157112*3^64-1
800829524*3^47-1
801245282*3^50-1
802324048*3^490-1
802829672*3^59-1
804875072*3^71-1[/code]I doubt that anybody cares or that anything needs to be done, just felt like reporting that little fact. :ermm:[/quote]
If I understand correctly, the new version should've stopped silent failures such as this, but it doesn't.
[CODE]PFGW Version 3.3.1.20100111.Win_Dev [GWNUM 25.13]

Primality testing 800157112*3^64-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 7, base 1+sqrt(7)
Special modular reduction using generic reduction x87 FFT length 32 on 800157112*3^64-1
800157112*3^64-1 is composite (0.0318s+0.0001s)
Primality testing 800829524*3^47-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 5, base 1+sqrt(5)
Special modular reduction using generic reduction x87 FFT length 32 on 800829524*3^47-1
800829524*3^47-1 is composite (0.0021s+0.0001s)
Primality testing 801245282*3^50-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 3, base 3+sqrt(3)
Special modular reduction using generic reduction x87 FFT length 32 on 801245282*3^50-1
801245282*3^50-1 is composite (4.9667s+0.0001s)
Primality testing 802324048*3^490-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 17, base 1+sqrt(17)
Special modular reduction using zero-padded FFT length 80 on 802324048*3^490-1
802324048*3^490-1 is composite (0.0154s+0.0001s)
Primality testing 802829672*3^59-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 5, base 1+sqrt(5)
Special modular reduction using generic reduction x87 FFT length 32 on 802829672*3^59-1
802829672*3^59-1 is composite (0.0023s+0.0001s)
Primality testing 804875072*3^71-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 5, base 1+sqrt(5)
Special modular reduction using generic reduction x87 FFT length 32 on 804875072*3^71-1
804875072*3^71-1 is composite (0.0023s+0.0001s)

Done.
[/CODE]

[QUOTE=Mini-Geek;202578]If I understand correctly, the new version should've stopped silent failures such as this, but it doesn't.
[CODE]PFGW Version 3.3.1.20100111.Win_Dev [GWNUM 25.13]

Primality testing 800157112*3^64-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 7, base 1+sqrt(7)
Special modular reduction using generic reduction x87 FFT length 32 on 800157112*3^64-1
800157112*3^64-1 is composite (0.0318s+0.0001s)
Primality testing 800829524*3^47-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 5, base 1+sqrt(5)
Special modular reduction using generic reduction x87 FFT length 32 on 800829524*3^47-1
800829524*3^47-1 is composite (0.0021s+0.0001s)
Primality testing 801245282*3^50-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 3, base 3+sqrt(3)
Special modular reduction using generic reduction x87 FFT length 32 on 801245282*3^50-1
801245282*3^50-1 is composite (4.9667s+0.0001s)
Primality testing 802324048*3^490-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 17, base 1+sqrt(17)
Special modular reduction using zero-padded FFT length 80 on 802324048*3^490-1
802324048*3^490-1 is composite (0.0154s+0.0001s)
Primality testing 802829672*3^59-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 5, base 1+sqrt(5)
Special modular reduction using generic reduction x87 FFT length 32 on 802829672*3^59-1
802829672*3^59-1 is composite (0.0023s+0.0001s)
Primality testing 804875072*3^71-1 [N+1, Brillhart-Lehmer-Selfridge]
Running N+1 test using discriminant 5, base 1+sqrt(5)
Special modular reduction using generic reduction x87 FFT length 32 on 804875072*3^71-1
804875072*3^71-1 is composite (0.0023s+0.0001s)

Done.
[/CODE][/QUOTE]

It should have, but obviously doesn't. This is a problem with gwnum that I cannot fix. This might have to wait until gwnum 26.x before it can be resolved. I'll see if George is able to spend time on it. Note that I do not know the conditions that trigger this problem, although it seems to only happen with small n.

[quote=rogue;202587]It should have, but obviously doesn't. This is a problem with gwnum that I cannot fix. This might have to wait until gwnum 26.x before it can be resolved. I'll see if George is able to spend time on it. Note that I do not know the conditions that trigger this problem, although it seems to only happen with small n.[/quote]
Hm...in the mean time, is there something that could be added to the script to make it run the primality proof as -a1 (preferably only after returning "composite" on a PRP) so it can be more sure before assuming it's really a composite and putting it in pl_compPRP.txt?

[QUOTE=Mini-Geek;202614]Hm...in the mean time, is there something that could be added to the script to make it run the primality proof as -a1 (preferably only after returning "composite" on a PRP) so it can be more sure before assuming it's really a composite and putting it in pl_compPRP.txt?[/QUOTE]

PFGW scripts cannot specify the -a switch. I'll think about a change, but can't make any promises.

I'm seriously concerned about the value of our proofs. I just did a doublecheck of all the primes found using WinPFGW version 3.2.0, with WinPFGW version 3.3.0. Of the 311882 primes from n=1 to n=2500, 589 of them were confirmed primes by version 3.2.0, but failed to be primes using version 3.3.0! Please notice, that all 589 primes, tested out as PRPs in both version 3.2.0 aswell in 3.3.0!

Now a 14 hour torture test has revealed that there is nothing wrong with my computer, so I'm thinking that either there is a problem in the script used in the "starting new bases" thread, or else there is a problem in WinPFGW. Eitherway, all my work is currently suspended, and if no satisfactoring explanation has been given to me within a 2 or 3 days, I'll not hacitate cancelling all my work.

So Rogue, Gary and anyone else, can you take a look at the files in the attached zip file and come up with an explanation or should I automatically conclude that the WinPFGW tool is not trustworthy and therefor all proofs and low primes should be double checked? So anyone, has an explanation. I may add that during some previous base 955 on the sierp side, i got some log files, where some of the numbers were concluded as: k*955^n+1 is unknown? That was using version 3.2.0, I have not seen this message in the log files using version 3.3.0.

Also doing a triple and comparisation test, 61 PRPs was confirmed primes using WinPGFW version 3.2.0, while they were never seen as anything but composite PRPs using version 3.3.0, you can see the k's that I'm talking about in the pfgw-prime.log file under the version 3.2.0 folder.

Sorry if I sound angry, but I do feel that the work I do, has to be trustworthy and productive, and if we all uses tools that produces composite primes, then our work is in fact a waste. But for now, consider ALL my reservations suspended, while an ongoing torture test is carried out.

If you have any questions, please feel free to ask them, and I'll answer them as good as I can. Again sorry for the tone I'm writing in, but I just hates to waste ressources.

Take care

KEP

Just tried your attached file.
Is it correct, that you are using the -t parameter?
But you are right. When I use the -t parameter, it actually thinks, every line is composite.
Without this parameter, it says for every line, that it is 3-PRP.

[QUOTE=Xentar;203983]Just tried your attached file.
Is it correct, that you are using the -t parameter?
But you are right. When I use the -t parameter, it actually thinks, every line is composite.
Without this parameter, it says for every line, that it is 3-PRP.[/QUOTE]

In both 3.2.0 and 3.3.0 PFGW versions I did use following commandline (after finding them all 3-PRP):

pfgw.log -t -lLog.txt

May I ask, what version of WinPFGW did you use? I'm asking because, what really concerns me is the fact that WinPFGW version 3.2.0, did find 61 of the composit primes as Prime, while it previously found all 589 k's prime. I should add, that getting the "is unknown" message, was also when using the -t flag.

Just came to think, can it have something to do with the base? Is there a flaw in the proof method which makes Sierp base 955 test errorneous? I'm here thinking, doesn't the Brillhart-Lehmer proof cover b=955 numbers the appropriate way?

KEP!

This is due to the change in PFGW to use irrational FFTs instead of rational FFTs. The change was made to address problems that would occur during a primality proof for some numbers. The proof would not detect a roundoff or sumout error, yet the test would have an incorrect result.

George knows about the issue (because it is in gwnum). He hopes to tackle it after his current vacation.

My recommendation is to use the -a1 switch if the number is PRP (via a PRP test) and the primality test says that the number is unknown. I know that this is a nuisance for everyone, but switching back to a rational FFT will not resolve the problem. It would only change the numbers that exhibit the problem.

[QUOTE=rogue;203998]This is due to the change in PFGW to use irrational FFTs instead of rational FFTs. The change was made to address problems that would occur during a primality proof for some numbers. The proof would not detect a roundoff or sumout error, yet the test would have an incorrect result.

George knows about the issue (because it is in gwnum). He hopes to tackle it after his current vacation.

My recommendation is to use the -a1 switch if the number is PRP (via a PRP test) and the primality test says that the number is unknown. I know that this is a nuisance for everyone, but switching back to a rational FFT will not resolve the problem. It would only change the numbers that exhibit the problem.[/QUOTE]

So just to be sure I understand correctly, all k's primes that is verified as primes using WinPFGW version 3.3.0, is SURE to be primes aswell those 589 k's being composites is sure to be composites? As long as the results for the primes produced using WinPFGW version <3.3.0, can be trusted, I guess no harm is done. However. I'm now if it is sure that these primes is composites, going to have to sieve those k's from n=1 to n=2500 to get them. So it will mean a little more work, however I'm ready to accept thath, just as long I can trust that those PRPs being found as primes, using both version 3.2.0 and 3.3.0 is actually primes.

Thanks for explaining, and sure I'll remember to use -a1 next time. Do you think Rogue that it should be nescessary to run a triple check of the primes using -a1 or should they be good to go when they are verified as primes for both version 3.2.0 and 3.3.0?

Regards

KEP

[QUOTE=KEP;204002]So just to be sure I understand correctly, all k's primes that is verified as primes using WinPFGW version 3.3.0, is SURE to be primes aswell those 589 k's being composites is sure to be composites? As long as the results for the primes produced using WinPFGW version <3.3.0, can be trusted, I guess no harm is done. However. I'm now if it is sure that these primes is composites, going to have to sieve those k's from n=1 to n=2500 to get them. So it will mean a little more work, however I'm ready to accept thath, just as long I can trust that those PRPs being found as primes, using both version 3.2.0 and 3.3.0 is actually primes.

Thanks for explaining, and sure I'll remember to use -a1 next time. Do you think Rogue that it should be nescessary to run a triple check of the primes using -a1 or should they be good to go when they are verified as primes for both version 3.2.0 and 3.3.0?[/QUOTE]

If the number is PRP and the primality test says it is prime (with both 3.2 and 3.3), then it is prime. If one of the following scenarios occurs, I would like to know about it:

1) PRP with both versions, prime with one version, not prime with the other and -a1 with the other still gives unknown.
2) PRP with both versions, prime with neither version. This is regardless if -a1 shows prime or unknown.

[QUOTE=rogue;204005]If the number is PRP and the primality test says it is prime (with both 3.2 and 3.3), then it is prime. If one of the following scenarios occurs, I would like to know about it:

1) PRP with both versions, prime with one version, not prime with the other and -a1 with the other still gives unknown.
2) PRP with both versions, prime with neither version. This is regardless if -a1 shows prime or unknown.[/QUOTE]

If you download the zip I attached, you can try the 61 PRPs that were found prime by version 3.2.0 but not by version 3.3.0, using -a1

Regarding number 2, 589 k's were PRP for both version 3.2.0 and 3.3.0 and of those, 528 k's with a PRP n wasn't prime on either version. The unknown, wasn't occurring in either version 3.2.0 or 3.3.0 for any of the double- triple- and quadrouple checked k's. But it happened around new years eve. Sadly I doesn't have the log file anymore, but it was running version 3.2.0 and with very small n's, n<=100.

Hope this helps.

KEP

[QUOTE=KEP;204018]If you download the zip I attached, you can try the 61 PRPs that were found prime by version 3.2.0 but not by version 3.3.0, using -a1

Regarding number 2, 589 k's were PRP for both version 3.2.0 and 3.3.0 and of those, 528 k's with a PRP n wasn't prime on either version. The unknown, wasn't occurring in either version 3.2.0 or 3.3.0 for any of the double- triple- and quadrouple checked k's. But it happened around new years eve. Sadly I doesn't have the log file anymore, but it was running version 3.2.0 and with very small n's, n<=100.[/QUOTE]

I will use those lists to help verify the next release of gwnum with PFGW.