droundy: > On Mon, Jun 16, 2008 at 05:08:36PM -0700, Don Stewart wrote: > > droundy: > > > On Mon, Jun 16, 2008 at 04:50:05PM -0700, John Meacham wrote: > > > > On Mon, Jun 16, 2008 at 04:41:23PM -0700, Evan Laforge wrote: > > > > > But what about that NaN->Integer conversion thing? > > > > > > > > I think that may be a bug or at least a misfeature. The standard is > > > > somewhat vauge on a lot of issues dealing with floating point since > > > > it is such a tricky subject and depends a lot on the environment. The > > > > various rounding funcitons are particularly ugly IMHO. I added varients > > > > of them that preserved the floating point type and properly implemented > > > > IEEE behavior for jhc. > > > > > > I think the Data.Binary guys think it's a feature, since they rely in > > > this behavior (well, they rely on the equivalently-foolish behavior of > > > toRational). I think it's a bug. > > > > You mean: > > > > instance Binary Double where > > put d = put (decodeFloat d) > > get = liftM2 encodeFloat get get > > > > ? > > > > if you've a portable Double decoding that works in GHC and Hugs, I'm > > accepting patches. > > I really don't understand why being portable is such an issue. Is it > really better to behave wrong on every platform rather than behaving > wrong on a very small minority of platforms?
The Binary instances are required to be portable, as that's the part of the definition of Binary's mandate: a portable binary encoding. > Anyhow, I've not hacked on binary, because I've not used it, and have > trouble seeing when I would use it. So maybe I shouldn't have brought > the subject up, except that this use of decodeFloat/encodeFloat is a > particularly egregious misuse of floating point numbers. > decodeFloat > really ought to be a partial function, and this should be a crashing > bug, if the standard libraries were better-written. It's a bug in the H98 report then: Section 6.4.6: "The function decodeFloat applied to a real floating-point number returns the significand expressed as an Integer and an appropriately scaled exponent (an Int). If decodeFloat x yields (m,n), then x is equal in value to mb^n, where b is the floating-point radix, and furthermore, either m and n are both zero or else b^d-1<=m<b^d, where d is the value of floatDigits x. encodeFloat performs the inverse of this transformation. " -- Don _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe