caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
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


  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;
as well as URLs for NNTP newsgroup(s).