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

[Daniel Fischer]

On Wednesday 21 September 2011, 01:23:48, Casey McCann wrote:
> On Tue, Sep 20, 2011 at 6:58 PM, Daniel Fischer
> 
> <daniel.is.fischer at googlemail.com> wrote:
> > On Wednesday 21 September 2011, 00:20:09, Casey McCann wrote:
> >> Because
> >> NaN values never compare equal to themselves, I'm not sure if it's
> >> even possible to remove them from the structure,
> > 
> > filter (not . isNaN)
> > 
> > resp.
> > 
> > filterWithKey (\k _ -> not $ isNaN k)
> 
> Er, right. Yes, of course. I'm not sure what I was thinking there. :]
> Though that still leaves the question of any damage done in the
> meantime, unless the filtering would repair the tree in the process.

With fromList . Prelude.filter (not . isNaN) . toList and the corresponding 
for Maps, you'll get a valid NaN-less tree.
However, damage done in the meantime generally couldn't be undone.

> 
> >> and because of tree
> >> rebalancing I'm not sure how to predict what the impact of one or
> >> more NaNs would be over multiple operations on the data structure.
> > 
> > Yuck. Don't even try to predict that (unless you absolutely have to).
> 
> Agreed. The consequence of not trying, however, is that it isn't
> viable to let things slide at all--every insertion must be checked for
> NaNs, because otherwise you lose any guarantee that the tree will be
> valid next time you use it.

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.

> 
> One can imagine a similar data structure designed to be resilient and
> predictable in the face of ill-behaved comparisons, but surely it
> would be easier to just fix the problem instances!

Except that people might expect IEEE semantics for (==), (<) etc.
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].

> 
> >> If you'd like to see an explicit demonstration (which you can try in
> >> GHCi yourself!) see here:
> >> http://stackoverflow.com/questions/6399648/what-happens-to-you-if-you
> >> -br eak-the-monad-laws/6399798#6399798 where I use it as an example
> >> of why it's important for type class instances to obey the relevant
> >> laws.
> > 
> > Nice and short.
> 
> Yes, and credit where due for the original example. :] Don't recall
> which -cafe thread that came from, though.

Google suggests "Exception for NaN" from May.