Erik de Castro Lopo wrote:

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