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

On Wednesday 21 September 2011, 04:18:38, Casey McCann wrote:

On Tue, Sep 20, 2011 at 8:20 PM, Daniel Fischer

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)