Short answer:

This is a round off problem exhibited in release build 1.1

Long answer:

In the 1.1 release of PFGW, when it builds the FFT's, it finds which

FFT size to use, and simply used it with the number of bits per limb

listed. The FFT size selected for this number was 32,23 (32 fft

limbs at 23 bits per limb). However, this number only requires

5.04 limbs (at 32 bits per limb), so it was simply "shoved" down

into the bottom of the FFT number. There is a current development

version of PFGW which behaves differently when building the FFT

contexts. It knows that this number fits into a 32,23 FFT, but it

then looks and finds that it fits in a 32,22 or a 32,21 ... or a

32,16. It choses to use a 32,16 (32 limbs with 16 bits per limb).

This eliminates ANY possiblity of round off issues, while still

processing the number using 32 FFT elements (same speed).

Within the current release 1.1 PFGW, there is a option which forces

pfgw to select a FFT using fewer than maximal number of bits. This

is the authentication function. Simply putting -a1 on the command

line switch will force PFGW to use 1 less bit per limb (possibly

causing it to have to use more limbs also). This helps reduce the

issues of FFT round off by using FFT's with less bits of precision

per limb. There is also a -a2 which reduces the number of bits

per limb by 2 bits. The drawback to 1 or 2 bits less per limb is

felt when this causes the number of FFT limbs to increase. When the

number of limbs increases, this causes a 20-65% slowdown for testing

the number.

One huge point of clarification. Using a tool such as PFGW which

uses FFT numbers exclusivly is a huge overkill. It is like duck

hunting with a tank. Sure it works, but it is probably far from

optimal. PFGW is probably at least 10 to 50 times slower on numbers

of this size than a program which uses "classical" or Karatsuba math,

such as GMP or Miracl. I am not sure if there currently is a GMP

program which does things like PFGW does, but for numbers under

2^1000, a program like that would be preferable over the current

FFT only PFGW.

Jim.

--- In primenumbers@y..., "Nuutti Kuosa" <nuutti.kuosa@i...> wrote:

> I tried this :

> ABC2 2^116+5766300710013+$a

> a: from 0 to 2028

>

> and I got that :

> 2^116+5766300710013+0 is composite: (0.000000 seconds)

>

> and primeform.exe gave :

> 2^116+5766300710013+0 is probable prime! (a = 4243) (digits:35)

>

> Yours,

>

> Nuutti

>

> -----Original Message-----

> From: Phil Carmody [mailto:fatphil@a...]

> Sent: 2. marraskuuta 2001 18:40

> To: primenumbers@y...

> Subject: RE: [PrimeNumbers] New prime gap L=2000

>

>

> On Fri, 02 November 2001, "Nuutti Kuosa" wrote:

> > I had some problems with pfgw.exe when I tried to verify the gap.

> > May be the ABC2 file format does not support that big numbers.

>

> Something as simple as

> <<<

> ABC2 _your_initial_prime_here_ + $a

> a: from 0 to _your_gap_length_here_

> >>>

>

> should work. 'step 2' can be added to skip the evens!

>

> Phil