Number of zero's in largest prime...

[paulunderwood]

Originally Posted by patrik

My guess is 350 000 000 zeros.

Let p be the exponent, 30 402 457. Then the number of digits in base i is about p log 2 / log i. (Rounding to an integer towards +inf gives the exact number.)

Looking at the distribution of digits for base 10 it looks like the digits are equally likely to occur. We know that this is not true for base 2. (And if we think a bit about it we realise it is also not true for bases 4, 8, 16, 32, ....)

Assuming it were true for all bases we could estimate the number of zeros for base i to be (p log 2) / (i log i), and for all bases, (p log 2) sum_2^M(p) 1 / (i log i).

Or we could start the summing at 3 since we know our assumption is wrong for base i=2. And following Uncwilly's argument we stop the summing at base M(p) since there are no more zeros after that.

The sum can be approximated by the integral of dx / (x log x). The primitive functions are log (log x), and we get (approximate equalities):

log ( log M(p) ) - log( log 2.5 ) = log ( p log 2 ) - log ( log 2.5 ) = 16.95

After multiplying by the prefactor (p log 2) we arrive at 357 million, which I round down to 350 million since I inluded the bases 4, 8, 16 etc in the estimate.

We need to sum for base < 2^(30402457/2) because a larger base will have at most 2 digits. Does this make a significant difference to your estimation?

[paulunderwood]

After multiplying by the prefactor (p log 2) we arrive at 357 million, which I round down to 350 million since I inluded the bases 4, 8, 16 etc in the estimate.

That's a bit harsh considering there are about log_2(M43)/M43 such bases

[Uncwilly]

Originally Posted by paulunderwood

Your code is okay, except the loop for "base" should be up to 2^30402457-1 and not 30402457 .

True, oops.

Originally Posted by paulunderwood

The loop should bail out when digits count became two

Because there are no X0 values, because that implies an even divisor?

Originally Posted by paulunderwood

and you could have coded with "-1".

I left the number to help average things.

Originally Posted by paulunderwood

I haven't checked "patrik"'s claim but at least your brute force method's expected number of zeroes is less than "patrik"'s mathematically computed expected number of them.

Originally Posted by patrik

After multiplying by the prefactor (p log 2) we arrive at 357 million, which I round down to 350 million since I inluded the bases 4, 8, 16 etc in the estimate.

His, 3.5x10⁸, is smaller than mine, 1.5x10⁹ and as you pointed out I didn't go anywhere near high enough.

Maybe we need to go back to the drawing board.

[Citrix]

My best estimate will be

Sigma((log2(M43)/(log2(x)*x))) for x from 2 to M43. I do not know the exact value of this? Any one know how to estimate this?

Citrix

[paulunderwood]

Does not end in zero...

Originally Posted by Citrix

Can you prove this?

Firstly take any two digit representation. None apart from 10 (base M43) can end zero by considering M43==20 (base B) which is 2*B+0==M43, but M43 is prime.

Now take the three digit representations. None can end in zero becase we would have a*B^2+b*B+0==M43 (a,b<B) i.e. B (<M43) divides M43 -- a contradiction.

This can be continued for all arbritary length representation all the way to its binary form.

Whether this skews the figures in patrik's mathematical aproximation, I do not know.

On a separate note, it might also be more accurate to use a computer for small bases (ie. long strings) and to use a mathematical method for the rest.

[paulunderwood]

Quote:
Originally Posted by paulunderwood
I haven't checked "patrik"'s claim but at least your brute force method's expected number of zeroes is less than "patrik"'s mathematically computed expected number of them.

Quote:
Originally Posted by patrik
After multiplying by the prefactor (p log 2) we arrive at 357 million, which I round down to 350 million since I inluded the bases 4, 8, 16 etc in the estimate.

Quote Uncwilly:
His, 3.5x108, is smaller than mine, 1.5x109 and as you pointed out I didn't go anywhere near high enough.

Maybe we need to go back to the drawing board.

\end{quotes}

Maybe! But remember your program used "log( Prime ) / log( Base )" which is wrong and grossly over estimated the number of zeroes.

[Uncwilly]

Originally Posted by paulunderwood

Does not end in zero...
.
Now take the three digit representations. None can end in zero becase we would have a*B^2+b*B+0==M43 (a,b<B) i.e. B (<M43) divides M43 -- a contradiction.
.
Whether this skews the figures in patrik's mathematical aproximation, I do not know.

