Output bug in mmff

ATH · 2012-09-17, 23:23

Ops I thought this was a typo on http://www.prothsearch.net/fermat.html but instead it seems to be a bug in mmff:

Quote:

F43 has a factor: 3916660235220715932328394753 [TF:91:92:mmff 0.23 mfaktc_barrett96_F32_63gs]
found 1 factor for k*2^45+1 in k range: 111318G to 111319G (92-bit factors) [mmff 0.23 mfaktc_barrett96_F32_63gs]

F85 has a factor: 246947940268608417020015902258307792897 [TF:127:128:mmff 0.23 mfaktc_barrett128_F64_95gs]
found 1 factor for k*2^87+1 in k range: 1595G to 1596G (128-bit factors) [mmff 0.23 mfaktc_barrett128_F64_95gs]

These 2 factors 111318179143061*2⁴⁵+1 and 1595863660157*2⁸⁷+1 are actually factors of F42 and F83 like the webpage reports not F43 and F85 as mmff reports, I checked this in c++ with GMP library as well.

Can someone correct the title of the thread?

ATH · 2012-09-17, 23:52

Found a third one:

Quote:

F118 has a factor: 4563438810603420826872624280490561141381005313 [TF:151:152:mmff 0.23 mfaktc_barrett152_F96_127gs]
found 1 factor for k*2^120+1 in k range: 3G to 4G (152-bit factors) [mmff 0.23 mfaktc_barrett152_F96_127gs]

This factor 3433149787*2¹²⁰+1 is a factor of F116, not F118.

R. Gerbicz · 2012-09-18, 01:43

Quote:

Originally Posted by ATH

Ops I thought this was a typo on http://www.prothsearch.net/fermat.html but instead it seems to be a bug in mmff:

These 2 factors 111318179143061*2⁴⁵+1 and 1595863660157*2⁸⁷+1 are actually factors of F42 and F83 like the webpage reports not F43 and F85 as mmff reports, I checked this in c++ with GMP library as well.

Can someone correct the title of the thread?

Yes, it is a serious bug. Have you checked that this code finds all known Fermat (prime) divisors (and the code doesn't contain them in a big table)

ATH · 2012-09-18, 02:11

Quote:

Originally Posted by R. Gerbicz

Yes, it is a serious bug. Have you checked that this code finds all known Fermat (prime) divisors (and the code doesn't contain them in a big table)

I checked all larger factors. The program only support n>27 and n<160 and only support k>= 2²⁴ or larger, depends a bit on the n and m I think. I checked all factors I can get the program to work with, which was 29<=n<=149 and most of the factors with k>10⁷.

LaurV · 2012-09-18, 02:52

At least, is a very good sign that it finds them

(for n>m-2, if we name Fm and k*2^n+1, I wondered if it will find factors if n>m-2 strictly).

(stupid question: are the third a new factor, or you tested to see if it re-finds an older factor?)

edit: @Gerbicz: I hope you wanted to be ironical. This is not a serious bug, as long as we have the right k, finding n is piece of cake... and about the program having the factors in a table, are you implying that George is a charlatan or what? I really hope you just joked!

Prime95 · 2012-09-18, 03:04

This is almost certainly a bug in the aptly named "dumb num" routines in tf_validate.h

Prime95 · 2012-09-18, 03:56

dumb num fixed in 0.24. If you find a new Fermat factor in 0.23 and earlier, we'll need to verify which Fermat number the factor really divides.

flashjh · 2012-09-18, 15:47

Quote:

Originally Posted by Prime95

dumb num fixed in 0.24. If you find a new Fermat factor in 0.23 and earlier, we'll need to verify which Fermat number the factor really divides.

Have you posted .24 source code yet?

Prime95 · 2012-09-18, 15:57

Quote:

Originally Posted by flashjh

Have you posted .24 source code yet?

Not yet. Let's wait a few days to see if any other bugs are reported.

2012-09-18, 02:52	#5
LaurV Romulan Interpreter "name field" Jun 2011 Thailand 10,273 Posts	At least, is a very good sign that it finds them (for n>m-2, if we name Fm and k2^n+1, I wondered if it will find factors if n>m-2 strictly). (stupid question: are the third a new factor, or you tested to see if it re-finds an older factor?) edit: @Gerbicz: I hope you wanted to be ironical. This is not a serious bug, as long as we have the right k, finding n is piece of cake... and about the program having the factors in a table, are you implying that George is a charlatan or what? I really hope you just joked! Last fiddled with by LaurV on 2012-09-18 at 02:55*

Similar Threads
Thread	Thread Starter	Forum	Replies	Last Post
GFN factoring with mmff-gfn \| Reservations	Batalov	Operazione Doppi Mersennes	41	2017-01-03 03:32
GFN factoring with mmff-gfn \| Results	Batalov	Operazione Doppi Mersennes	126	2016-11-12 12:22
mmff checkpoints	houding	Factoring	1	2015-09-02 19:32
mmff parameters	MattcAnderson	Operazione Doppi Mersennes	2	2015-07-08 15:28
My mmff got clogged	MattcAnderson	Operazione Doppi Mersennes	6	2014-12-18 08:52

2012-09-18, 03:04	#6
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 1FD8₁₆ Posts	This is almost certainly a bug in the aptly named "dumb num" routines in tf_validate.h

2012-09-18, 03:56	#7
Prime95 P90 years forever! Aug 2002 Yeehaw, FL 1111111011000₂ Posts	dumb num fixed in 0.24. If you find a new Fermat factor in 0.23 and earlier, we'll need to verify which Fermat number the factor really divides.