[Haskell-cafe] Proper Handling of Exceptional IEEE Floating Point Numbers

Casey McCann syntaxglitch at gmail.com
Sun Apr 25 22:22:16 EDT 2010

On Sun, Apr 25, 2010 at 9:08 PM, Richard O'Keefe <ok at cs.otago.ac.nz> wrote:
> It seems to me that there's a choice here between (...)

Nice! That's a very comprehensive summary of the situation regarding
issues of correctness. I do wonder, though, what (if any) are the
performance implications?

Editorializing a bit, I would actually go so far as to say that, in
the general case, using floating point values at all is a mistake.
Programmers failing to use them properly has been a small but
consistent source of bugs, even in low-level languages where one would
expect familiarity with their behavior to be the norm. The situation
is even worse in languages that are interpreted, VM-based, or
otherwise further removed from the hardware level, where I've seen
people who thought that IEEE specified behavior was a bug in the
language runtime.

To that end, I'd make a simultaneously conservative and radical
suggestion: Regard floating point types as, first and foremost, a
performance optimization, and strongly discourage their use as
general-purpose fractional numbers. Aside from issues of backwards
compatibility and such, I'd even advocate removing floating point
types from the Prelude and instead require an explicit import from a
separate module in the standard libraries. Use of floating point
values would, ideally, be limited to calculation-heavy code which
spends a non-trivial amount of its time doing fractional arithmetic,
with an assumption that anyone writing code like that ought to
understand both IEEE floats and Haskell's handling of them well enough
to do it correctly.

Given that distinction, I'd say that the order of priorities for
floats should be 1) anything that supports writing high-performance
code 2) accuracy to IEEE standards as the expected behavior 3)
minimize the ugliness from a Haskell perspective as much as possible
without harming the first two. What that works out to, I'm not sure,
but I'd tolerate creating _|_s or breaking Ord's semantics if that's
what it takes.

Alas, I expect that's far too disruptive of existing code to be a
viable approach.

- C.

More information about the Haskell-Cafe mailing list