Re: [boost] floating point FUD

Subject: Re: [boost] floating point FUD
From: Thomas Klimpel (Thomas.Klimpel_at_[hidden])
Date: 2010-01-24 08:48:03

Steve M. Robbins wrote:
> Nice examples.

Thank you. They were indeed the main point of my message, the rest was just the background story.

> I'm curious: what distinction are you drawing between "fundamental
> problems" and "usual traps that are continually overlooked"?

What will happen when I "send the source code to somebody from another group"? Parts of the code could potentially be pasted into other source files, and these source files might include "different" headers and be compiled with "different" compiler flags and compilers than the initial code was tested with. In this context, "fundamental problems" would mean that it would be impossible to fix the discovered floating point bugs in a way that would work on any reasonably standard conforming compiler. So when I say "usual traps that are continually overlooked", I mean that my floating point code has real bugs that are easy to fix once discovered. The opposite would be unfixable interactions between the code and the compiler (Corresponding FUD: write once, debug everywhere).

> And what is the moral of your story?  My reading is that you're
> essentially saying that floating point-driven logic is fine as long as
> you take care to avoid the usual traps.

I really try to avoid floating point-driven logic as far as I can. So when I'm forced to use floating point-driven logic, the problem at hand is already seriously challenging me. These are typically 2D geometrical problems, like sweepline type algorithms, or computing the overlapping area of three circles or the mentioned integration problem, which require handling of many different geometric scenarios.

What are your alternatives in such a situation? The authors of [Constrained Value] and  [Polygon] decided to avoid floating point, and got serious flak for that decision during their reviews. The authors of [GGL] took the other decision, and got the typical floating point FUD during his review. My moral from this is that you lose either way.

But as I wrote, I was offered a third alternative: "..., or commenting it in excessive detail." But how can I comment in the source code that I managed to avoid the "usual" traps?
- A first step would definitively be to document "usual" traps themselves. The first step for this is a test program that allows to trigger them. 
- A second step might be the complete opposite, i.e. a test program that shows on which floating point properties one can rely on when writing floating point-driven logic.
- A third step might be a test program showing the potential accuracy loss when a compiler does misguided optimizations, like ruining Kahan Summation Formula. But I'm not sure whether such "broken" compilers are still around, at least I guess it would be difficult for me to get my hands on such a "broken" compiler.

> But: isn't the very fact that
> most of us stumble over them continually -- and they can lie
> undiscovered for years -- reason enough to look for something better?

Good question. I think Java took that approach. But they also got flak, claiming that their overly restrictive floating point specification would be ruining performance. But on the positive side, most of the "usual" traps my test program highlighted don't exist in Java. The only one I'm not sure about is ((1-alpha)*a + alpha*b) != a for a==b.

Regards,
Thomas