And none can start with a zero, so my program needs to be adjusted to subtract 2 from every length, prior to division.

Originally Posted by paulunderwood

On a separate note, it might also be more accurate to use a computer for small bases (ie. long strings) and to use a mathematical method for the rest.

I had started with the following formula in exsell: CEILING(30402457*LOG(2,ROW()+2)/(ROW()+2),1) in row 1
This yields 915206 for base 10, while Mike's count is 913468.
I ran this through base 65538 (max rows in exsell plus 2) and summed, yielding 52,282,506
Modifying this by subtracting 2 per base yields, 52,151,434
Since UBasic only allows for natural log, I found the conversion and applied that to the formula that I used.


Does any one have or can point to, code (or simple algorithm) to convert to different bases? I could expand the number to various bases and then count the zeros. Lest I be accused of being lazy, this is so that I can "stand on the shoulders of giants".

[grandpascorpion]

This will print out the digits in reverse order for base b

while (n>0,print(n%b);n=floor(n/b));

=========================================

Here's my crack at the answer
x=30402457
Ln(x) = the natural log of x
p=2^x-1;
Let R(n) = floor(p^(1/n))

For z digit numbers, there are z-2 possible eligible digits to be zero.
We only need to consider bases through R(2) basically the floor(sqrt(p). Any number higher would have less than three digits and thereby not contribute a zero (the exception being where the base equals p itself)

Number
digits --- Sum the probabilites of the range:
1 * sigma( i=R(3)+1 to R(2), the value 1/i)
2 * sigma (i=R(4)+1 to R(3), the value 1/i)

..............

d * sigma(i=R(d+2)+1 to R(d+1), the value 1/i)

...............

x-2 * 1/2

Add 1 zero for base p

Sum across all number of digits, and you can rearrange the sum as

1 + sigma(i=1 to x-2, sigma(j=2,R(i), of 1/j))

simplify:
1 + sigma(i=1 to x-2, (Ln(p)/i -1))

simplify again:
(sigma(i=1 to x-2),1/i) * Ln(p)) - x -1 = 17.8072*x*Ln(2)-x-1 = 344856436

Now we have to deduct the contribution from bases b where b= 2^k (where k = 1 to x/2). That sum is sigma (k=1 to x/2 of (ceil(x/k) -2)/2^k) = 21073376
(BTW, the sum doesn't increase past the next integer after k=21)

So my estimate is roughly 324 million somewhat lower than patrik's.

[Uncwilly]

Originally Posted by grandpa scorpion

This will print out the digits in reverse order for base b

while (n>0,print(n%b);n=floor(n/b));

How well does that work for base 37? I think that that might work in a larger base if an array is used to store the digit characters. Although, for our case, we don't need to store the value, just check if your print statement yields a '0'. But, holding a number ~10m digits in memory and doing math on it is a bit out of the range of most simple languages.

Since, we also have the binary, could we not derive the nonadecimal (for example) expansion a bit more efficiently than a large number of divisions and mod's?

Originally Posted by Paul Underwood

Maybe! But remember your program used "log( Prime ) / log( Base )" which is wrong and grossly over estimated the number of zeroes.

This was to convert the from natural log to log_base. The program that I was using only has natural log and not log10. Maybe I am misunderstanding, but to get the number digits in base X doesn't one need log_X?

[Uncwilly]

Suggestion to the moderators: Create a duplicate thread in the math area starting at post 8, then delete posts 9--> in the original, and finally delete delete 54 (this post) in the duplicate.

[paulunderwood]

let B^e=2^30402457

then: log(B^e)=log(2^30402457) independent of which base the log is taken

or: e*log(B)=30402457*log(2)

e (the length in base B) will be 30402457*log(2)/log(B)

because in our case "e" is a whole number, maybe I would take ceiling(30402457*log(2)/log(B))

So I think your:

 10   Prime = 30402457 : Zeros=0
 20   for Base = 3 to Prime
 30   L_g = log( Prime ) / log( Base )
 40   N_l = L_g * Prime
 50   Digits = ( N_l / Base )
 60   Zeros = Zeros + Digits
 70   next Base
 80   print Zeros

gives the wrong answer: 1,529,591,493 zeroes.

I'll have to do my own guess but others' estimates for 300M-350M zeroes in all possible whole number representations of M43 seem reasonable to me.