views:

176

answers:

7

What are some good do-s and don't-s for floating point arithmetic (IEEE754 in case there's confusion) to ensure good numerical stability and high accuracy in your results?

I know a few like don't subtract quantities of similar magnitude, but I'm curious what other good rules are out there.

+1  A: 

never try to do an equals compare

double da,db;

...

if (da==db) then something.

remember that C uses double by default so if you want to do single precision, be clear about it

float fa,fb;

...

fa = fb + 1.0;

will convert fb to double do a double add then convert to single and do a single equal

Instead

fa = fb + 1.0F.

all single.

If you are going to use a whole number like 1.0 dont make it a decimal in your code. you get more reliability out of your compilers/tools if you can minimize the ascii numbers. so

fa = fb + 1;

or instead of

fa = fb + 0.3333333F;

do something like this (if interested in accuracy).

fc = 1; fc = fc / 3; fa = fb + fc;

Lots and lots of others, floating point is painful, compilers and libs are not that good, fpus have bugs, and IEEE is exceptionally painful and leads to more bugs. Unfortunately that is the world we live in on most platforms.

dwelch
+7  A: 

First, enter with the notion that floating point numbers do NOT necessarily follow the same rules as real numbers... once you have accepted this, you will understand most of the pitfalls.

Here's some rules/tips that I've always followed:

  • NEVER compare a floating point number to zero or anything else for that matter (IE don't do: if (myFloat == 0)
  • Associative property does not hold for floating point... meaning (a + b) + c != a + (b + c)
  • Remember that there is always rounding
  • Floating point numbers do not necessarily have a unique inverse
  • No closure with floating point numbers... never assume that the result of a floating point operation results in a valid floating point number.
  • Distributive property does not hold
  • Try to avoid using floating point comparisons at all... as round off error can cause unexpected results
Polaris878
"never assume that the result of a floating point operation results in a valid floating point number." It will always be another floating-point number, unless you mean NAN or infinity?
Rick Regan
Right sorry I should clarify... A floating point operation might not result in a real number :)
Polaris878
+3  A: 

The #1 "don't" rule with floating-point numbers is:

Don't use floating-point numbers where integers will suffice.

bta
A: 

Search for, download and read "what every computer scientist should know about floating point arithmetic"

dmuir
-1 for not linking it or being helpful
Malfist
phweem: http://docs.sun.com/source/806-3568/ncg_goldberg.html ?
Vuntic
Yes, but I wasn't sure if there was an "official" one somewhere.
dmuir
+4  A: 

DO understand how floating point behave.

DON'T believe that simple rules will be enough to use them correctly.

For instance, at least two answers proposed that comparing floating point for equality should be prohibited. First there are cases where comparing them for equality is what is needed. Then when doing range check is what is needed, you also need to be aware that it has its pitfall, for example it isn't transitive which is a property most people will assume for equality test.

AProgrammer
+1. There are far too many dogmatic 'never compare floats for equality' answers around.
Mark Dickinson
+1  A: 

DO remember that because of faulty floating point arithmetic people died and billion dollars of damages occured.

Ozan
A: 

My "main weapon" for avoiding floating-point pitfalls is to have a firm grasp on the way they work. I think Chris Hecker explains the basics pretty well.

S.C. Madsen