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.]
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.]
Mark - you wouldn't happen to represent Double as
a double precision float in your build? If not,
something's wrong.
--Sigbjorn
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. If it doesn't, then
the system docs should spell out what behaviour to
expect (where else?)
At least that's my reading of the situation, so Fergus'
last Q is a good one, since isIEEE returns False with
Hugs. (i.e., you have the choice of carefully documenting
what's supported, or flip the isIEEE flag and deal with
bug reports instead. :-)
> Mark P Jones [mailto:[EMAIL PROTECTED]] writes:
>
> Hi Fergus,
>
> Thanks for your bug report:
>
> | For hugs-1.4, the following query
> |
> | hugs> let x::Double; x = (1.0e100 - 1.0e100) in x == x
> |
> | results in the answer "False" on a sparc-sun-solaris2.5 system.
> | It also results in the hugs interpreter crashing due to
> | "Unexpected signal"
> | on a dec-alpha-osf3.2 system. These should probably both be
> | considered bugs.
>
> And on an Intel machine I get yet another different behaviour: True!
>
> You're right that it's a problem, but I don't know how to address it.
> I do remember looking into this a few years ago and concluding that
> there was no way to handle it nicely with the range of different C
> compilers that `mattered to me' at the time. Times, and compilers,
> have changed however. If you've found a good way to deal with this
> in your Mercury implementation (or if anybody else has a good
> solution), then I'd be very interested to hear about it!
>
> | The other bug is that the documentation doesn't say what should
> | happen in the case of floating pointer overflow.
>
> I guess we must defer to the Haskell manual for that? Whatever it
> says goes, and if it doesn't say anything, then anything goes!
> (Or is that: if it says nothing, then nothing goes? :-)
>
> All the best,
> Mark
>
