Second reply to the same message...
On Mon, May 03, 1999 at 11:22:02AM -0700, Mersenne Digest wrote:
>Date: Fri, 30 Apr 1999 10:44:16 -0600
>From: "Blosser, Jeremy" <[EMAIL PROTECTED]>
>Subject: Mersenne: JavaPrime update... (Lotsa Questions)
>
>b) Would it be more optimal to use a properly sized FFT to do the
>calculation than to use the 256k or 512k FFT. For example, a 64k FFT is
>subsecond, so is it feasable to initialize several different FFT engines for
>properly sized numbers.
I doubt so. Considering that the number is small only perhaps the 100 first
iterations (or so), and is at its largest at the last millions, it will only
be of extra complexity. Remember, the number is never getting larger than
the Mersenne prime itself.
>c) At some point, doing the math via FFT will become more expensive that a
>disk read (Especially if we plan on doing the 1,000,000,000 digit prime). So
>wouldn't a DB type lookup be more efficient at that point?
That would require an enormous lot of space! Consider just a 1K FFT:
2^1024 entries of 1 kilobyte each gives:
179769313486231590772930519078902473361797697894230657273430081157732
675805500963132708477322407536021120113879871393357658789768814416622
492847430639474124377767893424865485276302219601246094119453082952085
005768838150682342462881473913110540827237163350510684586298239947245
938479716304835356329624224137216
different combinations. I don't think we will see harddisks of this size
before the sun goes out, I'm afraid.
Or perhaps I've really missed your point ;-)
>e) Can N=N^2-2 be represented as a series? If so, wouldn't that be faster?
Keep in mind the modulo...
/* Steinar */
________________________________________________________________
Unsubscribe & list info -- http://www.scruz.net/~luke/signup.htm
