From: David W. Cantrell on
On Jan 26, 4:11 am, David W. Cantrell <DWCantr...(a)sigmaxi.net> wrote:
> David W.Cantrell<DWCantr...(a)sigmaxi.net> wrote:
>
> > Also see the OEIS entry for the number of decimaldigitsin n! :
> > <http://www.research.att.com/~njas/sequences/A034886>,
> > in particular, the last item in the formula section. I wonder if
> > the formula given in that item is correct.

The author of [1] recently informed me that, as indicated in the OEIS
entry, it is merely based on Stirling's approximation, without proof
that it is correct for all n >= 2. But see below...

> Now that I've had some time to think about it, I must say that I
> doubt the correctness of that formula:
>
> floor((log(2 pi n)/2 + n (log(n) - 1))/log(10)) + 1 [1]
>
> Indeed, I now have a heuristic argument that [1] should fail to give
> the number of decimaldigitsin n! correctly for infinitely many n,
> with the first failure occurring before n = 600000 with 50%
> probability and before n = 6 * 10^11 with 100% probability. (Of
> course, the first n for which [1] fails may be difficult to find.)

My heuristic argument is very simple. Note that the number of decimal
digits in n! is (obviously) given by
floor(logGamma(n + 1)/log(10)) + 1. The difference between
logGamma(n + 1)/log(10) and (log(2 pi n)/2 + n (log(n) - 1))/log(10)
is approximately 1/(12 log(10) n), the infinite sum of which goes to
infinity, albeit very slowly. (Harmonic series.) That is, the sum of
the lengths of the intervals
[(log(2 pi n)/2 + n (log(n) - 1))/log(10), logGamma(n + 1)/log(10)]
is infinite. If any such interval happens to contain an integer, then
floor of (log(2 pi n)/2 + n (log(n) - 1))/log(10) will be smaller by 1
than floor of logGamma(n + 1)/log(10), and so cause formula [1] to
fail.

But I have not found any n for which [1] fails. And so I am now led
to wonder if there is something happening which is not captured in the
heuristic argument -- number theoretically, maybe -- which causes
[1] to give the correct number of decial digits in n! for all n >= 2.
I would appreciate other people's thoughts on this matter.

> But there is a very simple modification to the formula which should,
> according to a heuristic argument, make it valid, with high
> probability, for all n >= 1:
>
> floor((log(2 pi n)/2 + n (log(n) - 1) + 1/(12 n))/log(10)) + 1 [2]

Using the same sort of heuristic reasoning:
The difference between
(log(2 pi n)/2 + n (log(n) - 1) + 1/(12 n))/log(10) and
logGamma(n + 1)/log(10) is approximately 1/(360 log(10) n^3).
The sum of the lengths of the intervals
[logGamma(n + 1)/log(10), (log(2 pi n)/2 + n (log(n) - 1) + 1/(12
n))/log(10)], from n = 1..oo, is zeta(3)/(360 log(10)) = 0.00145...,
making it unlikely that any such interval would happen to contain an
integer.

Investigations in other bases:

Of course, my formula [2] can be modified to give the number of base-b
digits in n! by simply replacing log(10) with log(b). It seems that,
so modified, [2] works correctly for all n >= 1 and for all bases b.

But, when similarly modified, formula [1] fails in some bases. (It
fails in all bases for n = 1, but that is of little interest.
Henceforth, we consider just n > 1.) It will fail at n in base b if
b = n! For example, it fails in base 6 for n = 3 because b = 6 = 3!
and it fails in base 2 for n = 2 because b = 2 = 2! Here are the
other failures I've found in various bases:

b n
5 47
6 2751
12 516
14 29
14 4799
14 11321

In all those cases, not surprisingly, n! in base b consists of 1
followed by some 0's. For example, in base 14, we have 29! =
1006bb5d6db12a825d9398ac0000

The fact that formula [1], when modified for base b, fails in some
bases strengthens my skepticism about its working in base 10 for
all n >= 2.

