Date: Thu, 25 Feb 1999 13:10:27 +0100
From: Xavier Leroy <Xavier.Leroy@inria.fr>
To: Shyjan Mahamud <mahamud@marr.ius.cs.cmu.edu>, caml-list@inria.fr
Subject: Re: bug in floating point implementation ?
In-Reply-To: <199902250043.BAA21786@nez-perce.inria.fr>; from Shyjan Mahamud on Wed, Feb 24, 1999 at 07:43:05PM -0500
> i'm new to CAML, so i'm not sure if this is a known issue.
> is there a known bug or difference in the implementation of floating
> point arithmetic between the toplevel and that for the standalone
> compiled version. i've run the same exact function from both the
> toplevel and a standalone program. the numbers come out slightly
> different.
The toplevel and the bytecode compiler (ocamlc) should give exactly
the same results, because they use the same bytecode compiler, virtual
machine and C primitives.
The native-code compiler (ocamlopt) generates in-line assembly code
for floating-point operations, of course, and also has various
unboxing strategies that are not found in ocamlc and in the toplevel.
On all architectures except the Intel x86, the ocamlopt tricks
shouldn't make any differences, because the same floating-point format
(IEEE double) is used everywhere.
The Intel x86 has an interesting quirk: it computes internally in
extended precision (80 bits), and rounds to double precision (64 bits)
only when storing a result in memory. This means that in a piece of
code such as
let x = a * b + c
the virtual machine will compute a * b, round it (by storing it in
memory), add c, and round the result. While the native-code compiler
will compute a * b, keep the result in extended precision in the top
float register, then add c, then round the result.
In extreme cases (badly conditioned algorithm, computation of errors),
you may thus get different results.
(Similar problems plague all x86 compilers. It's really bad for Java,
which specifies that all computations must be done in 64 bits.)
If you don't think this explains your problem (e.g. you see the same
discrepancies on other processors), please send me a complete program
that reproduces the problem and I'll look at it.
- Xavier Leroy
This archive was generated by hypermail 2b29 : Sun Jan 02 2000 - 11:58:20 MET