Talk:Champernowne constant

From Wikipedia, the free encyclopedia

[edit] 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)

[edit] 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)

[edit] 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)