I know I initially warned everyone that PIES was a finite
project, due to the fact that Dan Bernstein's FFT library
topped out at 8192 limbs. All those months, over a year,
ago, it looked like such worries were merely abstract, so
far in the future. However, time marches on, and ranges
come, and ranges go; so the finiteness has finally become
glaringly obvious.

If we look back at what we've achieved in the last year, I
think we can collectively be very pleased. With the fruitful
(no pun intended, honest) cherry range, we darted straight
up to #1 in the top-20-by-number table, and with the heftier
peach range ("worth" >8 cherries each, roughly) we managed
to sneak up to #4 on the top-20-by-score table. We've slipped
down by one slot for both of those now, but even still it's
a great position to be in. (And in 2 years' time the current
#1 by count will have 0 primes, while we'll have over 250!)

So I'd like to thank you all for your participation - without
your CPUs, this wouldn't have happened in such a spectacular
way. I hope that you continue to help me drain the peach range
as the year ends - I'm sure there are 40-50 more 100000+-digit
primes still left to find as 2005 approaches.

And I'll need all the help I can get, as in the next few days
I have to pull my machines off the peach range...



(
. Why,
. Phil
. ?
. Tell
. us
. why
. !
. )


... onto the apples.

:-D

I'm in the early stages of testing the exponent 98304. So far
I can see no problems, but I need to do _months_ of testing
before I "go live" (i.e. I want to find _1_ prime myself just
so I can be sure that I'll not be wasting your CPU power).
Testing's much more laborious; when Raffi kindly did early
testing of the 24576 range, he found a dozen primes in only a
few weeks. However, these apples are big blighters - they'll
start at the ~140000-digit size, and will quickly grow to
180000-200000 digits. Each one is worth >8 peaches.

One thing that's astounding is the density of the primes in the
new range. The density coefficient is 23; i.e. these numbers
are 23 times as likely as arbitrary numbers to be prime. That
means that the new program passes the tests - the whole testable
range will probably contain nearly _100_ primes. Compare that
to Yves' 32768 GFN range. He found 35 primes, his density being
only 5.8 (so he found more primes than expected).

Consequently, this is an _enormous_ task. Sieving (which I'm
currently doing, up to 10^14 already so I've got a fair estimate
of how many candidates will remain) is barely making a dent
in the range - the density is just astounding.

So I will probably need you guys, or at least your CPUs, more
than ever! The once finite task has turned into a monster!

One slight drawback is that I shall probably be limited to only
x86 clients. (But those with other architectures can help sieve,
which would be much appreciated.) I will probably be limited
only to linux. (*BSD runs linux binaries though.) Both of these
are beyond my control, as basically the new FFT library I have
is distributed as an object file for linux/x86. I think I can do
windows users with a 15-30% speed hit by using a different FFT
library. I'll not tempt you too much with real speeds yet, as
unless the code is correct (there are no known primes to check
against, so only time will tell), speeds are irrelevant.

However, as a taster: at my program's sweet spot, over 200000
digits, it's over 8 times faster than PFGW on the same number
on my Duron/900 (5814s rather than 48530s). Remember that PFGW
has to do a 3-multiply modular reduction on this number,
which slows it down greatly; it's not a fair comparison.

http://fatphil.org/maths/PIES/98304ann.html

Thanks for reading, I'll keep you all posted with more information
anon.

Phil