On Mon, Jun 16, 2008 at 4:18 PM, David Roundy wrote:

On Mon, Jun 16, 2008 at 4:07 PM, Evan Laforge wrote:

...

Every other language throws an exception, even C will crash the program, so I'm guessing it's telling the processor / OS to turn these into signals, while GHC is turning that off. Or something. But then what about this note in Control.Exception:

That's just not true. It depends on how your system (compiler?) is configured, but the default on most systems that I've used is to return NaNs.

Sorry, I just read my post, and realized I quoted too much. I was responding to the first sentence about other languages, thinking of octave, C and C++. David

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. John -- John Meacham - ⑆repetae.net⑆john⑈

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. -- Don

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

On Mon, Jun 16, 2008 at 05:39:39PM -0700, Don Stewart wrote:

...

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

Yes, it is a bug in the report, that it doesn't fully specify the behavior this function when given a NaN or infinity. There's also a bug in the standard libraries, which is that they don't conform to the report. let x = 0/0 let (m,n) = decodeFloat x Prelude> (m,n) (-6755399441055744,972) Prelude> let x = 0/0 Prelude> x NaN Prelude> let d = floatDigits x Prelude> let (m,n) = decodeFloat x Prelude> let x' = (fromInteger m :: Double)*2^n Prelude> x' -Infinity Prelude> 2^d-1<=m False Prelude> m<2^d True So for the ghc decodeFloat, when operating on a NaN, the specifications of decodeFloat are almost completely unsatisfied. On the plus side, at least it's true that m

Since Haskell-Café often strays into mathematics, this may not be too far off topic. On 17 Jun 2008, at 2:29 pm, Evan Laforge wrote:

Yeah, on reflection, I think my "intuition" derives from me asking a math teacher back in high school "isn't n/0 infinity?" after looking at a graph, to which he said "no, it's undefined, you can only say it approaches infinity in the limit, but it isn't infinity".

Let's put this kindly: it is POSSIBLE that your maths teacher knew what he was talking about and was just telling what the "Science of Discworld" authors call "lies-to-children". It is certainly likely that it didn't occur to him that you might transfer what he said about the mathematical real numbers to a rather different algebraic system, IEEE floats. The usual "real numbers" R form an ordered field. *In that structure*, n/0 is undefined. But there is another algebraic structure which includes all the real numbers plus one more: infinity. It's call the real projective line. See http://en.wikipedia.org/wiki/Real_projective_line In that structure, n/0 is perfectly well defined, and is indeed infinity. That structure has all the properties you really need to do calculus, but isn't a field and isn't ordered. However, whenever an operation on elements of R is defined, the analogous operation on the corresponding elements of \hat R is defined and has the corresponding value. Basically, you can define operations any way you want as long as you are willing to live with the consequences. For example, it turns out to be possible to define an alternative arithmetic in which (-x)*(-y) = -(x*y) for positive x, y. The price is that it doesn't satisfy all the usual axioms, though it does satisfy other possibly useful ones that the usual systems don't. In an analogous way, the IEEE designers decided that it would be useful to have +/- epsilon instead of 0 and +/- (1/epsilon) instead of infinity, but then decided that the ordering operations should identify -epsilon with +epsilon, so the result still isn't quite a proper total order, even ignoring NaNs. (What happens if you sort a list of mixed +0.0 and -0.0? What, if anything, _should_ happen?) They obtained the benefits they wanted, at the price of making the resulting structure less like R. But then, floating point numbers never were _very_ much like R to start with. It's not clear to me that *R offers anything more than a heuristic analogy to IEEE arithmetic. For one thing, *R is ordered.