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

New AP11/AP12 record

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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.