caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: David Monniaux <David.Monniaux@ens.fr>
To: Xavier Leroy <Xavier.Leroy@inria.fr>
Cc: seanmcl@cmu.edu, caml-list@inria.fr
Subject: Re: [Caml-list] float rounding
Date: Fri, 24 Nov 2006 00:00:42 +0100	[thread overview]
Message-ID: <4566281A.9080402@ens.fr> (raw)
In-Reply-To: <451FEE9C.9040501@inria.fr>

Xavier Leroy a écrit :
>> I'm using Ocaml for an interval arithmetic application.  I"m  curious
>> about what the Ocaml parser/compiler does to float constants.
>>
>> - For the native-code compiler ocamlopt, some ports go the
>> float_of_string route, but most output the literal as a string in the
>> generated assembly code, letting the assembler do the conversion.
>> The assembler is likely to use strtod() or atof(), though.
> As Gerd said, the C standards do not guarantee this, so it really
> depends on how well-implemented your C library is.
In C, if you are really concerned about getting your exact constants up 
to the last bit, you should use the hexadecimal float notation 
introduced in C99. You should also use "%a" or "%A" to print out your 
floating-point values in hexadecimal if you intend to reload them on 
another IEEE-754 system in a portable way.

(Unfortunately on OCaml, %a is already used for another use... Xavier, 
what do you think of adding the hexadecimal float conversion to the 
family of printf functions?)

Anyway, "IEEE-754 compliant", as used by common vendors, is a fairly 
vague claim. For instance, contrary to a commonly held belief, the same 
C or Caml program ran on two different major platforms (say, IA32 vs 
AMD64 or IA32 vs PowerPC) can give different results, possibly even 
depending on compiler options, and this has nothing to do with how they 
parse constants... You might wish to read my preprint:
http://www.di.ens.fr/~monniaux/biblio/pitfalls_of_floating_point.pdf

The only widespread language that I know about that has fixed semantics 
for floating-point is Java if the 'strictfp' modifier is used. 
(Originally, Java was supposed to have a fully fixed semantics, but they 
realized that implementing it over the 80387 compatible floating-point 
stack was difficult and that it also precluded some optimizations, so 
they relaxed it by default and introduced 'strictfp'. Goodbye 
predictability.)


  reply	other threads:[~2006-11-24  0:28 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-09-30 18:25 Sean McLaughlin
2006-10-01 12:44 ` [Caml-list] " Florent Monnier
2006-10-01 13:36 ` Gerd Stolpmann
2006-10-01 16:36 ` Xavier Leroy
2006-11-23 23:00   ` David Monniaux [this message]
2006-10-03 13:41 ` Christophe Raffalli
2006-10-03 19:59 ` Christophe Raffalli
2006-10-03 21:05   ` Olivier Andrieu
2006-11-26  1:51     ` David Monniaux

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=4566281A.9080402@ens.fr \
    --to=david.monniaux@ens.fr \
    --cc=Xavier.Leroy@inria.fr \
    --cc=caml-list@inria.fr \
    --cc=seanmcl@cmu.edu \
    /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).