From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on yquem.inria.fr X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.1.3 X-Original-To: caml-list@yquem.inria.fr Delivered-To: caml-list@yquem.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by yquem.inria.fr (Postfix) with ESMTP id 1D467BBAF for ; Mon, 23 Jun 2008 10:45:33 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwCAKf/XkjC2fJbb2dsb2JhbACJbYh9AQwFAgYFEwOdFg X-IronPort-AV: E=Sophos;i="4.27,689,1204498800"; d="scan'208";a="14389299" Received: from anchor-post-33.mail.demon.net ([194.217.242.91]) by mail3-smtp-sop.national.inria.fr with ESMTP; 23 Jun 2008 10:45:32 +0200 Received: from orion.metastack.com ([80.177.38.218]) by anchor-post-33.mail.demon.net with esmtp (Exim 4.67) id 1KAhg3-0005pi-C7 for caml-list@yquem.inria.fr; Mon, 23 Jun 2008 08:45:31 +0000 Received: from countertenor (general-ld-222.t-mobile.co.uk [149.254.200.222]) (authenticated bits=0) by orion.metastack.com (8.13.4/8.13.3) with ESMTP id m5N8Y1Ws032558 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for ; Mon, 23 Jun 2008 09:34:07 +0100 From: "David Allsopp" To: "'caml-list caml-list'" References: <4b5157c30806220956p164d8346i3e832bc8b8666306@mail.gmail.com> <4b5157c30806221350xe608e08v1ed2d9a1e6b9d744@mail.gmail.com> Subject: RE: [Caml-list] Strange behaviour of string_of_float Date: Mon, 23 Jun 2008 09:45:04 +0100 Organization: MetaStack Solutions Ltd. Message-ID: <6975022428ED405199F4BC4DE14D970B@countertenor> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5512 thread-index: AcjUqBHm/YLVHH4KQoS/0GaYQmQXjQAYo2+w In-Reply-To: <4b5157c30806221350xe608e08v1ed2d9a1e6b9d744@mail.gmail.com> X-Scanned-By: MIMEDefang 2.63 on 172.16.28.218 X-Spam: no; 0.00; serialize:01 integers:01 integers:01 deserialize:01 pervasives:01 caml-list:01 int:01 int:01 behaviour:01 defined:02 defined:02 binary:02 string:02 string:02 float:03 > > Richard gave you the reason. Erm, please correct me if I'm wrong but every single possible floating point value (on the same architecture) has a string representation that will be reparsed to the same floating point value (on the same architecture). It's the reverse that isn't true because floating point numbers are only an approximation. > > If you can serialize to binary, you can acheive what you want by > > serializing the 64 bits integers you get with Int64.bits_of_float and > > applying Int64.float_of_bits to the integers you deserialize. > > Just posted a useless message :-) > > This is *exactly* what I was searching for, thanks Daniel. This is of course a better, more reliable and faster way of serialising, but the real cause for your original spurious result is down to how string_of_float is defined in pervasives.ml: # pi;; - : float = 3.1415926535897931 # string_of_float pi;; - : string = "3.14159265359" In other words, (pi |> string_of_float |> float_of_string) is never going to be equal to your original pi. For some reason, string_of_float is defined as: let string_of_float f = valid_float_lexem (format_float "%.12g" f);; Perhaps Xavier can say why it's only "%.12g" in the format (I imagine there's a historical reason) but if you increase it to 16 then you'll get the answer you expected (0.). All that said, the values given by string_of_float cannot always be fed back to float_of_string anyway (e.g. float_of_string (string_of_float nan)) David