Re: [Caml-list] Need for a built in round_to_int function

[Erik de Castro Lopo <ocaml-erikd@mega-nerd.com>]

On Sun, 20 Feb 2005 16:00:53 -0800
Robert Roessler <roessler@rftp.com> 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