From: Jon Harrop <jon@jdh30.plus.com>
To: caml-list@yquem.inria.fr
Subject: Re: [Caml-list] [Bug] Different behavior bytecode/nativecode
Date: Sun, 27 Feb 2005 04:44:50 +0000 [thread overview]
Message-ID: <200502270444.51192.jon@jdh30.plus.com> (raw)
In-Reply-To: <20050227.011343.11780601.Christophe.Troestler@umh.ac.be>
On Sunday 27 February 2005 00:13, Christophe TROESTLER wrote:
> When I compile the attached program to bytecode, I get the output
> "0.000000 -1.000000 -> 1" (which is correct) but when I compile to
> native code the result is "0.000000 -1.000000 -> 0".
>
> The error stops when I substitute "invw" in "let cr = 300. *. invw
> -. 1.5" by its definition (i.e. if I write
> "let cr = 300. *. (2. /. float w) -. 1.5").
>
> Curious to know what is the problem.
The problem is the conflict of interests between having ocamlc and ocamlopt
behave identically, and having ocamlopt-compiled code achieve good
performance. In floating-point code, ocamlopt can sometimes generate slightly
different results from ocamlc.
Specifically, your code is numerically unstable at the specified values and
ocamlopt is generating x86 code which is partly performed in 80-bit registers
(300. *. invw -. 1.5) and partly stored in 64-bit memory locations (2. /.
float w) whereas ocamlc is storing everything in 64-bit memory locations.
This leads ocamlc to a result of exactly zero and ocamlopt to a result
slightly above zero (cr=0.00000000000000003). The rest of the code is then
numerically unstable with respect to this result.
Inlining the definition of "invw" simply causes the ocamlopt-compiled
program's computation to be performed entirely at 80-bits, giving the desired
result of precisely zero:
$ cat >a.ml
let x = 2. /. 400.;;
Printf.printf "%.30f\n" (300. *. x -. 1.5);;
Printf.printf "%.30f\n" (300. *. (2. /. 400.) -. 1.5);;
$ ocamlc a.ml -o a
$ ./a
0.000000000000000000000000000000
0.000000000000000000000000000000
$ ocamlopt a.ml -o a
$ ./a
0.000000000000000031225022567583
0.000000000000000000000000000000
This is described in chapter 4 of "Objective CAML for Scientists":
http://www.ffconsultancy.com/products/ocaml_for_scientists/
See also "Re: bug in floating point implementation ?" by Xavier Leroy:
http://caml.inria.fr/caml-list/1147.html
--
Dr Jon D Harrop, Flying Frog Consultancy Ltd.
http://ffconsultancy.com
next prev parent reply other threads:[~2005-02-27 4:43 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-27 0:13 Christophe TROESTLER
2005-02-27 2:32 ` [Caml-list] " Kurt Welgehausen
2005-02-27 4:44 ` Jon Harrop [this message]
2005-02-27 10:13 ` Christophe TROESTLER
2005-02-27 11:10 ` Jon Harrop
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200502270444.51192.jon@jdh30.plus.com \
--to=jon@jdh30.plus.com \
--cc=caml-list@yquem.inria.fr \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox