[Haskell-cafe] instance Enum Double considered not entirely great?

[Casey McCann]

On Tue, Sep 20, 2011 at 8:20 PM, Daniel Fischer
<daniel.is.fischer at googlemail.com> wrote:
> Yes, where NaNs matter, you always have to check (well, unless you *know*
> that your calculations don't produce any NaNs).
> Btw, -0.0 can be problematic too.

How so? As far as I can tell Ord and Eq treat it as equal to 0.0 in
every way, which is correct and shouldn't break any expected behavior.
I don't think it's required that distinguishable values be unequal,
and while I imagine arguments could be made both ways on whether that
would be a good idea, I don't see any way that could cause problems in
code polymorphic on instances of Eq or Ord, which is the main concern
to my mind.

> Except that people might expect IEEE semantics for (==), (<) etc.

Yes, but probably fewer people than expect Map and Set to work correctly. :]

> However, nowadays I tend to think that making the Eq and Ord instances
> well-behaved (wrt the class contract) and having separate IEEE comparisons
> would overall be preferable.
> There is still the question whether all NaNs should be considered equal or
> not [and where Ord should place NaNs].

IEEE semantics are incompatible with Ord regardless. The problem can
be fixed by changing Ord, removing the instance completely, or
changing the instance to ignore the IEEE spec. I think the latter is
the least bad option in the big picture.

I still don't see why it makes sense to add separate IEEE comparisons
instead of just adding a standard partial order class, though. Surely
posets are common enough to justify the abstraction, and it surprises
me that one isn't already included. No doubt there are at least three
or four different partial ordering classes on Hackage already.

As for where Ord should place NaN, I still suggest it be the least
element, to be consistent with the Ord instance for Maybe. If
different NaNs are unequal, that may change matters.

> Google suggests "Exception for NaN" from May.

Ah, yes, wherein someone suggested that comparing to NaN should be a
runtime error rather than give incorrect results. A strictly more
correct approach, but not one I find satisfactory...

- C.