Stories
Slash Boxes
Comments

SoylentNews is people

posted by Fnord666 on Wednesday August 14 2019, @11:59PM   Printer-friendly
from the that's-the-combination-to-my-luggage! dept.

https://www.jpl.nasa.gov/edu/news/2016/3/16/how-many-decimals-of-pi-do-we-really-need/

Earlier this week, we received this question from a fan on Facebook who wondered how many decimals of the mathematical constant pi (π) NASA-JPL scientists and engineers use when making calculations:

Does JPL only use 3.14 for its pi calculations? Or do you use more decimals like say: 3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628034825342117067982148086513282306647093844609550582231725359408128481117450284102701938521105559644622948954930381964428810975665933446128475648233786783165271201909145648566923460348610454326648213393607260249141273724587006606315588174881520920962829254091715364367892590360

We posed this question to the director and chief engineer for NASA's Dawn mission, Marc Rayman. Here's what he said:


Original Submission

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 5, Informative) by Immerman on Thursday August 15 2019, @02:12PM (20 children)

    by Immerman (3985) on Thursday August 15 2019, @02:12PM (#880582)

    A bunch of posts in the time it took me to calculate and type this, so here it is at the top:

    What I learned in college science and engineering classes is, just keep the number of significant digits the same.

    Your margin of error is determined by the number of significant digits in the least-precise piece of starting data, and it's pointless to include significantly more precise numbers elsewhere, whether it's pi, the speed of light, or any other constant.

    Example: I measure a circle as being 23.1cm across then the last digit is an estimate - if it's accurate that means the actual diameter is somewhere between 23.05cm and 23.15cm. In practice you'll typically estimate one more digit than your measuring tool offers gradations for, and the margin of error will be even larger (e.g. you made that measurement with a meter stick that doesn't have mm marks, and you just eyeballed it as being 10% of the way to the next cm mark).

    Then I calculate the circumference using many digits of pi as 72.5708cm
    But, given my margin of error, I know the actual circumference is somewhere between 72.414cm and 72.728cm

    My results should definitely not include more significant digits than my data - if I list a result of 72.571cm, and that's all you see, then you're going to assume that the .57 is accurate, and the .001 is estimated. But looking at the results calculated at the margins of error, we can see that even the .5 is an estimate.

    So what happens if we just used the same number of significant digits in pi as in the data? 23.1*3.14 = 72.5 - we arrive at the same result, and it's clear that the .5 is the estimated digit.

    Also, typically you don't want constants in your real world results. If I tell you to cut a beam 7pi cm long I'm just requiring you to do a calculation that invites mistakes. If you're working in math, where everything is theoretical and your numbers exact, that's different. But in science and engineering all your numbers are estimates, and you're going to do something definite with the results, so you want precise numerical results, but only slightly more precise than your actual margin of error.

    Starting Score:    1  point
    Moderation   +3  
       Informative=3, Total=3
    Extra 'Informative' Modifier   0  
    Karma-Bonus Modifier   +1  

    Total Score:   5  
  • (Score: 3, Insightful) by Runaway1956 on Thursday August 15 2019, @02:29PM (14 children)

    by Runaway1956 (2926) Subscriber Badge on Thursday August 15 2019, @02:29PM (#880592) Journal

    Yes, that exactly. In real life, you're building, or whatever, two or three digits after the decimal is all you're ever going to need. Real life, mind you. If you're measuring in inches, you're not going to use more than two decimals anyway. If you're measuring in feet, ditto, even if you're using an engineer's scale. Using more digits for Pi than you are using in your measuring scale is merely an attempt to prove how smart you is - and it's always a fail. The tooling shop only measures to thousandths of an inch, and when they calculate something, they use three decimals of Pi. Only in academia and rocket surgery are ten or more digits going to matter.

    • (Score: 2) by JNCF on Thursday August 15 2019, @02:43PM (11 children)

      by JNCF (4317) on Thursday August 15 2019, @02:43PM (#880596) Journal

      If you're measuring in inches, you're not going to use more than two decimals anyway.

      Standard rulers and measuring tapes have 1/8th inch marks, which are 0.125 inches in decimal. I have totally used more than two decimals when using inches for carpentry, plumbing, typesetting, and all sorts of other things.

      • (Score: 2) by Immerman on Thursday August 15 2019, @03:26PM (8 children)

        by Immerman (3985) on Thursday August 15 2019, @03:26PM (#880621)

        Yeah, that's one of the big problems with combining a fractional scale and decimal calculations - they really don't mesh well. You absolutely didn't measure anything to thousands of an inch accuracy, but you have to put that much accuracy in your calculation just to avoid losing data in the "unit conversion"

        Similar problem in computers actually - floating point numbers are fractional (binary) rather than decimal, and the conversion can't be done gracefully. One of the big reasons financial calculations are typically done in cents rather than dollars - $0.01 is an infinite repeating decimal in binary, and thus can't possibly be represented correctly. (Alternatively they may use binary coded decimals, but I don't think any modern CPU supports native BCD calculations, and a software implementation is terribly inefficient.)

        • (Score: 2) by Zinho on Thursday August 15 2019, @04:22PM (5 children)

          by Zinho (759) on Thursday August 15 2019, @04:22PM (#880636)

          (Alternatively they may use binary coded decimals, but I don't think any modern CPU supports native BCD calculations, and a software implementation is terribly inefficient.)

          The typical solution for this is to store the value as pennies [1] and represent it with an integer. Modern computers do integer calculations just fine. It's trivial to display the result in dollars with a decimal point in the right place. I think this trick has been used since the COBOL days, and what isn't broke doesn't get fixed.

          [1] if you're doing accounting for a gas station where the values stored look like $5.4321 the same trick still works, you just keep track of how many places to shift the decimal from your smallest value when displaying.

          --
          "Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
          • (Score: 0) by Anonymous Coward on Thursday August 15 2019, @09:53PM (2 children)

            by Anonymous Coward on Thursday August 15 2019, @09:53PM (#880742)

            You guys are both a bit off.
            For financial calculations, you use a language that supports decimal arithmetic.
            COBOL is one such language, and Java is another. (Java can do integer, floating point, and decimal arithmetic.)
            It wouldn't surprise me if LISP could do it too.
            Doing arithmetic in "pennies" is only accurate for sums and differences. In short, here's a nickel, kid: buy a real language!

            • (Score: 2) by Immerman on Friday August 16 2019, @01:56AM (1 child)

              by Immerman (3985) on Friday August 16 2019, @01:56AM (#880821)

              The language doesn't matter - the problem is that the CPU itself can't do decimal arithmetic. Full stop. (aside from BCD on some uncommon processors). If the language looks like it's doing decimal arithmetic, then it's playing inefficient software-based tricks behind the scenes. In the case of Java's BigDecimal, *dangerous* software tricks that can easily cause numerous problems that can truncate your results from either end (loss of most- or least- significant digit information) if used carelessly without fully understanding its weaknesses. I assume COBOL is more robust given its business pedigree, but don't know it well enough to comment.

              • (Score: 0) by Anonymous Coward on Friday August 16 2019, @05:39PM

                by Anonymous Coward on Friday August 16 2019, @05:39PM (#881194)

                What are you going on about?
                Java BigDecimal is a very well though out system.
                The fact that the arithmetic is done "in software" versus "in the CPU" is of no consequence.
                There is nothing about "in the CPU" that makes a system of arithmetic foolproof.
                There are things you have to be aware of with IEEE floating point arithmetic as well so that you don't accidentally end up with bad accuracy in your results.

          • (Score: 2) by Immerman on Friday August 16 2019, @02:35AM (1 child)

            by Immerman (3985) on Friday August 16 2019, @02:35AM (#880843)

            As I said. It does have some serious weaknesses if you might care about fractions of a penny in some situations though.

            There is also the possibility of something resembling decimal floating-point numbers - aka integer + decimal exponent (e.g. ddddddd*10^x rather than the normal IEEE-754 binary floating-point format of 1.bbbbbbb*2^x) I don't know of any languages do that, but I'll freely admit that it's not a topic I'm well versed in. I assume there are at least as many caveats and gotchas to such a format as there are for binary floating points, and massively fewer people who care enough to sort them out.

            • (Score: 0) by Anonymous Coward on Friday August 16 2019, @05:42PM

              by Anonymous Coward on Friday August 16 2019, @05:42PM (#881196)

              If you read AC comments, you would have seen a discussion of decimal arithmetic supported in COBOL and Java.
              Stay uninformed -- your choice.

        • (Score: 2) by sjames on Thursday August 15 2019, @08:56PM (1 child)

          by sjames (2882) on Thursday August 15 2019, @08:56PM (#880729) Journal

          Interestingly, computer based floating point meshes much better with the way common measures do fractional units. 1/8 is quite easy to represent in binary. If a calculator (or program) had a good way to input 8ths, it could be precisely represented in a way that wouldn't screw with significant digits.

          As several others have pointed out, in cases where the needed precision is known in advance, integer values are simply scaled, but that doesn't overcome the fact that 1/8 (or worse, 1/3) wouldn't be handled very neatly.

          Of course, non power of 2 fractions would still be an issue. Another option is to store and perform computations based on ratios.

          • (Score: 2) by Immerman on Friday August 16 2019, @02:06AM

            by Immerman (3985) on Friday August 16 2019, @02:06AM (#880827)

            Common measures? You mean the uncommon non-SI units used only by the 3rd, 26th, and 124th largest nations in the world? (okay, and several others in common parlance, but rarely for real work)

            But yes, ironically enough binary is better suited to power-of-two fractional measures than decimal ones. Ironically, because typically there's no way to input or read those values except as gratuitously long decimal values. I've used a few pieces of software that will actually accept a value like 3+7/8 in a numerical field, but they're so few and far between as to be really noteworthy.

      • (Score: 2) by Zinho on Thursday August 15 2019, @04:07PM

        by Zinho (759) on Thursday August 15 2019, @04:07PM (#880627)

        Unless you are using a decimal-marked inch scale (like the 1:10 side of an engineer's scale [wikipedia.org]) then you'll have a mismatch between the implied precision of the measurement you took and the exact decimal representation of that measurement.

        When you're using your tape measure and read to the 7/32 mark, your measurement's precision is +/- 1/64. The decimal representation of 7/32 (0.21875) appears to have a precision of +/- 0.00005 inch; in reality it's more like +/- 0.01 inch or +/- 0.02 inch (truncating or rounding 0.015625). This is the exact problem we have with decimal-to-binary number conversion, and there's not a practical solution.

        If you're keeping track of all 6 decimal places worth of those 1/64 inch measurements to avoid losing accuracy due to rounding after number conversion, feel free. Especially if you're getting high-quality results, don't think I'm trying to stop you. If, at the end of your calculations, you're shifting the result into a CNC machine for the final cut it's important for your mental health to realize that truncating or rounding at the 1/1000 inch place is all the precision you've gained for your effort, and the machine won't benefit from any extra digits.

        --
        "Space Exploration is not endless circles in low earth orbit." -Buzz Aldrin
      • (Score: 2) by janrinok on Thursday August 15 2019, @06:36PM

        by janrinok (52) Subscriber Badge on Thursday August 15 2019, @06:36PM (#880692) Journal

        The rulers we had in schools in the 1960s-1990s had 1/10th inch marks too. A 12" ruler had 6" of 1/8th graduations and 6" of 1/10th graduations. The other side was centimeters and millimeters.

    • (Score: 0) by Anonymous Coward on Thursday August 15 2019, @04:20PM

      by Anonymous Coward on Thursday August 15 2019, @04:20PM (#880634)

      Exactly - that's why I always trim off the USELESS extra digits to get a nice speed bump.

      double pi = round(M_PI*100)/100;

    • (Score: 0) by Anonymous Coward on Thursday August 15 2019, @05:20PM

      by Anonymous Coward on Thursday August 15 2019, @05:20PM (#880652)

      Yet another dramatic reproduction of the Dunning-Koeger Effect! Our confirmation rate must be close to 99.999, but that could be us just trying to show off how smart we is.

  • (Score: 2) by looorg on Thursday August 15 2019, @03:09PM (4 children)

    by looorg (578) on Thursday August 15 2019, @03:09PM (#880609)

    Sure it's fairly standard to just use the number of decimals in the answer as in the data given if one has to.

    That said if it's for building small things just change the scale down to mm and you don't, or shouldn't, have to bother with decimals. But sure for some hands-on buildings some sort of calculation to an actual number is helpful. That said a lot of machines used in construction and cutting can/could probably take a 7pi cm cut as a valid input these days; it's been a long time since I had to program anything for a CNC.

    • (Score: 2) by Immerman on Thursday August 15 2019, @03:17PM (3 children)

      by Immerman (3985) on Thursday August 15 2019, @03:17PM (#880616)

      Not the number of decimals - the number of significant digits.

      23.1 cm, 231mm, 0.231m 0.000231km or 231,000um all have 3 significant digits even though the number of decimals varies wildly

      Admittedly there's a little bit of assumption made with the 231,000um - we're assuming three significant digits as there's no accepted way to indicate whether any of the zeros are measured values rather than placeholders, but that doesn't actually come up in real-world situations very often.

      • (Score: 2) by Osamabobama on Thursday August 15 2019, @04:39PM (1 child)

        by Osamabobama (5842) on Thursday August 15 2019, @04:39PM (#880645)

        There's a good story [scienceabc.com] about precision of the initial measurement of Mount Everest. It was measured at exactly 29,000 feet (five significant digits), but Sir George Everest published the measurement at 29,002 to imply the actual precision, even though it was less accurate than reality.

        --
        Appended to the end of comments you post. Max: 120 chars.
        • (Score: 2) by Immerman on Friday August 16 2019, @02:45AM

          by Immerman (3985) on Friday August 16 2019, @02:45AM (#880845)

          Now you've got me wondering why he didn't use 29,001 feet instead, and half the error or the same result.

          I suppose measuring to a fraction of a foot in those days would be rough, leaving 29,000.0 as unacceptable.

          It does bear mentioning that I've seen a convention in many science and engineering books of representing such an "exact" integer with a trailing decimal point - e.g. as 29,000. - but it's far from ubiquitous. It also isn't generally flexible - it doesn't help you if your measuring method is accurate to 10 feet.

          Plus, as your link indicates, he was actually off by 29 feet, so clearly he was overestimating the precision of his measurement technology by 1.5 orders of magnitude.

      • (Score: 2) by FatPhil on Friday August 16 2019, @08:17AM

        by FatPhil (863) <pc-soylentNO@SPAMasdf.fi> on Friday August 16 2019, @08:17AM (#880949) Homepage
        Hard science will often use uncertainty indicators, the equivalent of an error bar. E.g. the Fine Structure Constant is 7.2973525693(11) * 10^-3 where the (11) means a possible uncertainty of 11 in the final digits, and therefore that the last three digits 963 might in reality range from 682 to 704. Astronomy in particular will sometimes give asymmetric uncertainty indicators, but that requires fancier typesetting.
        --
        Great minds discuss ideas; average minds discuss events; small minds discuss people; the smallest discuss themselves