Sorry, an error occurred while loading the content.

## New AP14 record

Expand Messages
• Here is a new AP14 record at 60 digits:- (211370029+22263450*n)*131#+1 is prime for n=0..13 All confirmed prime with PFGW -tc Input/output statistics:- Numbers
Message 1 of 11 , Sep 24, 2006
Here is a new AP14 record at 60 digits:-

(211370029+22263450*n)*131#+1 is prime for n=0..13

All confirmed prime with PFGW -tc

Input/output statistics:-
Numbers tested by NewPGen: 1*10^9
NewPGen reduced these (by sieving to 20G) to: 2.09*10^8
PRP's found by PFGW: 6.48*10^7
AP13's found: 8
AP14's found: 1

Run-time statistics:-
NewPGen: 1 GHz-hr
PFGW: 1 GHz-day
Pascal program to find AP's: 20 GHz-days

Poisson was kind: about 16 AP13's should have been needed to get an
AP14.

-Mike Oakes
• ... Congratulations on another AP record. Mike has now set the 4 latest: http://hjem.get2net.dk/jka/math/aprecords.htm#news -- Jens Kruse Andersen
Message 2 of 11 , Sep 24, 2006
Mike Oakes wrote:
> Here is a new AP14 record at 60 digits:-
>
> (211370029+22263450*n)*131#+1 is prime for n=0..13

Congratulations on another AP record. Mike has now set the 4 latest:
http://hjem.get2net.dk/jka/math/aprecords.htm#news

--
Jens Kruse Andersen
• Here is a new simultaneous AP11 and AP12 record at 128 digits:- ABC2 (1075032530+\$a*89982195)*283#+1 a: from 0 to 11 step 1 Jeff Anderson-Lee
Message 3 of 11 , Sep 25, 2006
Here is a new simultaneous AP11 and AP12 record at 128 digits:-

ABC2 (1075032530+\$a*89982195)*283#+1
a: from 0 to 11 step 1

Jeff Anderson-Lee
• ... Congratulations to a new AP record setter, the fourth to improve the AP12 this year: http://hjem.get2net.dk/jka/math/aprecords.htm#history12 That makes
Message 4 of 11 , Sep 25, 2006
Jeff Anderson-Lee wrote:
> Here is a new simultaneous AP11 and AP12 record at 128 digits:-
>
> ABC2 (1075032530+\$a*89982195)*283#+1
> a: from 0 to 11

Congratulations to a new AP record setter, the fourth to improve the
AP12 this year:
http://hjem.get2net.dk/jka/math/aprecords.htm#history12
That makes AP12 the largest battleground, but I guess Jeff's nice record
will last longer.

--
Jens Kruse Andersen
• Jeff Anderson-Lee wrote: Not to leave well enough alone, here is a new simultaneous AP11 and AP12 record at 173 digits:- ABC2 (1366899295+\$a*54290654)*401#+1
Message 5 of 11 , Dec 10, 2006
Jeff Anderson-Lee wrote:

Not to leave well enough alone, here is a new simultaneous AP11 and AP12
record at 173 digits:-

ABC2 (1366899295+\$a*54290654)*401#+1
a: from 0 to 11 step 1

Found using newpgen, pfgw/primeform, and custom sieving code. Proven
with pfgw.

Jeff Anderson-Lee
• ... Congratulations on a large improvement of your own records. http://hjem.get2net.dk/jka/math/aprecords.htm is updated. -- Jens Kruse Andersen
Message 6 of 11 , Dec 10, 2006
Jeff Anderson-Lee wrote:
> Not to leave well enough alone, here is a new
> simultaneous AP11 and AP12 record at 173 digits:-
>
> ABC2 (1366899295+\$a*54290654)*401#+1
> a: from 0 to 11 step 1

Congratulations on a large improvement of your own records.
http://hjem.get2net.dk/jka/math/aprecords.htm is updated.

--
Jens Kruse Andersen
• Here is a new AP14 records at 71 digits:- (145978014+25313115*n)*157#+1 is prime for n=0..13 All confirmed prime with PFGW -tc Input/output statistics:-
Message 7 of 11 , Dec 10, 2009
Here is a new AP14 records at 71 digits:-

(145978014+25313115*n)*157#+1 is prime for n=0..13

All confirmed prime with PFGW -tc

Input/output statistics:-
Numbers tested by NewPGen: 2*10^9
NewPGen reduced these (by sieving to 100 billion) to: 4.06*10^8
PRP's found by PFGW: 112,989,593
AP13's found: 2
AP14's found: 1

Run-time statistics:-
NewPGen: 5 GHz-hrs
PFGW: 2 GHz-days
Pascal program to find an AP14: 57 GHz-days

The AP13 count was well below the Poisson-expected 16.
The search program was killed at this point, at about 1/4 of the way through.

