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 mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by yquem.inria.fr (Postfix) with ESMTP id 72D20BBAF for ; Mon, 23 Jun 2008 02:30:25 +0200 (CEST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AnUBAKOLXkjYi40Ilmdsb2JhbACSbAEBAQEJBQgYmmM X-IronPort-AV: E=Sophos;i="4.27,686,1204498800"; d="scan'208";a="12422080" Received: from mail-out8.nyct.net (HELO mail.nyct.net) ([216.139.141.8]) by mail2-smtp-roc.national.inria.fr with ESMTP; 23 Jun 2008 02:30:24 +0200 Received: from [192.168.42.2] (pool-96-250-28-207.nycmny.east.verizon.net [96.250.28.207]) (authenticated bits=0) by mail.nyct.net (8.14.2/8.14.1) with ESMTP id m5N0UKvp041733 (version=TLSv1/SSLv3 cipher=DHE-DSS-AES256-SHA bits=256 verify=NO); Sun, 22 Jun 2008 20:30:21 -0400 (EDT) (envelope-from bhurt@spnz.org) Date: Sun, 22 Jun 2008 21:06:19 -0400 (EDT) From: Brian Hurt X-X-Sender: bhurt@localhost To: =?ISO-8859-1?Q?Daniel_B=FCnzli?= Cc: caml-list caml-list Subject: Re: [Caml-list] Strange behaviour of string_of_float In-Reply-To: Message-ID: References: <4b5157c30806220956p164d8346i3e832bc8b8666306@mail.gmail.com> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="8323328-1784423763-1214183179=:3616" X-Spam: no; 0.00; unreadable:01 mime-aware:01 bunzli:01 serialize:01 integers:01 integers:01 deserialize:01 nans:01 infinities:01 iirc:01 specifies:01 10,:98 divs:98 wrote:01 readable:01 X-Attachments: cset="X-UNKNOWN" This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --8323328-1784423763-1214183179=:3616 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Sun, 22 Jun 2008, Daniel B=FCnzli wrote: > Richard gave you the reason. > > If you can serialize to binary, you can acheive what you want by serializ= ing=20 > the 64 bits integers you get with Int64.bits_of_float and applying=20 > Int64.float_of_bits to the integers you deserialize. Actually, for serialization, I strongly reccommend first using=20 classify_float to split off and handle NaNs, Infinities, etc., then using= =20 frexp to split the float into a fraction and exponent. The exponent is=20 just an int, and the fractional part can be multiplied by, say, 2^56 and=20 then converted into an integer. The advantage of doing things this way, despite it being slightly more=20 complicated, is two fold: one, it gaurentees you the ability to recovery=20 the exact binary value of the float, and two, it sidesteps a huge number=20 of compatibility issues between architectures- IIRC, IEEE 754 specifies=20 how many bits have to be used to represent each part of the float, but not= =20 where they have to be in the word. Also, if you use hexadecimal for=20 saving the integers, this can actually be faster than converting to=20 base-10, as conversion to base-10 isn't cheap. It's a couple of more=20 branches, but a lot of divs and mods get turned into shifts and ands. Brian --8323328-1784423763-1214183179=:3616--