From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from concorde.inria.fr (concorde.inria.fr [192.93.2.39]) by yquem.inria.fr (Postfix) with ESMTP id F1851BC48 for ; Sun, 10 Apr 2005 15:43:32 +0200 (CEST) Received: from smtp003.mail.ukl.yahoo.com (smtp003.mail.ukl.yahoo.com [217.12.11.34]) by concorde.inria.fr (8.13.0/8.13.0) with SMTP id j3ADhWYH020106 for ; Sun, 10 Apr 2005 15:43:32 +0200 Received: from unknown (HELO ?83.114.111.217?) (sejourne?kevin@83.114.111.217 with plain) by smtp003.mail.ukl.yahoo.com with SMTP; 10 Apr 2005 13:43:32 -0000 Message-ID: <42594BED.8070301@yahoo.fr> Date: Sun, 10 Apr 2005 15:53:17 +0000 From: sejourne_kevin User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050331) X-Accept-Language: fr, en MIME-Version: 1.0 Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] float precision on AMD64 References: <2a1a1a0c0504091814876c24a@mail.gmail.com> <42588430.3060105@rftp.com> <425914C2.1010101@yahoo.fr> <4259157C.5090400@exomi.com> <42593B4D.2040601@yahoo.fr> <425927FE.606@exomi.com> In-Reply-To: <425927FE.606@exomi.com> X-Enigmail-Version: 0.90.2.0 X-Enigmail-Supports: pgp-inline, pgp-mime Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Miltered: at concorde with ID 42592D84.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 rounding:01 rounding:01 wrote:01 wrote:01 slower:01 expression:01 floats:01 floats:01 logical:01 float:03 float:03 ecrit:04 bits:04 bits:04 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=disabled version=3.0.2 X-Spam-Level: Ville-Pertti Keinonen a écrit : > sejourne_kevin wrote: > >> Do you want to say that one small logical operation (' and ' or ' >> shift') after the evaluation of an expression ' float ' will be slower >> than the management of it box? > > > Shifting floats wouldn't make much sense, but you could just clear/set > the tag bit (it would be the least significant bit of the mantissa). > However, this would be insufficient if you wanted control over rounding > (you could only have round-toward-zero). > > Of course someone content with losing a bit of precision from the > mantissa probably wouldn't care too much about rounding. > The programs who works with floats in 32 bits shall also work with floats in 64 bits without one bit from the mantissa, no? So, what are we waiting for unbox the floats? Historical reason(C code wrote that use the box representation of the floats) ? Kévin.