On Wednesday 21 September 2011, 04:18:38, Casey McCann wrote: > On Tue, Sep 20, 2011 at 8:20 PM, Daniel Fischer > > <daniel.is.fisc...@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) _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe