On Tuesday 23 July 2002 10:25, Paul Leyland wrote:
> George,
>
> I think I've found two bugs in Prime95 or, at least, serious
> misfeatures. I don't know whether they've been fixed in more recent
> releases but as I'm using the program in a rather creative manner I
> suspect not. The Mersenne list is Cc:ed so that if anyone else wishes
> to use your program in this way they will be aware of the problems and
> take appropriate countermeasures.
>
> Bug 1: A factor specified in lowm.txt or lowp.txt which is more than a
> hundred or so decimal digits is not read correctly and is incorrectly
> reported as not dividing the M or P number being factored. The exact
> length at which it fails wasn't determined directly but it's around that
> size.
Umm.
My guess would be that whatever buffer space is set aside for known factors
(or the product of known factors) is insufficiently large, so something gets
trampled on.
>
> Bug 2: If worktodo.ini contains two lines specifying ECM work to be
> done, and a factor is found of the first number, the worktodo.ini file
> is truncated to zero size and Prime95 halts. In my opinion it's a
> misfeature that the program doesn't append the new factor to
> low{m,p}.txt and continue with the remaining curves on that integer but
> I accept that may not be what everyone wants. Wiping out all remaining
> lines *is* a bug in my opinion.
Sure. But it hasn't happened to me when I've found factors (up to 44 digits).
I thought the "continue after finding factor" feature was set by default -
doesn't one have to set ContinueECM=0 in prime.ini if one wants to abort
after finding a factor? The exception being if the cofactor is determined to
be a probable prime, in which case there is no point in continuing...?
Maybe fixing any "short buffer" problem would fix this problem too.
Regards
Brian Beesley
_________________________________________________________________________
Unsubscribe & list info -- http://www.ndatech.com/mersenne/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
