3.14

9 Responses to 3.14

1. Andrew says:

   14 March 2011 at 11:31 pm

   That’s an interesting place to stop, as printing 707 digits gives “…20200″, but printing 708 digits gives “…201996″. It’s a rare (well, one in a hundred, I suppose) occurrence that three digits depend on your choice of rounding.
2. John Cowan says:

   15 March 2011 at 2:47 am

   3. 1415926535 8979323846 2643383279 5028841971 6939937510 5820974944 5923078164 0628620899 8628034825 3421170679 8214808651 3282306647 0938446095 5058223172 5359408128 4811174502 8410270193 8521105559 6446229489 5493038196 4428810975 6659334461 2847564823 3786783165 2712019091 4564856692 3460348610 4543266482 1339360726 0249141273 7245870066 0631558817 4881520920 9628292540 9171536436 7892590360 0113305305 4882046652 1384146951 9415116094 3305727036 5759591953 0921861173 8193261179 3105118548 0744623799 6274956735 1885752724 8912279381 8301194912 9833673362 4406566430 8602139494 6395224737 1907021798 6094370277 0539217176 2931767523 8467481846 7669405132 0005681271 4526356082 7785771342 7577896091 7363717872 1468440901 2249534301 4654958537 1050792279 6892589235 4201995611 2129021960 8640344181 5981362977 4771309960 5187072113 4999999… and so on!
3. Derek Jones says:

   15 March 2011 at 6:44 am

   I would have expected a lot more occurrences of pi related values. Did your search allow for 1 (one) being scanned as l (ell), 0 (zero) as o or O (ohh)? I found that this made a big difference when matching hexadecimal literals
4. brian says:

   15 March 2011 at 10:15 am

   @Derek Jones

   Trying to measure the impact of OCR errors in the Google Books data set is very much on my mind. But getting reliable answers is not easy. You might think we could just compare the frequency of 3.1416 with all the plausible variants: 3.l416, 3.i416, 3.i4l6, 3.!4ib, &.iAlh, and so on. There are at least two problems with this approach. The first is that entropy works against us: There’s only one correct reading, but there are exponentially many possible errors. Thus even if the total number of erroneous readings is large, any one variant is likely to be rare and therefore unlikely to reach the 40-count threshold for inclusion in the data set.

   In this particular case, the situation is even worse. The OCR algorithm reads a string of decimal digits with a single noninitial period as a number, but in any other context a period is taken to be a word separator. Thus “3.1416″ –> “3.1416″ but “3.14i6″ –> “3″ “.” “14i6″.

   With integers we have a better chance of learning something. I have not done any sort of comprehensive study, but here’s a single example, plucked more or less at random—the number of occurrences for a few likely misreadings of “1997″

   "i997"    10835
   "I997"    19602
   "l997"   171548
   "L997"      114
   

   That’s more than 200,000 errors (assuming they are all in fact OCR failures, which is probably not far from the truth). This sounds horrendous. On the other hand, “1997″ itself occurs 19,761,552 times, so we’re looking at errors at the 1 percent level. Is that something to worry about? I just don’t know for sure. It probably depends on what you want to do with the data.

   Thanks very much for that pointer to your posting on hex strings in the Google Books data. We must try roman numerals!
5. unekdoud says:

   15 March 2011 at 12:49 pm

   How about fractional approximations: 22/7, 335/113 and possibly 314/100? In particular, I expected 22/7 to show up on the graph, but it seems indistinguishable from the rest of the distribution.

   Another curiosity on the graph: numbers rounded to 1 decimal place are 10-20 times as common as those rounded to 2 decimal places (the pattern of the terminal digits shows that terminal zeros are dropped), but these are about 40 times as common as numbers rounded to 3 decimal places. Perhaps section numbers are distorting the results.
6. Jim Ward says:

   18 March 2011 at 3:07 pm

   To verify the 707 digits are correct, you should also publish a checksum. That way when I do the calculation, I can compare. I’ve seen several pi approximations, what are the correct float, double, and long double values? The int one is 3.
7. Derek Jones says:

   19 March 2011 at 4:31 pm

   Brian,

   Characters such as & and ! are each treated as a single entity so the number of possible combinations is not that great.

   What made you pick on the 40 per book threshold, it sounds a bit high? I suspect 3.14 is more likely to refer to a section number than a poor representation of pi and perhaps have a handful of occurrences.

   I have found a worryingly wide number of different representation of pi in source code.

   Roman numerals would be interesting; I would expect the usage to decrease over time. Another possibility is to search for incorrect values, such as the 3.1459265 I found in Mifit’s core/Helix.cpp
8. Frank Meulenaar says:

   20 March 2011 at 3:37 am

   So, which book contained the best approximation of pi?
9. Erwin Engert says:

   26 July 2012 at 9:34 pm

   When talking about the number of digits after the decimal point so the “3.” does not get counted. The 706 digits which ended with “200” should have been left at “1995” without rounding up.

   So, which book contained the best approximation of pi? The key board here is book no web location. I have heard of a book with 2,000,000 digits of pi. It was known as the most boring book in the world. I have printed the first 1,000,000 digits of pi for the fun of it.

   If you want to find out more about the number William Shanks produced with the error that stood for 72 years, Google “William Shanks 707 digits” for my file. William Shanks calculated 709 and rounded down to 707 digits

   Erwin