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