Back in March, we looked at the reasons behind apparent arithmetic "mistakes" that can occur in software programs like R that use floating-point arithmetic, like this:
> 1.0 - 0.9 - 0.1
[1] -2.775558e-17
Of course, the answer should be zero, but it's not, not exactly anyway. That example (which I wish I'd thought of myself at the time) comes from an well-written and informative article published in PC Plus and available online at techradar.com. In simple, non-technical terms, it explains why such floating-point errors occur. It also gives some examples of the consequences of not anticipating such errors, like the Ariane 5 rocket that self-destructed 5 seconds after launch, or the Patriot missile that failed to target an Iraqi Scud missile that killed 28 people.
These horror stories explain why good programmers should always be aware of the pitfalls of using floating-point arithmetic and to program defensively to avoid them. (I gave some tips for R in that article from March.) It's a great article to send next time someone asks you why their code isn't giving a exactly the right result when they think it should.
TechRadar.com: Why computers suck at maths
If one wants to know everything about floating point but is afraid to ask there is the bible of computer programming in particular the Semi-numerical Algorithms section. Fundamentally the issue is that the floating point number line is not dense, i.e. there are points on the line that have no representation in the floating point space, because recall that between any two numbers on that line there is another number. Unless one had an infinitely long floating point number, the above condition can not be satisfied.
Posted by: Lyle | November 07, 2009 at 21:18
Opps forgot to add that the book cited is by Donald Knuth.
Posted by: Lyle | November 07, 2009 at 21:18
The Ariane5 did not crash due to a floating point error but due to an integer overflow. Rather different beast...
Posted by: Joris | October 22, 2011 at 15:47