Version française
Home     About     Download     Resources     Contact us    

This site is updated infrequently. For up-to-date information, please visit the new OCaml website at

Browse thread
bug in floating point implementation ?
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: 1999-02-25 (16:40)
From: Xavier Leroy <Xavier.Leroy@i...>
Subject: Re: bug in floating point implementation ?
> 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