Talk:Champernowne constant

Error in continued fraction?

I think the nice image here containing the continued fraction terms is incorrect in the last partial term. I rediscovered this curious continued fraction for myself recently after writing a small program which accepted an infinite decimal expansion on standard input and produced its continued fraction terms on standard output as they became uniquely determined; but my program says that the 163rd term begins "44457", not "40012" as claimed in the picture on this page.

Of course my program could be faulty - the page itself does mention that Champernowne's constant can stress naive continued-fraction calculation code - but I have two reasons to think it isn't faulty: firstly, the two previous very large terms start "457" and "4457", making me willing to believe that the next one starts "44457", and secondly I googled up [1] which agrees to the last digit with my 163rd term and not with the one here. (That page, incidentally, also shows the next ludicrously large number starting with "444457", continuing the pattern.)

So I've prepared a replacement image and uploaded it to [2] (it's unfortunately slightly wider because of my available fonts), but I hesitate to unilaterally replace the image on this page without somebody doing an independent check of my findings.

(If anyone cares, my program - in Python - is available at [3]. I don't recommend using it to check my findings, obviously, since of course that will give the same answer as I got! But if someone disagrees with my result, they might wish to point out to me where the bug is.)

- Simon Tatham 86.6.4.136 08:05, 29 April 2007 (UTC)

I confirmed that the image was incorrect and removed it. — Preceding unsigned comment added by 24.19.214.109 (talk) 01:19, 2 August 2011 (UTC)

Reason for large terms

Also, I believe I understand why those extremely large terms show up in the expansion. However, I hesitate to add it to the page, because it might constitute original research (I thought of it for myself). On the other hand, it's pretty simple and was instantly obvious to me on examining the convergents, so perhaps it's not original enough to be a problem. I'd like a judgment call from an experienced Wikipedian, if one is available.

My argument is as follows:

The decimal expansion of 1/99^2 is 0.0001020304..., that of 1/999^2 is 0.000001002003004..., and in general the expansion of 1/(10^n-1)^2 consists of a sequence of integers incrementing from zero at each n-digit position. (You can check this by working out $\sum _{i=0}^{\infty }10^{-(i+1)n}i$ as a GP of GPs.) Of course the pattern in each of these expansions breaks once the integers start carrying from one n-digit segment into the previous one, and being rational they must end up repeating somehow.

So we can use this fact to directly construct a very good approximation to Champernowne's constant which goes as far as (for example) the end of the 2-digit numbers. Simply start with 1/99^2, which actually contains the digit sequence 10111213...9697. Then multiply by 10^11 to bring that sequence to the correct decmial place, and we have 10203040.506070809101112... Now adjust it to get the first few digits right (which involves subtracting exactly 10203040.38261402), and we end up with 60499999499/490050000000 - which is indeed the 18th convergent of the continued fraction for Champernowne's constant. In a similar way we could construct an approximation which went as far as the end of the 3-digit numbers, with a denominator only barely larger than that required to specify the 2-digit section, and so on. That's why there are extremely good approximations available for this number, and hence why the continued fraction contains very large terms after each of them.

(I don't, however, understand why there are intermediate large terms, such as the 102nd which begins "97867".)

- Simon Tatham 86.6.4.136 08:05, 29 April 2007 (UTC)

Something that's always bothered me

The article says this number is "obviously" normal in base 10, which I know means all the digits occur with equal frequency. However, after the first 190 digits, 0.12345678910111213...9899, the digit 0 has occurred much less than the others because we do not write 01, 02, 03 etc. The same is true after we add all the 3-digit numbers, all the 4-digit numbers and so on. Why it is "obvious" that the probability of a random digit being 0 eventually catches up, so to speak? 91.105.60.254 (talk) 01:54, 24 November 2007 (UTC)

Excellent question. I suppose it has something to do with leading digits mattering less as the numbers get longer. DanBishop (talk) 21:06, 30 August 2009 (UTC)

I just did some calculations. Let P(N) be the proportion of 0's in the concatenation of the integers 1 to N inclusive. Then P(9) = 0, P(99) = 0.047619047619, P(999) = 0.0654205607477, P(9,999) = 0.0742883591761, P(99,999) = 0.0795456637396, P(999,999) = 0.0830188852261, P(9,999,999) = 0.0854838724428. DanBishop (talk) 21:32, 30 August 2009 (UTC)

This is similar to the argument that the integers are countable. While any finite termination of the number will have fewer 0s, all digits will occur a countably infinite number of times over its infinite extent. Law of Entropy (talk) 04:52, 29 May 2012 (UTC)

Yes, but that does not say anything about the relative frequencies of each digit. Consider a infinite sequence composed of the terms a_3n+0, b_3n+1, and c_3n+2, for all n ≥ 0, where each a and b are odd and each c is even; obviously, the sequence contains an infinite number of odd and even numbers, yet the odd terms occur with twice the frequency of the even terms. If the decimal Champernowne constant C₁₀ is normal, then the proportional of zero digits should have a limit of 1⁄10. Since Champernowne proved that it is indeed normal, we should see DanBishop's P(N) above increase towards 0.1 as N increases, which it appears to do. — Loadmaster (talk) 20:28, 25 July 2012 (UTC)

Of course. I was specifically addressing the OP's "cut the number off after X digits" approach, and why that's exactly never going to give you 1/10 for the frequencies. Law of Entropy (talk) 09:34, 23 November 2012 (UTC)

In reply to the section creator, and working out a formula in support of DanBishop's argument, the "best" proof I could think of is to construct similar numbers C, Ch, Cha, Cham, Champ, etc. defined as

the sum of 10^n terms (k / 10^kn). E.g.

C = 0.123456789,

Ch = 00.0102030405060708091011...979899, ...

Champ = 00000.00001 00002 00003 00004 00005 00006 00007 00008 00009 00010...99998 99999...

These don't approximate the Champernowne number, but we can count all digits except 0 easily and find that there are exactly (n/10) 10^n of each. The '0' digits are a bit nonstandard here, and when written in standard form, C, Ch, Cha... lose exactly n of them because they appear before the decimal point. (But n in (n/10)10^n soon becomes negligible.)

On to the differences between digits of C, Ch, Cha... and the Champernowne number: The latter doesn't use fixed-length numbers, but omits all leading 0 digits, of which there are none in C, 10 in Ch, 10+100 in Cha, and generally (10^n-10) / 9 in the nth of the lot.

That grows like O(10^n) rather than O(n 10^n) and becomes negligible for truly long excerpts of C10.

Finally, if we truncate elsewhere (not at a power of 10 - and a complete proof of normality must include those cases), say at 5 googol, we'd have more digits 1 to 4 than 5 to 9, but as we look at more and more decimals, these fluctuations start to "drown" in a "sea" of equifrequent trailing digits. Googol (included) to 5 googol (excluded) would contribute a total of 404 (no pun intended) googol digits: 40 googol '0' digits, (40+1) googol digits 1 to 4 each, and 40 googol digits 5 to 9. Again, deviations from equifrequency are within O(m) if we stop at m, and average digit frequencies are O(m log m).

I think we should say a few more sentences about the normalization of C10 in the article, but that would require an already published accessible (both in language that's easy to understand, and available free of charge) proof somewhere else as a source.

84.140.35.194 (talk) 07:03, 8 March 2019 (UTC)

Formatting and decimals fixed. 84.140.35.194 (talk) 14:02, 8 March 2019 (UTC)

Uses?

Can someone start a section giving the uses of this number? 81.129.181.145 (talk) 14:16, 2 June 2013 (UTC)

Error in log scale graph?

I think that there is an error in the log scale graph of the continued fraction coefficients. The term at position 41 has 2504 decimal digits , so I think that the point for position 41 should be near 10²⁵⁰⁴ instead of 10²⁵⁴.

If this is the case, then I am not sure what approach should be used to rectify the situation. I assume that the original author of the graphs intended to use the log scale graph to include all of the points that are off scale on the linear graph. Going to 10²⁵⁰⁴ would greatly compress the scale of the log graph, but keeping the scale as it is would mean that the point at position 41 is off scale.

Am I correct, and if so, does anyone have any ideas on the best remedy? Aginourmidst (talk) 04:02, 23 August 2013 (UTC)

Alternative expression in base 10?

While solving a Project Euler problem, I came up with an alternative expression for the Champernowne constant in base 10, which I think is a little easier to read than the one given. I think it can also be easily generalized to other bases. Here's the expression:

$C_{10}=\sum _{m=1}^{\infty }{\frac {m}{10^{f(m)}}}$ where $f(m)=m(1+n)-{\frac {10^{n+1}}{9}}+{\frac {10}{9}}+n$; here $n+1$ is defined to be the number of digits in $m$.

Is this formula (which is quite easy to derive, and therefore probably already well-known to mathematicians) worth including in the article? An advantage of this formula is that it enables one to efficiently find the $n$th decimal digit in the constant without directly finding the preceding digits.

--Tanmay Mudholkar (talk) 21:54, 11 August 2016 (UTC)

Infinite sum

Could I add that $C_{m}=\sum _{n=1}^{\infty }{\frac {n}{10_{m}^{~\left(\sum \limits _{k=1}^{n}\left\lceil \log _{10_{m}}(k+1)\right\rceil \right)}}}$ ?

- Bexandre2002 (talk) 13:15, 6 July 2017 (UTC)