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

[Daniel Fischer]

On Wednesday 21 September 2011, 04:18:38, Casey McCann wrote:
> 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,

Yes. Which can be inconvenient if you are interested in whether you got a 
-0.0, so if that's the case, you can't simply use (== -0.0).
Okay, problematic is a too strong word, but it's another case that may 
require special treatment.

> which is correct and shouldn't break any expected behavior.
> I don't think it's required that distinguishable values be unequal,

But desirable, IMO.

> 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,

It wouldn't do that, as far as I'm aware.

> 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. :]

True.

> > 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.

Agreed.

> 
> I still don't see why it makes sense to add separate IEEE comparisons

Pure and simple: speed.
That is what the machine instructions, and hence the primops, deliver.

> 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.

Seems reasonable.

> If different NaNs are unequal, that may change matters.

Yeah, if there are a lot of them, it might be better to put them at the end 
[that is, make them larger than any non-NaN].

> 
> > 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...

Umm, 'more correct' only in some sense. Definitely unsatisfactory.

do x <- someList
   y <- someComputation
   guard (not $ isNaN y)
   z <- someOtherComputation
   return (if z < 3 then foo z else bar z)