> I like the thread of saving multiple residues at various checkpoints along
> the way. George suggested a % completion series. I might suggest a
> specific series of points -- like every L(1000k). This might be
> simpler to
> track in a database although the number of entries grows linearly
> with p so
> the data storage might grow with p^2, depending. Another series like
> k*floor(p/s) would work just as well and keep the data needs smaller as it
> would have just s+1 checkpoints (s can be fixed for all p).
I think we could keep it simple by just saving every x% iteration's residue
(in truncated form). Using a WAG of saving it every 10% along the way,
you'd only have 9 partial and 1 full residue when all is said and done.
So for an exponent like 8027219, you'd save the partial residue at the 10%,
or 802722th iteration (rounding up or down as normal). Of course, the
number of iterations varies just slightly from the exponent, but
whatever...you get the idea.
These partial residues could be sent (for the first LL test) during the
check-ins, or saved up and all sent at once when the test is done.
> Might the v.17 problem have been trapped with something like
> this? I do not
> recall enough of the discussion to know and the ensuing belly-aching
> overshadowed the real content of finding/fixing/reworking. (I know I am
> never going to rise high on the list, so I do not worry a whole lot about
> how much my report shows.)
I don't think so, since it produced the wrong data right from the start,
regardless. A double-check on a different platform (non GIMPS code like
MacLucas) would have caught it earlier though I suppose.
_________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
Mersenne Prime FAQ -- http://www.tasam.com/~lrwiman/FAQ-mers
