From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Delivered-To: caml-list@yquem.inria.fr Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by yquem.inria.fr (Postfix) with ESMTP id 0B15EBC8E for ; Mon, 21 Feb 2005 05:34:01 +0100 (CET) Received: from smtp804.mail.sc5.yahoo.com (smtp804.mail.sc5.yahoo.com [66.163.168.183]) by nez-perce.inria.fr (8.13.0/8.13.0) with SMTP id j1L4XxNN023917 for ; Mon, 21 Feb 2005 05:34:00 +0100 Received: from unknown (HELO ?192.168.1.100?) (rftp@pacbell.net@63.194.18.166 with plain) by smtp804.mail.sc5.yahoo.com with SMTP; 21 Feb 2005 04:33:58 -0000 Message-ID: <421964C6.3080102@rftp.com> Date: Sun, 20 Feb 2005 20:34:14 -0800 From: Robert Roessler Organization: Robert's High-performance Software User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041217 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Erik de Castro Lopo Cc: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Need for a built in round_to_int function References: <20050221072255.29055ee4.ocaml-erikd@mega-nerd.com> <421924B5.6030108@rftp.com> <20050221125103.4b7132f8.ocaml-erikd@mega-nerd.com> In-Reply-To: <20050221125103.4b7132f8.ocaml-erikd@mega-nerd.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-Miltered: at nez-perce with ID 421964B7.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 wrote:01 wrote:01 rounding:01 unreasonable:01 manpage:01 rounding:01 unspecified:01 o'caml:01 compiler:01 compiler:01 ocamlopt:01 bytecode:01 runtime:01 bytecode:01 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: Erik de Castro Lopo wrote: > On Sun, 20 Feb 2005 16:00:53 -0800 > Robert Roessler wrote: > ... >>You, on the other hand, are willing to make an assumption regarding >>the hardware rounding mode - [presumably] that it is set to the >>power-on default of "Round to nearest, or to even if equidistant", >>which may not be unreasonable - it just needs to be explicit that this >>*is* the assumption, and that you have a way of verifying (or at least >>reason to believe) that other software components in your app's >>environment are not invalidating this assumption. > > >>>From the lrint manpage on Linux: > > These functions round their argument to the nearest integer value, > using the current rounding direction. If x is infinite or NaN, or if > the rounded value is outside the range of the return type, the numeric > result is unspecified. A domain error may occur if the magnitude of x > is too large. > > I would suggest something similar for the proposed O'Caml function. Exactly like the "FIST[P]" instruction without explicit control word saving, setting and restoring - which is believable, since according to your first post, your reference implementation is done this way. >>The fact that the default hardware rounding mode does NOT match "(int) >>floor (f + 0.5)" should also be mentioned... the "+ 0.5" attempts to >>do what the hardware would call "Round up (toward +infinity)" > > > Careful, that could very easily be confused with the C functions ceil(). Umm, 2 of the IEEE hardware rounding modes *do* seem to match floor() and ceil()... it is probably not a coincidence. :) >>This could take the form of a compiler switch exactly like "/QIfist", > > > A compiler switch is significantly more complicated than my proposal > for a new built-in function with a well defined behaviour. > > The compiler switch causes all int_to_float to behave like a round > instead of a truncate. My proposal allows a single file to have > both behaviours. Actually, emulating the VC7 "/QIfist" does NOT cause "all int_to_float to behave like a round instead of a truncate" - it does exactly what we are already talking about: do the int_of_float with a "bare" FIST[P], operating in whatever rounding mode the hardware is already in (presumably one we want and expect it to be in). >>Of course, if something like this were to added to ocamlopt (for >>target architectures using IEEE floating point), code (an additional >>bytecode op?) emulating the same behavior could be added to the >>runtime to maintain consistency across the interpreted and native >>operating environments - or not. > > > I believe that the bytecode interpreter simply uses the definitions > supplied by ocamlopt. Once ocamlopt has this functionality there > is not much else required to allow the interpretter to use the same > functionality. The bytecode interpreter has nothing to do with ocamlopt... in fact, the primitive for doing int_of_float is precisely return Val_long((long) Double_val(f)); which will perform a "truncate" operation for the conversion, since that is what the C standard requires. :) Robert Roessler roessler@rftp.com http://www.rftp.com