David W. Cantrell
From: David W. Cantrell on
"David W. Cantrell" <DWCantrell(a)sigmaxi.net> wrote:
> On Jan 26, 4:11 am, David W. Cantrell <DWCantr...(a)sigmaxi.net> wrote:
> > David W.Cantrell<DWCantr...(a)sigmaxi.net> wrote:
> >
> > > Also see the OEIS entry for the number of decimaldigitsin n! :
> > > <http://www.research.att.com/~njas/sequences/A034886>,
> > > in particular, the last item in the formula section. I wonder if
> > > the formula given in that item is correct.
>
> The author of [1] recently informed me that, as indicated in the OEIS
> entry, it is merely based on Stirling's approximation, without proof
> that it is correct for all n >= 2. But see below...
>
> > Now that I've had some time to think about it, I must say that I
> > doubt the correctness of that formula:
> >
> > floor((log(2 pi n)/2 + n (log(n) - 1))/log(10)) + 1 [1]
> >
> > Indeed, I now have a heuristic argument that [1] should fail to give
> > the number of decimaldigitsin n! correctly for infinitely many n,
> > with the first failure occurring before n = 600000 with 50%
> > probability and before n = 6 * 10^11 with 100% probability. (Of
> > course, the first n for which [1] fails may be difficult to find.)
>
> My heuristic argument is very simple. Note that the number of decimal
> digits in n! is (obviously) given by
> floor(logGamma(n + 1)/log(10)) + 1. The difference between
> logGamma(n + 1)/log(10) and (log(2 pi n)/2 + n (log(n) - 1))/log(10)
> is approximately 1/(12 log(10) n), the infinite sum of which goes to
> infinity, albeit very slowly. (Harmonic series.) That is, the sum of
> the lengths of the intervals
> [(log(2 pi n)/2 + n (log(n) - 1))/log(10), logGamma(n + 1)/log(10)]
> is infinite. If any such interval happens to contain an integer, then
> floor of (log(2 pi n)/2 + n (log(n) - 1))/log(10) will be smaller by 1
> than floor of logGamma(n + 1)/log(10), and so cause formula [1] to fail.
>
> But I have not found any n for which [1] fails. And so I am now led
> to wonder if there is something happening which is not captured in the
> heuristic argument -- number theoretically, maybe -- which causes
> [1] to give the correct number of decial digits in n! for all n >= 2.
> I would appreciate other people's thoughts on this matter.
>
> > But there is a very simple modification to the formula which should,
> > according to a heuristic argument, make it valid, with high
> > probability, for all n >= 1:
> >
> > floor((log(2 pi n)/2 + n (log(n) - 1) + 1/(12 n))/log(10)) + 1 [2]
>
> Using the same sort of heuristic reasoning:
> The difference between
> (log(2 pi n)/2 + n (log(n) - 1) + 1/(12 n))/log(10) and
> logGamma(n + 1)/log(10) is approximately 1/(360 log(10) n^3).
> The sum of the lengths of the intervals
> [logGamma(n + 1)/log(10), (log(2 pi n)/2 + n (log(n) - 1) + 1/(12
> n))/log(10)], from n = 1..oo, is zeta(3)/(360 log(10)) = 0.00145...,
> making it unlikely that any such interval would happen to contain an
> integer.
>
> Investigations in other bases:
>
> Of course, my formula [2] can be modified to give the number of base-b
> digits in n! by simply replacing log(10) with log(b). It seems that,
> so modified, [2] works correctly for all n >= 1 and for all bases b.
>
> But, when similarly modified, formula [1] fails in some bases. (It
> fails in all bases for n = 1, but that is of little interest.
> Henceforth, we consider just n > 1.) It will fail at n in base b if
> b = n! For example, it fails in base 6 for n = 3 because b = 6 = 3!
> and it fails in base 2 for n = 2 because b = 2 = 2! Here are the
> other failures I've found in various bases:
>
> b n
> 5 47
> 6 2751
> 12 516
> 14 29
> 14 4799
> 14 11321

Oops. To avoid confusion I should have specified that my values of n are
given in _decimal_ notation.

> In all those cases, not surprisingly, n! in base b consists of 1
> followed by some 0's. For example, in base 14, we have 29! =
> 1006bb5d6db12a825d9398ac0000

That is, (29_10)! = 1006bb5d6db12a825d9398ac0000_14.

DWC

> The fact that formula [1], when modified for base b, fails in some
> bases strengthens my skepticism about its working in base 10 for
> all n >= 2.
>
> David W. Cantrell
From: Richard Tobin on
In article <19ce633c-f872-4f7c-9a67-4587b1cee338(a)z26g2000yqm.googlegroups.com>,
David W. Cantrell <DWCantrell(a)sigmaxi.net> wrote:

>The fact that formula [1], when modified for base b, fails in some
>bases strengthens my skepticism about its working in base 10 for
>all n >= 2.

Could you determine whether it fails for 3121515!. I don't have the
facilities to hand to check it accurately.

-- Richard
--
Please remember to mention me / in tapes you leave behind.
From: David W. Cantrell on
richard(a)cogsci.ed.ac.uk (Richard Tobin) wrote:
> In article
> <19ce633c-f872-4f7c-9a67-4587b1cee338(a)z26g2000yqm.googlegroups.com>,
> David W. Cantrell <DWCantrell(a)sigmaxi.net> wrote:
>
> >The fact that formula [1], when modified for base b, fails in some
> >bases strengthens my skepticism about its working in base 10 for
> >all n >= 2.
>
> Could you determine whether it fails for 3121515!. I don't have the
> facilities to hand to check it accurately.

Thanks for your suggestion.

3121515! = 1.000000695... * 10^18916606

and so it has 18916607 decimal digits. The formula given in the OEIS entry
works correctly in this case. For n = 3121515, the interval

[(log(2 pi n)/2 + n (log(n) - 1))/log(10), logGamma(n + 1)/log(10)] =

[18916606.000000290..., 18916606.000000301...]

and so does not contain an integer.

Any other suggestions?