Jens, this only creeps marginally above your nontrivial 2007 record announced in:
http://tech.groups.yahoo.com/group/primeform/message/8760
Do you have any stats on that - or on your search algorithm?
(I can't see that any further speed-up is possible with mine.)

-Mike Oakes
• ... Congratulations on beating my record. http://users.cybercity.dk/~dsl522332/math/aprecords.htm is updated. ... My old file shows 16 AP13 before the AP14. It
Message 8 of 11 , Dec 10, 2009
Mike Oakes wrote:
> Here is a new AP14 records at 71 digits:-
>
> (145978014+25313115*n)*157#+1 is prime for n=0..13

Congratulations on beating my record.
http://users.cybercity.dk/~dsl522332/math/aprecords.htm is updated.

> Jens, this only creeps marginally above your nontrivial 2007 record
> announced in:
> http://tech.groups.yahoo.com/group/primeform/message/8760
> Do you have any stats on that - or on your search algorithm?

My old file shows 16 AP13 before the AP14.
It was on my 2.4 GHz Core 2 Duo. The AP14 was found with a
C program 9 days after the AP detection stage started.
It probably ran nearly the whole time but I don't remember.
It used one core. Another project ran on the other core.
It's my only computer and is also used for lots of other
things but usually not cpu intensive.
I guess it used around 20 GHz days on AP detection.

I will get back to you on search algorithm within a couple
of days when I have better time.
The program has not changed since the start of 2005.
I think we have discussed something about algorithms since then.
I have not searched AP's since 2007.

--
Jens Kruse Andersen
• ... I use the same C program as when we discussed in April 2006: http://tech.groups.yahoo.com/group/primeform/message/7180
Message 9 of 11 , Dec 12, 2009
Mike Oakes wrote:
> Do you have any stats on that - or on your search algorithm?
> (I can't see that any further speed-up is possible with mine.)

I use the same C program as when we discussed in April 2006:
http://tech.groups.yahoo.com/group/primeform/message/7180
http://tech.groups.yahoo.com/group/primeform/message/7185

Back then you said your detector doesn't try to optimize caching.
I said no cache optimization is bad in a program mostly doing
lookups in large tables.
I don't know whether your program has changed since then.
Some of my programs become several times faster when they
work on smaller tables or parts of a table at a time, so the used
data fits in cache most of the time.
If it's complicated to get good cache performance with large tables
then you can consider making several smaller tables one at a time
and only search for AP's fitting inside a small table. You will need
more prp's if you only test potential AP's with small common
differences but better cache performance may be well worth it.

C also tends to be faster than Pascal.
Make sure the Pascal compiler doesn't add code for array bounds checking.

--
Jens Kruse Andersen
• ... Years ago when I wrote a program to search for small long CCs and BiTwins, I found a roughly 3x - 5x performance boost by working in smaller chunks of
Message 10 of 11 , Dec 12, 2009
Jens Kruse Andersen wrote:
> I said no cache optimization is bad in a program mostly doing
> lookups in large tables.
> I don't know whether your program has changed since then.
> Some of my programs become several times faster when they
> work on smaller tables or parts of a table at a time, so the used
> data fits in cache most of the time.

Years ago when I wrote a program to search for small long CCs
and BiTwins, I found a roughly 3x - 5x performance boost by
working in smaller chunks of memory which could fit in the
CPU's level 1 memory cache.

Yeah, 3x - 5x faster...
• ... I m sure what you say here is very important - I ll have another look at precisely that caching question. (It s not easy, tho...) ... Not much,
Message 11 of 11 , Dec 12, 2009
--- In primeform@yahoogroups.com, "Jens Kruse Andersen" <jens.k.a@...> wrote:
>
> Mike Oakes wrote:
> > Do you have any stats on that - or on your search algorithm?
> > (I can't see that any further speed-up is possible with mine.)
>
> I use the same C program as when we discussed in April 2006:
> http://tech.groups.yahoo.com/group/primeform/message/7180
> http://tech.groups.yahoo.com/group/primeform/message/7185
>
> Back then you said your detector doesn't try to optimize caching.
> I said no cache optimization is bad in a program mostly doing
> lookups in large tables.
> I don't know whether your program has changed since then.
> Some of my programs become several times faster when they
> work on smaller tables or parts of a table at a time, so the used
> data fits in cache most of the time.
> If it's complicated to get good cache performance with large tables
> then you can consider making several smaller tables one at a time
> and only search for AP's fitting inside a small table. You will need
> more prp's if you only test potential AP's with small common
> differences but better cache performance may be well worth it.

I'm sure what you say here is very important - I'll have another look at precisely that caching question. (It's not easy, tho...)

> C also tends to be faster than Pascal.
Not much, necessarily.
I co-authored the compiler I'm using:
http://en.wikipedia.org/wiki/Prospero_Pascal
so am familiar with (how good:-) its code generator is.

> Make sure the Pascal compiler doesn't add code for array bounds checking.
Of course!

Thanks for your input.

Mike
Your message has been successfully submitted and would be delivered to recipients shortly.