Proposal: New Eq and Ord instances for Double and Float

[Roman Leshchinskiy]

Daniel Fischer wrote:
> Proposal: Provide Double and Float with Eq and Ord instances that
> introduce a total order.

I'm strongly against this, for the reasons that have already been
mentioned.   and because there a good reasons for why the IEEE semantics
is the way it is. Also, performance is going to suffer horribly.

> As a result, various algorithms and data structures are broken in the
> presence of NaNs:
>
> Prelude Data.List Data.Set> let nan :: Double; nan = 0/0
> Prelude Data.List Data.Set> max nan 1
> NaN
> Prelude Data.List Data.Set> max 1 nan
> 1.0
> Prelude Data.List Data.Set> minimum [0,1,nan,2,nan,3,4,nan,5,6]
> 5.0
> Prelude Data.List Data.Set> sort [0,1,nan,2,nan,3,4,nan,5,6]
> [0.0,1.0,3.0,5.0,6.0,NaN,4.0,NaN,2.0,NaN]
> Prelude Data.List Data.Set> let st = fromList [0,1,nan,2,nan,3,4,nan,5,6]
> Prelude Data.List Data.Set> Prelude.filter (`member` st) [0 .. 10]
> [0.0,1.0,2.0,5.0,6.0]
> Prelude Data.List Data.Set> Prelude.filter (`member` (Data.Set.filter (not
> . isNaN) st)) [0 .. 10]
> [0.0,1.0,2.0,3.0,4.0,5.0,6.0]
> =====================

I would say it's a precondition of min, max and friends that none of the
numbers involved are NaNs. In fact, one could argue that the Eq and Ord
instances have the same precondition and hence define a total order, but
can only handle a subset of the Double/Float values.

IMO, anybody who stores Doubles in a Set either really knows what he's
doing (in which case NaNs shouldn't be a problem) or is just doing it
wrong.

In general, these examples just look broken to me regardless of how Eq and
Ord are defined. If I saw something like this happen in real code I'd
assume it's a bug.

Roman