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 CB310BC8E for ; Mon, 21 Feb 2005 02:51:09 +0100 (CET) Received: from smtp.syd.swiftdsl.com.au (smtp.syd.swiftdsl.com.au [218.214.224.138]) by concorde.inria.fr (8.13.0/8.13.0) with SMTP id j1L1p6UL009140 for ; Mon, 21 Feb 2005 02:51:08 +0100 Received: (qmail 14255 invoked from network); 21 Feb 2005 01:51:10 -0000 Received: from unknown (HELO coltrane.mega-nerd.net) (218.214.64.136) by smtp.syd.swiftdsl.com.au with SMTP; 21 Feb 2005 01:51:10 -0000 Received: from coltrane (localhost [127.0.0.1]) by coltrane.mega-nerd.net (Postfix) with SMTP id 37B007ADA for ; Mon, 21 Feb 2005 12:51:03 +1100 (EST) Date: Mon, 21 Feb 2005 12:51:03 +1100 From: Erik de Castro Lopo To: caml-list@yquem.inria.fr Subject: Re: [Caml-list] Need for a built in round_to_int function Message-Id: <20050221125103.4b7132f8.ocaml-erikd@mega-nerd.com> In-Reply-To: <421924B5.6030108@rftp.com> References: <20050221072255.29055ee4.ocaml-erikd@mega-nerd.com> <421924B5.6030108@rftp.com> Organization: Erik Conspiracy Secret Labs X-Mailer: Sylpheed version 1.0.0 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Miltered: at concorde with ID 42193E8A.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 wrote:01 compiler:01 rounding:01 rounding:01 unreasonable:01 manpage:01 unspecified:01 o'caml:01 compiler:01 ocamlopt:01 bytecode:01 runtime:01 bytecode:01 ocamlopt:01 X-Spam-Checker-Version: SpamAssassin 3.0.2 (2004-11-16) on yquem.inria.fr X-Spam-Status: No, score=0.1 required=5.0 tests=FORGED_RCVD_HELO autolearn=disabled version=3.0.2 X-Spam-Level: On Sun, 20 Feb 2005 16:00:53 -0800 Robert Roessler wrote: > I will preface this by a Slashdot-like "IANANA" (I Am Not A Numerical > Analyst). Nor am I. I don't play one in a TV show either. > The above approach is more or less what you expect if you (as a > compiler code generator) a) want to do rounding following C/C++ > standards ("Truncate (toward 0)"), and b) make no assumption regarding > the state of the IEEE hardware rounding setting... Yes. > 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. > 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(). > 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. > 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. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ "When you say "I wrote a program that crashed Windows", people just stare at you blankly and say "Hey, I got those with the system, *for free*." -- Linus Torvalds