On 21-Jan-1999, Sigbjorn Finne (Intl Vendor) <[EMAIL PROTECTED]> wrote:
>
> This is not a bug, but expected behaviour since
> Hugs implements Doubles using single-precision
> floats (by default - there's a flag that can
> be flipped in config.h for this, I believe.)
>
> Converting 1.0e100 into a float should yield
> Inf, with Inf - Inf = NaN. The result of NaN == NaN
> is False. Hence, the Sparc result is cool
> (wrt. IEEE 754.) [Aside: FP purists may not agree
> with this, but IEEE 754 is pretty much the
> universal standard (LIAS never seemed to catch on),
> so having Haskell deviate would be a Bad Idea.
> If you care about equals-for-equals and stuff,
> stick to Rational, I'd say.]
I don't have IEEE 754 on hand, but I think it recommends that
the default behaviour should be to generate some kind of
"hard-to-ignore" signal or exception if a computation results
in a NaN.
In any case, IEEE 754 does not specify the result of Haskell's "==".
For example, defining Haskell's "==" operator to always return 42
would not require any deviation from strict IEEE 754 conformance!
So arguments based on IEEE 754 conformance can't provide
any definitive answer to questions about what Haskell's "=="
operator should do.
The statement that LIAS never seemed to catch on is a bit
premature, I think. LIAS is a fairly new standard and
I think it will take some time for languages to define
bindings to this standard. Last time I looked, the new C9X
draft standard included an (informative) annex which specified
an LIAS binding. And I've also seen LIAS used for other new
languages, e.g. Goedel.
> Re: alpha - with gcc, the default is not to catch
> exceptional FP conditions in software and convert
> them into IEEE exceptional values, hence the observed
> behaviour when attempting to convert 1.0e100 into a
> float (at least that's my guess at what's signalling
> here!) [For what it's worth, ghc compiled code on
> the Alpha doesn't try to avoid these floating point
> exceptions either.]
The difference is that hugs is an interactive system.
Aborting the current computation is a fine thing to do,
but the hugs interpreter itself should not abort.
> Re: Haskell and floats, if (isIEEE (x::Double)) returns
> True on your system, that should be a clear indication
> at what behaviour to expect/demand.
Not entirely -- you still need an IEEE binding,
that is a document describing which Haskell operations
correspond to which IEEE operations, and defining
any implemented-defined behaviour. I don't have the IEEE
standard, so I don't know what behaviours are implementation-defined,
but I think that whether and/or how exceptions are signalled might be one
of them.
--
Fergus Henderson <[EMAIL PROTECTED]> | "Binaries may die
WWW: <http://www.cs.mu.oz.au/~fjh> | but source code lives forever"
PGP: finger [EMAIL PROTECTED] | -- leaked Microsoft memo.
