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? 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. David