From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA16178; Sat, 4 May 2002 10:53:27 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id KAA16181 for ; Sat, 4 May 2002 10:53:26 +0200 (MET DST) Received: from pauillac.inria.fr (pauillac.inria.fr [128.93.11.35]) by concorde.inria.fr (8.11.1/8.11.1) with ESMTP id g448rPX11989; Sat, 4 May 2002 10:53:25 +0200 (MET DST) Received: (from xleroy@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id KAA16177; Sat, 4 May 2002 10:53:24 +0200 (MET DST) Date: Sat, 4 May 2002 10:53:24 +0200 From: Xavier Leroy To: "Beck01, Wolfgang" Cc: caml-list@inria.fr Subject: Re: [Caml-list] string_of_float less accurate than sprintf "%f" ? Message-ID: <20020504105324.A15588@pauillac.inria.fr> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Mailer: Mutt 1.0i In-Reply-To: ; from BeckW@t-systems.com on Tue, Apr 30, 2002 at 10:21:43AM +0200 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk > while doing some time measurements with Unix.gettimeofday() I > discovered a problem with string_of_float: > > # string_of_float 123456789.123456789;; > - : string = "123456789.123" > > OK, just it may by just an inaccuracy of the float type. However, > sprintf returns a different result: > > # sprintf "%f" 123456789.123456789;; > - : string = "123456789.1234567" This is not an inaccuracy of the underlying float value, which is indeed double-precision, but a consequence of the definition of string_of_float, which is essentially sprintf "%.12g". So, you get a different rounding than sprintf "%f". Here, %f is more precise, but not always (try with 1e-12 for instance). > My application needs to be fast (that's why I am using OCaml :-) and > sprintf is of course slower than string_of_float. Not by much. I recommend that you use sprintf with the floating-point format appropriate for your application, e.g. "%.3f" for printing times with a millisecond precision. Now, you might wonder why string_of_float doesn't "do the right thing" and prints its float argument with as many digits as necessary to ensure e.g. float_of_string(string_of_float f) = f. The main reason is pragmatic: OCaml's float-to-string conversions are built on top of the sprintf() function from the C runtime library, and the latter doesn't provide a "print a float with enough digits to represent it exactly" format. David Chase mentioned some third-party source that does this (thanks for the pointer); I wish the C library would provide something like this. There might be a more philosophical issue behind this. For a numerical analyst, or physicist, or experimental scientist in general, floating-point numbers are just approximate measurements of experimental measures, or results of computations on these approximate measurements. Hence, there is no such thing as "the" string representation of a floating-point value: not all digits are meaningful, and how many significant digits to print depends on the physical problem being modeled and solved. With this viewpoint, string_of_float doesn't make any sense, and you should always use sprintf with the float format appropriate for your problem. Then, there is the computer engineering viewpoint on floating-point numbers, which are collections of (say) 64 bits with well-defined (if a bit convoluted) operations on them such as addition, multiplication, etc, as specified in IEEE 754. From this viewpoint, it makes sense to have conversions to and from strings that are exact, i.e. without information loss. (It is feasible, but much harder than it sounds; there was two full papers at PLDI 94 (?) on this problem.) I'm not taking sides here, just noticing that Java takes the computer engineering viewpoint and C (and Caml, by inheritance of implementation :-) takes the physicist's viewpoint... - Xavier Leroy ------------------- To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/ Beginner's list: http://groups.yahoo.com/group/ocaml_beginners