[QUOTE=ATH;435431]The "-tc" options gives:
[CODE]is Fermat and Lucas PRP![/CODE]

which means the N-1 options I was wondering about has to be Fermat PRP, I guess base 3?[/QUOTE]

That is the default base. I think it would only give PRP if you can't use the base, but I don't know how to verify that.

pfgw 3.8.1 is now released. You can find Windows and Mac builds over at sourceforge.

The main change in this release is the support of a new file format I call "DECIMAL". This is the format I suggested over in the [URL="http://www.mersenneforum.org/showthread.php?t=16978"]Primes in π[/URL] thread. The distribution has a text file explaining the file format. The main reason I created this was to slim down the size of files input to pfgw for projects like Primes in π, which also includes Smarandache-Wellin and Copeland-Erdos searches.

FYI, the files on sourceforge only have 64-bit builds. If you absolutely need a 32-bit build, please let me know.

When you run the "N+1" test it does run 2-3 tests depending on the number before the last one gives: "Lucas PRP". I looked in the code but cannot find where the Lucas PRP test takes place.

Do you know or can quickly find out where that is? Maybe then the Lucas PRP could be a switch option like Fermat PRPs? The advantage is that combined with Fermat PRP test it would almost be a BPSW test (Fermat instead of Miller-Rabin test).

[QUOTE=ATH;435504]When you run the "N+1" test it does run 2-3 tests depending on the number before the last one gives: "Lucas PRP". I looked in the code but cannot find where the Lucas PRP test takes place.

Do you know or can quickly find out where that is? Maybe then the Lucas PRP could be a switch option like Fermat PRPs? The advantage is that combined with Fermat PRP test it would almost be a BPSW test (Fermat instead of Miller-Rabin test).[/QUOTE]

It isn't clear to me either. It seems that the switch with -t determines what it outputs. The primality test code in pfgw is pretty nasty stuff and I've not really touched the original code.

Hi. When running pfgw-3.7.10 on ubuntu 14.04 (64 bit) I get for some numbers a SIGILL error.
I tested on a Intel Core i7 920 and a Core i7 6700K.
Also version 3.8.1 for Windows is affected.

The problem seems to be related to the POWMOD function .
If you start the following minimal script in pfgw you get the error at the end of the POWMOD iterations.
[CODE]
SCRIPT
DIM result,0
POWMOD result, 10, (10^86453-1)/9, 22944*10^86454-229439
[/CODE]

[QUOTE=rogue;231402]I have released PFGW 3.4.0. You can d/l it from [URL="http://sourceforge.net/projects/openpfgw/files/"]here[/URL].

Here are the highlights of this release:
[list][*]Upgraded to gwnum v26.2[*]Upgraded to use GMP 5.0[*]First 64-bit release of PFGW. Both 32-bit and 64-bit distributed together.
..
A 64-bit build for Linux has not been included as it has not been built yet. This is related my last note above. I need to make it easier for the average person to build PFGW. It is just too difficult to do on *nix, now more so than ever since it needs to build both with a single makefile.[/QUOTE]

What does the Linux build setup look like? Perhaps we can simply with limited functionality to get it going again.

[QUOTE=Angular;438689]What does the Linux build setup look like? Perhaps we can simply with limited functionality to get it going again.[/QUOTE]

Steven Harvey hasn't had as much time. I could nudge him again.

As for building on Linux, it shouldn't be too hard. You need to build GMP and will need to install the gwnum components. There is a makefile that is up to date, but might need some changes to work on your specific Linux implementation. You can get code from sourceforge and from there, send me e-mails to help you thru the build process.

Thanks, yes please ask Steven I would appreciate that. I'm sure he could do a much better job that I.
I might be able to help some with the building although I am by no means a developer. Should I use the default gcc 4.8.x from CentOS 7.1 64b or the latest stable v5.4? (other distros are available as well)

Given the newer GW libraries available would you guess a double digit performance increase is possible? (pfgw 3.7.1 vs 3.8.1 9 months)

I don't see any of the PFGW source code on sourceforge: [url]https://sourceforge.net/projects/openpfgw/files/?source=navbar[/url]
Is this the latest gwnum from 2011? [url]https://github.com/rudimeier/mprime/tree/master/gwnum[/url]
GMP 6.0.0 looks to be in the centos epel repos, or 6.1.1 from the project website: [url]https://gmplib.org/[/url]

[QUOTE=Angular;438747]Thanks, I might be able to help some with the building although I am by no means a developer. Should I use the default gcc 4.8.x from CentOS 7.1 64b or the latest stable v5.4?

Given the newer GW libraries available would you guess a double digit performance increase is possible? (pfgw 3.7.1 vs 3.8.1 9 months)

I don't see any of the PFGW source code on sourceforge: [url]https://sourceforge.net/projects/openpfgw/files/?source=navbar[/url]

Is this the latest gwnum from 2011? [url]https://github.com/rudimeier/mprime/tree/master/gwnum[/url]

GMP 6.0.0 looks to be in the centos epel repos, or 6.1.1 from the project website: [url]https://gmplib.org/[/url][/QUOTE]

You can probably use either gcc.

I do not know what improvements were made to gwnum, but I don't think they were that significant.

Use this to check out the source code: svn checkout svn://svn.code.sf.net/p/openpfgw/code/ openpfgw-code

In the gwnum package directory I believe it tells you where to d/l the latest gwnum.

Use can use GMP 6.1.1, but you will have to build it on your own.

Unless anyone asks otherwise, I am going to remove ABCZ (aka PrZ) file support in the next release. This is in the pfgw documentation:

[code]
This is a highly compressed ABCD (or NewPGen) format file. The file
is compressed considerably more with the PrZ format, than it is with
PkZip (or RAR/LHA/ACE2/SITX), and it is "processable" by PFGW in the
compressed form. At this writing, the PrZ format is still a work in
progress, so the code itself will (may) change some.
[/code]

I don't think that file sizes are much of a concern today (compared to more than 10 years ago when this code was written).

[url]http://xkcd.com/1172/[/url]