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 BB347BC75 for ; Mon, 21 Feb 2005 07:50:32 +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 j1L6oUr1010269 for ; Mon, 21 Feb 2005 07:50:31 +0100 Received: (qmail 2351 invoked from network); 21 Feb 2005 06:50:42 -0000 Received: from unknown (HELO coltrane.mega-nerd.net) (218.214.64.136) by smtp.syd.swiftdsl.com.au with SMTP; 21 Feb 2005 06:50:42 -0000 Received: from coltrane (localhost [127.0.0.1]) by coltrane.mega-nerd.net (Postfix) with SMTP id 34BBD7ADA for ; Mon, 21 Feb 2005 17:50:29 +1100 (EST) Date: Mon, 21 Feb 2005 17:50:29 +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: <20050221175029.2754c608.ocaml-erikd@mega-nerd.com> In-Reply-To: <421964C6.3080102@rftp.com> References: <20050221072255.29055ee4.ocaml-erikd@mega-nerd.com> <421924B5.6030108@rftp.com> <20050221125103.4b7132f8.ocaml-erikd@mega-nerd.com> <421964C6.3080102@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 421984B6.000 by Joe's j-chkmail (http://j-chkmail.ensmp.fr)! X-Spam: no; 0.00; caml-list:01 wrote:01 rounding:01 compiler:01 defines:01 val:01 fist:98 nospam:98 behaviour:01 int:01 int:01 behave:02 float:03 float:03 truncate:04 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 20:34:14 -0800 Robert Roessler wrote: > 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). Implementing your proposal, means that int_of_float will change behaviour depending on a compiler flag. I think thats a bad idea. My proposal leaves int_of_float just as it is and defines a new function: val round_to_int : float -> int which expand to a FISTPL instruction and one or two glue instructions. Erik -- +-----------------------------------------------------------+ Erik de Castro Lopo nospam@mega-nerd.com (Yes it's valid) +-----------------------------------------------------------+ Good advice for everyone : stay away from churches, mosques and synagouges.