David
From: Chip Eastham on
On Feb 6, 1:56 am, David W. Cantrell <DWCantr...(a)sigmaxi.net> wrote:
> "David W. Cantrell" <DWCantr...(a)sigmaxi.net> wrote:
>
>
>
> > On Jan 26, 4:11 am, David W. Cantrell <DWCantr...(a)sigmaxi.net> wrote:
> > > David W.Cantrell<DWCantr...(a)sigmaxi.net> wrote:
>
> > > > Also see the OEIS entry for the number of decimaldigitsin n! :
> > > > <http://www.research.att.com/~njas/sequences/A034886>,
> > > > in particular, the last item in the formula section. I wonder if
> > > > the formula given in that item is correct.
>
> > The author of [1] recently informed me that, as indicated in the OEIS
> > entry, it is merely based on Stirling's approximation, without proof
> > that it is correct for all n >= 2. But see below...
>
> > > Now that I've had some time to think about it, I must say that I
> > > doubt the correctness of that formula:
>
> > > floor((log(2 pi n)/2 + n (log(n) - 1))/log(10)) + 1              [1]
>
> > > Indeed, I now have a heuristic argument that [1] should fail to give
> > > the number of decimaldigitsin n! correctly for infinitely many n,
> > > with the first failure occurring before n = 600000 with 50%
> > > probability and before n = 6 * 10^11 with 100% probability. (Of
> > > course, the first n for which [1] fails may be difficult to find.)
>
> > My heuristic argument is very simple. Note that the number of decimal
> > digits in n! is (obviously) given by
> > floor(logGamma(n + 1)/log(10)) + 1. The difference between
> > logGamma(n + 1)/log(10)  and  (log(2 pi n)/2 + n (log(n) - 1))/log(10)
> > is approximately 1/(12 log(10) n), the infinite sum of which goes to
> > infinity, albeit very slowly. (Harmonic series.) That is, the sum of
> > the lengths of the intervals
> > [(log(2 pi n)/2 + n (log(n) - 1))/log(10), logGamma(n + 1)/log(10)]
> > is infinite. If any such interval happens to contain an integer, then
> > floor of (log(2 pi n)/2 + n (log(n) - 1))/log(10) will be smaller by 1
> > than floor of logGamma(n + 1)/log(10), and so cause formula [1] to fail..
>
> > But I have not found any n for which [1] fails. And so I am now led
> > to wonder if there is something happening which is not captured in the
> > heuristic argument -- number theoretically, maybe -- which causes
> > [1] to give the correct number of decial digits in n! for all n >= 2.
> > I would appreciate other people's thoughts on this matter.
>
> > > But there is a very simple modification to the formula which should,
> > > according to a heuristic argument, make it valid, with high
> > > probability, for all n >= 1:
>
> > > floor((log(2 pi n)/2 + n (log(n) - 1) + 1/(12 n))/log(10)) + 1    [2]
>
> > Using the same sort of heuristic reasoning:
> > The difference between
> > (log(2 pi n)/2 + n (log(n) - 1) + 1/(12 n))/log(10)  and
> > logGamma(n + 1)/log(10) is approximately 1/(360 log(10) n^3).
> > The sum of the lengths of the intervals
> > [logGamma(n + 1)/log(10), (log(2 pi n)/2 + n (log(n) - 1) + 1/(12
> > n))/log(10)], from n = 1..oo, is zeta(3)/(360 log(10)) = 0.00145...,
> > making it unlikely that any such interval would happen to contain an
> > integer.
>
> > Investigations in other bases:
>
> > Of course, my formula [2] can be modified to give the number of base-b
> > digits in n! by simply replacing log(10) with log(b). It seems that,
> > so modified, [2] works correctly for all n >= 1 and for all bases b.
>
> > But, when similarly modified, formula [1] fails in some bases. (It
> > fails in all bases for n = 1, but that is of little interest.
> > Henceforth, we consider just n > 1.) It will fail at n in base b if
> > b = n!  For example, it fails in base 6 for n = 3 because b = 6 = 3!
> > and it fails in base 2 for n = 2 because b = 2 = 2!  Here are the
> > other failures I've found in various bases:
>
> > b    n
> > 5    47
> > 6    2751
> > 12   516
> > 14   29
> > 14   4799
> > 14   11321
>
> Oops. To avoid confusion I should have specified that my values of n are
> given in _decimal_ notation.
>
> > In all those cases, not surprisingly, n! in base b consists of 1
> > followed by some 0's. For example, in base 14, we have 29! =
> > 1006bb5d6db12a825d9398ac0000
>
> That is, (29_10)! = 1006bb5d6db12a825d9398ac0000_14.
>
> DWC
>
> > The fact that formula [1], when modified for base b, fails in some
> > bases strengthens my skepticism about its working in base 10 for
> > all n >= 2.

Hi, David:

I suspect your heuristic arguments are correct,
and we are simply frustrated by the horribly
slow divergence of the harmonic series.

Have the intervals of disagreement between [1]
and [2] been exhaustively checked up to some
point, e.g. n = 600000 as you supposed would
give a 50% chance of counterexample? It seems
this would be easy to program, and if none is
found, the data might suggest some systematic
reason for failure.

regards, chip