[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)