Can we trust floating-point numbers? (2006) [pdf]

The only thing that they make easier is parsing and displaying numbers. The number of times where you deal with things that are guaranteed to be perfectly represented by powers of ten are relatively few.

Scheme (via its numeric tower) and some other language default to exact types (decimal or in some cases rational if they don't have a separate exact decimal type) and only use approximate floating point types if explicitly requested (including using by using a function which inherently produces an approximate output.)

Haskell can be configured by way of the default specifier to do something analogous to this in its handling of ambiguous numeric types (which includes literals, which start out with a generic type of Num a => a) , though the default default uses double precision floating point for types that can't be constrained to arbitrary precision integers -- default (Integer, Double) -- so to do this you need something like default (Integer, Rational, Double.)

  #include <stdio.h>
  int main() {
      unsigned long long bits = 0x7FFC000000000000;
      double x = *(double *)&bits;
      bits += 1;
      double y = *(double *)&bits;
      double z = x + y, w = y + x;
      printf("%llx %llx\n", *(unsigned long long *)&z, *(unsigned long long *)&w);
  }

The one that surprised me was that, in some cases:

      Large + small + small + small =! small + small + small +  = Large

Really underscores how complex things are.

On the first look, it appears a dubious presentation anyway. The examples don't have much sense too: you can't actually calculate properly sin( 10e22 ) in binary floating point format because both exponent and mantissa are binary: the exponent is 2^76 and in 4-bytes floats you have 23 bits, in 8-byte doubles 53 bits, so you can't even represent the starting number with the enough bits to calculate meaningful sin. You'd need a two parameter function to be even able to pass what you actually want to pass. So calling sin( 10e22 ) in the languages with 4 or 8-bytes binary FP of course can't be expected to produce any meaningful result.

But maybe all this was spoken, not written, and it's just misleading to read it without knowing the comments.

"Who is NOT using: Excel, BLAS" could maybe then mean that author wanted to say "Excel, BLAS, they use them too"? (If we want to believe that he had any idea what he wrote about). Definitely not good to give this presentation to somebody who doesn't already know more. Confusion guaranteed.

Floats are not that much of a problem as people might think. They come as a surprise for those that don't know how they work. Small course in numerical analysis would do people good.

Switching to fixed point would not cure anything, just change the ways they can break. Floats actually have way superior error propagation properties compared to fixed point if your range varies widely, as it often does in physics. In a massively simplified way one can say that multiplication is error free in floats whereas in fixed point multiplication is horrible.

Sure, but if you aren't dealing with transcendental functions but just typical input from people and arithmetic, you don't usually introduce as many errors by rounding to a base-10 representation, so decimal floating point solves a lot of the problems (at the cost of performance if you have a system that implements it over hardware that doesn't.)

You still have the big + small problem, though.