Loading ...
Sorry, an error occurred while loading the content.
 

New AP14 record

Expand Messages
  • mikeoakes2@aol.com
    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
    • jkand71
      ... 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
      • Jeff Anderson-Lee
        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
        • jkand71
          ... 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
            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
            • Jens Kruse Andersen
              ... 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
              • mikeoakes2
                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
                • Jens Kruse Andersen
                  ... 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
                  • 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
                    • Jack Brennen
                      ... 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...
                      • mikeoakes2
                        ... 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.