My Apologies

[chalsall]

Originally Posted by Rodrigo

How about 190M? http://www.mersenne.info/?s=100000000&d=1&t=1

That range is about to start being handed out by the server to those who have selected "LMH - TF" on the client.

So, to answer your question in the negative, why don't you do what we've been advising you do for some time, and simply select "LMH - TF" on your client and let the system do what it was designed to do?

Originally Posted by Rodrigo

Which leads me to something I'd been meaning to ask. After all these years and with so many people participating, why is there (apparently) still so much work left undone in the very low ranges? (I.e., http://www.mersenne.info/?s=0&d=2&t=1 )

No doubt there is a good reason.

Indeed there is...

Remember we told you earlier that the smaller the exponent, the longer TFing takes. Besides, all those low numbers have already been LLed and DCed, so from the project's main objective (finding primes) there is no point in doing additional work on them.

Not to say that you can't, however; and some do and are. But keep in mind it would take your slow machines months to move a single low exponent up by one factor depth, with *very* little chance of finding a factor (because of the PM-1 and possibly EMC factoring attempts done on them).

[Rodrigo]

chalsall,

Thanks for the explanation. I suspected it might have something to do with it taking longer to TF a smaller exponent; just wanted to make sure my suspicion was warranted.

Yes, LMH-TF does look more and more like the place to go. Things were up in the air for a bit because we were considering OBD, but that's looking less likely now for the P75.

I've signed up the first of my computers to do work, and will be adding each of the others in turn as I get better acquainted with the process. In fact I'll be starting a new thread shortly with a couple of questions about the program settings. But it's already churning away!

Gratefully,

Rodrigo

[Rodrigo]

Originally Posted by Primeinator

I think all of those exponents have been factored past 62 bits (which, if I remember correctly, was the limit of what your oldest machine is capable of).

Primeinator,

How can I look up what that limit is?

Thanks!

Rodrigo

[lavalamp]

There is a little table on here:
http://www.mersenne.org/various/math.php

I'll reproduce it here slightly edited:

        Exponents     Bit
          up to      depth
        ---------    -----
         3960000      60
         5160000      61
         6515000      62
         8250000      63
        13380000      64
        23390000      65
        29690000      66
        37800000      67
        47450000      68
        58520000      69
        75670000      70
        96830000      71

This relationship between log(exponent) and bit depth is roughly linear, with a bit of a kink around 64 and 65 bits.

If you plot the log of the exponent against the bit depth (log to base 2 of the trial factor to depth), you get a nice straight line from a bit depth of 65 onwards.

I added a trend line to that and the equation was this:

ln(E) = 0.2346*D + 1.7171

Where E is the exponent and D is the bit depth.

So using this, it's tentatively possible to extend the table, but whether or not this linear relationship should continue I don't know. Assuming it does, here's what the numbers would be:

        Exponents     Bit
          up to      depth
        ---------    -----
        23390000      65
        29690000      66
        37800000      67
        47450000      68
        58520000      69
        75670000      70
        96830000      71
       120640000      72
       152530000      73
       192860000      74
       243860000      75
       308340000      76
       389860000      77
       492940000      78
       623280000      79
       788070000      80
       996440000      81
      1259900000      82
      1593020000      83
      2014220000      84
      2546790000      85
      3220170000      86
      4071590000      87

So it seems as though Operation Billion Digits should be taking numbers to 87 bits, and currently there are 10 (soon to be 13) exponents that are at 81 bits.

Also, the first lot of 100 million digit candidates should be trial factored to 77 bits.

Once again, I do not know if this linear relationship between exponent and trial factor depth should continue. So take it with a pinch of salt until someone who actually knows something about it makes a comment.

[axn]

Originally Posted by lavalamp

I added a trend line to that and the equation was this:

ln(E) = 0.2346*D + 1.7171

Where E is the exponent and D is the bit depth.

So using this, it's tentatively possible to extend the table, but whether or not this linear relationship should continue I don't know. Assuming it does, here's what the numbers would be:

        Exponents     Bit
          up to      depth
        ---------    -----
        23390000      65
        29690000      66
        37800000      67
        47450000      68
        58520000      69
        75670000      70
        96830000      71
       120640000      72
       152530000      73
       192860000      74
       243860000      75
       308340000      76
       389860000      77
       492940000      78
       623280000      79
       788070000      80
       996440000      81
      1259900000      82
      1593020000      83
      2014220000      84
      2546790000      85
      3220170000      86
      4071590000      87

So it seems as though Operation Billion Digits should be taking numbers to 87 bits, and currently there are 10 (soon to be 13) exponents that are at 81 bits.

Also, the first lot of 100 million digit candidates should be trial factored to 77 bits.

Once again, I do not know if this linear relationship between exponent and trial factor depth should continue. So take it with a pinch of salt until someone who actually knows something about it makes a comment.

Close enough. The rule of thumb is, doubling of exponent = 3 more bits. If you make it so that the bit depth changes are aligned to FFT size changes, that should be good enough. But since we're looking at only the OBD exponents, the figure 87 bits should be within +/- 1 bit of optimal. Since P-1 is not yet practical on these size exponents, maybe that number can be increased.

[Uncwilly]

Originally Posted by lavalamp

Also, the first lot of 100 million digit candidates should be trial factored to 77 bits.

That is what George says.

[lavalamp]

Originally Posted by axn

If you make it so that the bit depth changes are aligned to FFT size changes, that should be good enough.

I don't suppose there's a list of these somewhere, or some method to work out what size exponents fit into what size FFT? The benchmark page on mersenne.org only gives exponent ranges for FFT sizes up to 4M, but I know that Prime95 runs to at least 32M.

I wasn't only looking at OBD exponenets by the way, I just gave them a special mention, along with the 100 million digit candidates.

[S485122]

Originally Posted by lavalamp

I don't suppose there's a list of these somewhere, or some method to work out what size exponents fit into what size FFT?

You will find the FFT size for all exponent ranges up to 596M in the source code. I attach an zipped excel file for those to lazy to look it up.

Jacob

[davieddy]

Originally Posted by axn

The rule of thumb is, doubling of exponent = 3 more bits.

This can be understood simply:
Doubling the exponent quadruples the time for an LL test,
and halves the number of trial divisors 2kp + 1.

Note also that doubling the exponent multiplies the
computing required to find a Mersenne prime by 8:
the time is 4 times longer and the probability of it
being prime is halved.
If doubling the digits every 3.8 years is to be maintained,
I would guess that GIMPS needs India and/or China to
catch the bug!

David

[lavalamp]

Originally Posted by S485122

You will find the FFT size for all exponent ranges up to 596M in the source code. I attach an zipped excel file for those to lazy to look it up.

I downloaded your excel file, so I am clearly lazy.

I also downloaded the source code for Prime95 and looked through the files, none of which are named in such a way as to appear a likely place to contain such information, not that I saw at least. Upon searching the contents of many (MANY) of them, I still have not found it. Since you seem to know where the needle sized array is located in this haystack of 431 files, could you please drop a name?

[S485122]

Originally Posted by lavalamp

I downloaded your excel file, so I am clearly lazy.

I also downloaded the source code for Prime95 and looked through the files, none of which are named in such a way as to appear a likely place to contain such information, not that I saw at least. Upon searching the contents of many (MANY) of them, I still have not found it. Since you seem to know where the needle sized array is located in this haystack of 431 files, could you please drop a name?

You will find the table in mult.asm
But you could also search the forum : the subject has been treated already.

Jacob