Slashdot Mirror

← Back to Stories (view on slashdot.org)

Floating Point Programming, Today?

Posted by Cliff on from the learning-new-techniques dept.

An anonymous reader asks: "I'm rather new with programming and stumbled across these twe articles: The Perils of Floating Point from 1996 and What Every Computer Scientist Should Know About Floating-Point Arithmetic from 1991. I tried some of the examples in these articles with Intel's Fortran Compiler and g77 and noted that some of those issue reported no longer seem valid whereas quite a few still very much are around. Could someone, please, give me a pointer to some newer thoughts and/or new facts surrounding floating point programming. What has been improved since those articles were written? What is still the same? How is the future, especially with the new platforms IA64 and AMD64? I am most interested in the x86 and x86-64 architectures. Thank you for your kind help."

7 of 111 comments (clear)

  1. The articles are quite up-to-date by Mik!tAAt · · Score: 5, Informative

    Both articles are still valid today, mostly because current processors use the same IEEE floating point format than the ones available in 96 (or 91).

    --
    This is the place where you write something that will make you seem like a complete idiot.
  2. Unsolvable problem by Anonymous Coward · · Score: 5, Informative

    Floating point stuff hasn't really changed much since then. Basic rule of thumb, if you want it to be accurate don't use floating point.

    Much the same problem as you have with decimals. Many fractions cannot be evaluated evenly in certain bases. It will always cause you headaches if you don't realize this.

    Try writing a bunch of numbers in hex but then do all of your calculations in decimal. you'll have the same problem.

    1. Re:Unsolvable problem by john_many_jars · · Score: 4, Informative

      The use of floating point numbers isn't all bad. Those of use who use them are often solving problems with condition numbers that render the answer we get less accurate than the number of digits of accuracy provided.

      Think about tan(89.99) versus tan(89.991) (which is very ill-conditioned around 90). Both numbers are not terribly truncated by floating point, but the results are different by about 1,000. Try it and you'll see floating point error isn't as dangerous as things like cancellation, ill-conditioning and the like.

  3. Platform and all by Stary · · Score: 5, Informative

    It all depends on what platform you program on and so on. Newer x86 processors do their floating point in an 80-bit format and only truncate when copying back to your original 32 or 64 bit floats. That saves you some precision but not that much. As others have said, there are probably situations where almost all of the material in those articles is valid.

    --
    Tomorrow will be cancelled due to lack of interest
  4. Common mistake by PD · · Score: 5, Informative

    Don't count money as floating point. You'll just have rounding errors. Using long doubles instead of floats won't help you at all.

    The solution is to count pennies instead, or if you need values bigger than 22 million dollars, use a BCD library. BCD is Binary Coded Decimal.

    --
    If tits were wings it'd be flying around.
  5. Here's an important one. by Apuleius · · Score: 4, Informative

    Using accurate arithmetics to improve numerical reproducibility and stability in parallel applications, also available here if you're one of the unwashed masses. It has algorithms to see if your app is facing floating point trouble.

  6. If you need more precision... by cfallin · · Score: 4, Informative

    Hardware floating point is only so accurate - if you need more floating point (or integer) precision, use GNU MP - a library for C with bindings for many other languages too. It came in quite handy when I wrote some cryptography code with very large numbers.