PFGW 3.2.0 has been Released

[3.14159]

Originally Posted by Karsten

George Woltman is the developer of the gwnum-library which is used by Prime95, PFGW and LLR.

He (or someone else) will notify here in the forum, so everyone will be aware of a new version!

Well, I hope there is no cost to speed on this next version! It would be a tragedy if there were.

[3.14159]

Will it be 3.4? Or 3.3.5? (Well, at least posting elsewhere solves the problem of being lonely in the kook section.)

[CRGreathouse]

Originally Posted by 3.14159

Well, I hope there is no cost to speed on this next version! It would be a tragedy if there were.

I'd rather wait for a correct result than get an incorrect one quickly.

[3.14159]

Originally Posted by CRGreathouse

I'd rather wait for a correct result than get an incorrect one quickly.

I would rather not have people make weak strawmen of my posts. But we can't all get what we want, can we?

[paulunderwood]

I'd like to know from the horses' mouths how the round off errors are affecting multi-million-bit numbers crunched by LLR (and PFGW), used by PrimeGrid -- not just "small" numbers such as those posted

[paulunderwood]

Originally Posted by kar_bon

Found this while testing some small cases:

pfgw -q"9238*619^619+1"
PFGW Version 3.3.4.20100405.Win_Stable [GWNUM 25.14]
9238*619^619+1 is composite: RES64: [AF5E2DAE777932BE] (0.1337s+0.0003s)

--------8< SNIP -----

but running again, lonely, they're not reproduceable!

Why there're these differences?

Is this a heat/electro/timing problem or a real bug?

[rogue]

Originally Posted by paulunderwood

Is this a heat/electro/timing problem or a real bug?

This is definitely a real bug. I can reproduce it.

[kar_bon]

Originally Posted by paulunderwood

Is this a heat/electro/timing problem or a real bug?

Don't know yet exactly. Heat seems not a problem (not overclocked) although I've run all 4 cores with prime-crunching.
Perhaps use of other programs during such PFGW-work can affect in some ways, but I have to test more here.

I've also 9 more examples of PRPs not found by LLR but PFGW -a1!

Originally Posted by rogue

This is definitely a real bug. I can reproduce it.

OK, good to hear this.

[rogue]

Originally Posted by kar_bon

Don't know yet exactly. Heat seems not a problem (not overclocked) although I've run all 4 cores with prime-crunching.
Perhaps use of other programs during such PFGW-work can affect in some ways, but I have to test more here.

I've also 9 more examples of PRPs not found by LLR but PFGW -a1!

Please PM me that list. Thanks.

[CRGreathouse]

Originally Posted by 3.14159

But we can't all get what we want, can we?

Surely not, because...

Originally Posted by 3.14159

I would rather not have people make weak strawmen of my posts.

...I'd rather not have people wrongly accuse me of making strawmen.

[Prime95]

Originally Posted by paulunderwood

Is this a heat/electro/timing problem or a real bug?

It is a real bug. Gwnum should choose a larger FFT size (or an error should have been raised during the test).

There are two factors that make Primegrid's (and others) search relatively safe from similar problems:

1) Larger FFTs are much better behaved regarding the variance of round off errors. This makes sense in that one is much more likely to get a truly random distribution of FFT data values when there are a million FFT data points as opposed to 768 in this case.

2) This error case is not base 2. The base 2 is much better tested. The non-base-2 cases are new to version 25. The code that determines which FFT size to use may still need fine tuning.

Note that this may not be a gwnum bug. The size selection code is a tradeoff between being 1) very ultra safe but using larger FFT sizes more often than most users would like, or 2) selecting a faster FFT size that works for almost all cases, but maybe one or two will fail (with an error detected during the primality test).

The important question, being researched now, is why were no roundoff errors detected so that these programs could tell the user not to trust the result (use a larger FFT size)?