[Haskell-cafe] haskell gsoc proposal for richer numerical type classes and supporting algorithms

[Casey McCann]

On Thu, Apr 8, 2010 at 8:51 PM, Gregory Crosswhite
<gcross at phys.washington.edu> wrote:
> First of all, it isn't clear to me that NaN /= NaN, since in ghci the expression "1.0/0.0 == 1.0/0.0" evaluates to True.  But even if that were the case, I would call that more of a technicality then meaning that equality is not reflexive for floats, since NaN is roughly the floating-point equivalent of _|_, and using the same argument one could also say that reflexivity does not hold in general for equating values of *any* Haskell type since (_|_ == _|_) does not return true but rather _|_.

The difference there is that _|_ generally means the entire program
has shuffled off this mortal coil, whilst a (non-signalling) NaN is,
by specification, silently and automatically propagated, turning
everything it touches into more NaNs. The very sensible purpose of
this is to allow computations on floats to be written in a
straightforward manner without worrying about intermediate errors,
rather than having NaN checks everywhere, or having to worry about
exceptions all the time. In that regard, it's more analogous to all
floating point operations occurring in an implicit Maybe monad, except
with Nothing treated as False by conditionals. "(==) <$> Nothing <*>
Nothing" indeed does not evaluate to "Just True", so in a sense
equality is also not reflexive for types such as "Maybe Integer".

Although I like to make fun of floats as being sorry excuses for
numbers, the way they work is actually quite sensible from the
perspective of doing low-level computations with fractional numbers.
Now, if only certain... other... programming languages were as
well-designed, and could silently and safely propagate values like
"Not a Reference" or "Not a Pointer".

- C.