On 18-Jul-2000, Sven Panne <[EMAIL PROTECTED]> wrote:
>
> Nevertheless, there seems to be some consensus that optimization should
> not change the outcome of a computation. Note that GCC's -O flag *does*
> change it, at least if -ffloat-store is not given in addition. The newly
> introduced GHC option -fstrictfp is intended to give back that guarantee,
> but after this discussion I feel that it should be the default behaviour.
I agree. And the inverse option (`-fno-strict-fp') should be documented
as not conforming to the Haskell report.
> A short description of GHC's internal handling of floating point values
> and the accompanying problems:
>
> * GHC uses IEEE arithmetic for Float and Double.
Is that true for every platform that GHC targets?
> * Floating point values are internally represented as Rationals, which
> is completely OK for literals given by the programmer. It is flexible
> enough to make cross-compilation possible (which GHC currently can't
> do for other reasons), a possibility which would be lost if Float/Double
> were used for this, so this approach would be a step in the wrong
> direction.
If all the platforms that GHC target use the same IEEE arithmetic
and representation for Float/Double, why does GHC need to use
Rational to represent floating pointer values?
--
Fergus Henderson <[EMAIL PROTECTED]> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger [EMAIL PROTECTED] | -- the last words of T. S. Garp.
