Tue Mar 11 19:53:42 EDT 2008

I'm not sure whether this is the right branch of the thread for this post.
Maybe it belongs to a different thread altogether.
But here goes:

Maybe most of our gripes with floating point arithmetic (besides broken
implementations) is that we expect it to behave like Real arithmetic, and
when it doesn't, we whine that it's unreliable, ill-defined, etc etc etc.

If we consider FP as a mathematical entity of its own (e.g as defined in
IEEE 754), we see that it has a well-defined, reliable behaviour which
happens to emulate the behaviour of the real numbers within some margins.
The accuracy of this emulation can be analyzed in a rigorous manner, see
http://www.validlab.com/goldberg/paper.pdf

So if floating point (==) doesn't correspond with numeric equality, it's not
FP's fault, but ours for expecting it to do! By the way, IEEE754 does define
another comparison operator which corresponds to our notion of 'equality'.
FP (==) is just a partial equivalence relation which makes more sense than
mathematical equality in an FP context. Of course, if an implementation
doesn't guarantee that 'x == x' yields true whenever x is not a NaN, then
the implementation is broken.

An earlier post said that "Haskell is not math" (or something like it). I
beg to differ -- one of its selling points, after all, is supposed to be the
ability to perform equational reasoning. We work hard to give well-defined
semantics to our expressions. We rely on types to tell us which properties
to expect of which values, and which manipulations are valid.

But then Haskell goes and fools us (just like most other languages do) into
thinking FP arithmetic is something that it's not: the behaviour of
operations depends on an unseen environment (e.g. rounding mode), the order
of evaluation matters, evaluation can fail... not at all what we'd call
purely functional!

So if FP arithmetic is not purely functional, what do we do? If we could do
Haskell all over again, I'd propose a different approach to FP arithmetic
(and for stuff like Int, for that matter), which I'm actually surprised not
to see discussed more often since it's after all the usual Haskell approach
to things which are not purely functional. The original topic of this thread
should already have hinted at it. ;)

-----
Ariel J. Birnbaum
--