On 27/09/2011, at 4:55 PM, Chris Smith wrote: > So there are two perspectives here. One is that we should think in > terms of exact values of the type Float, which means we'd want to > exclude it, because it's larger than the top end of the range. The > other is that we should think of approximate values of real numbers, in > which case it's best to pick the endpoint closest to the stated one, to > correct for what's obviously unintended drift due to rounding.
My perspective on this is neither of the above. My perspective is that if I say I want numbers in the range L..U, anything outside that range is wrong and could be catastrophically wrong. > So that's what this is about: do we think of Float as an approximate > real number type, or as an exact type with specific values. That may be the way you see it, but it's not the way I see it. The way I see it is that the *order* properties are more fundamental than the *arithmetic* properties, and that it is far less important to produce value which is approximately the end point (after all, [0,2..9] doesn't include 10) than it is to ensure that all the results are in the interval. And I would be *delighted* if Haskell's compare raised an exception if either argument were a NaN; that's what Real.compare does in SML. Floating point *operations* are approximate; floating point *numbers* are, according to the relevant standards (IEEE, LIA), precise. _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
