On Sun, Apr 25, 2010 at 9:08 PM, Richard O'Keefe
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.