Personally I think one of the hardest things to wrap your head around is how it's power-of-two fractions that can be represented exactly, not power-of-10 fractions. In other words, 0.5 can be represented exactly as IEEE floating point, but 0.1 cannot.<p>This is not inherent to floating point; a floating point representation that was based on decimal digits instead of binary ones would not have this issue.<p>It's not too hard to understand limited precision and rounding; we deal with both all the time. The part that's hard to understand is that you have to perform rounding simply to put a number like "0.1" into a floating-point value.<p>Specifically, in 0.1 as an IEEE float is represented as:<p><pre><code> val = 0x3dcccccd
sign = 0
significand = 4ccccd (1.6000000)
exponent = 0x7b (-4)
</code></pre>
So 0.1 is internally represented as 1.6000000 * 2^-4, while 0.5 has the much more understandable representation 1 * 2^-1.<p>This is made even more confusing by the fact that rounding performed on output will make it <i>appear</i> that 0.1 has been exactly represented in many cases.<p>So take a data type that can't exactly represent some numbers that look very simple in decimal, but that appears to represent them exactly when you print them out, but then compares not equal when you try to actually compare them. No wonder people get confused!
The D programming language takes the (so far as I know) unique approach that the implementation is allowed to evaluate expressions in the highest precision it wants to - the different floating point data types only represent storage formats.<p>The idea is that algorithms should be designed with a minimum required precision, but no maximum, and should not fail if higher precision is used.<p>I think this rule serves very well.
This article seems to appear every so often on HN and Reddit. It used to be at sun.com. I'm glad Oracle didn't 404 it.<p>The title isn't accurate though. The article is mostly about using IEEE 754 to manage computational error, which is a pretty esoteric subject.<p>Most programmers spend precious little time using floating point and don't need to worry about computational error. Even among those who use it a great deal -- those doing numerical analysis -- computational error doesn't seem to be something they concern themselves with. My guess is that in most instances it's swamped by experimental error.<p>My thoughts on this article are:<p>1: It's certainly good that it's available online. It'd be better with a different title.<p>2: It's good that modern CPUs support IEEE 754 for the rare instance that people use it.<p>3: It's worth reading the first third or so of it, just to get an idea of what computational error is<p>4: The most important thing the "typical" programmer needs to know is that dollar values shouldn't be represented in floating point. Ideally they shouldn't be represented as integers either because the integer rounding truncates towards zero, which is not how an accountant would round.
I think the latex typeset pdf is much nicer to read.<p><a href="http://docs.oracle.com/cd/E19957-01/800-7895/800-7895.pdf" rel="nofollow">http://docs.oracle.com/cd/E19957-01/800-7895/800-7895.pdf</a>
The big thing I remember from my Numerical Computing course in college was floating point arithmetic is not commutative. Totally. Rocked. My world. You have to work hard to retain your significant digits throughout the computation.
After spending a week ripping out someone's poorly thought out floating point code, the lesson I learned is that you just shouldn't use floating point unless you really need to.<p>For example, if you're working with money, you don't need floating point.
What Every Web Programmer Should Know About Floating Point:<p>0. Do not calculate monetary amounts in FP. Businesses don't react well to being told about acceptable imprecision.<p>1. Javascript is floating point.<p>2. Do not calculate money amounts in Javascript.<p>There are decimal libraries for Javascript (eg [1][2]). Use those if you need to calculate monetary amounts.<p>[1] <a href="https://github.com/whatgoodisaroad/Big-js" rel="nofollow">https://github.com/whatgoodisaroad/Big-js</a><p>[2] <a href="https://github.com/dtrebbien/BigDecimal.js" rel="nofollow">https://github.com/dtrebbien/BigDecimal.js</a>
A number of years ago the project I was working had problems in Ada because the conversion of floating point numbers from character string to internal floating point by the Ada compiler did not always produce the same values as runtime conversion. I had fun reconciling the two.
What Every Programmer Should Know About Floating-Point Arithmetic:<p><a href="http://floating-point-gui.d" rel="nofollow">http://floating-point-gui.d</a>
What every Computer Scientist should be asking about Floating-point arithmetic: Why aren't there types for fixed-point/rational arithmetic exposed by your language and/or standard library?