[Cfp-interest] functions: thoughts about conversions - version 0

[Jim Thomas]

David Hough CFP wrote:

>Another way to deal with the number of 
>convertToInteger FP to integer type conversion functions:
>
>
>Add four functions for each FP type:
>
> maxint  from_FP  ( FP x, int round, int bits );
> maxint  from_FP_x( FP x, int round, int bits );
>umaxint ufrom_FP  ( FP x, int round, int bits );
>umaxint ufrom_FP_x( FP x, int round, int bits );
>
>These functions return the maximum length signed or unsigned
>integer type in an implementation.
>
>The FP functions do not signal the inexact exception.
>The FPx functions do signal the inexact exception when an otherwise
>valid result differs in value from x.
>  
>
At last Thursday's study group meeting I noted that the scheme for 
detecting inexact, in the 03 Aug version of the Functions spec, didn't 
work because invalid out of range cases may signal inexact if the 
destination integer type has more precision than the floating-point 
type. (Who came up with that scheme??) This led us to reconsider 
alternatives 1 and 2, and again balk at the huge number of user 
functions required for alternative 1. The approach above is a variation 
on alternative 2, originally proposed by Fred. The macros below seem 
like a move back toward alternative 1.

>While an implementation shall provide these functions, it should also
>define macros that correspond to functions that are implemented
>efficiently in hardware.    Although optimizing compilers might recognize
>some invocations of these functions and convert them into efficient
>hardware sequences, programmers can help make their intents clear
>by using such macros.
>
>Thus if "(int)x" happens to signal invalid or integer overflow
>correctly for x of type double, without signaling inexact, then
>
>#define from_double_trunc_int(x) ((int)(x))
>
>would be a handy macro in lieu of
>
>#define from_double_trunc_int(x) ((int)from_FP(x,trunc,8*sizeof(int)))
>
>which would be guaranteed to handle exceptions correctly in all conforming
>implementations.
>
>In contrast,
>
>#define ufrom_Float32x_floor_16(x) ((int16)ufrom_Float32x_x(x,floor,16))
>
>might be a handy macro for conversions from _Float32x to 16-bit unsigned
>integers signaling inexact, but it is less likely to have an efficient
>hardware implementation.
>
>(Should we list all the macro names and require that they be defined?
>All 4 x 5 macros per {FP type, int type} pair?   Probably not, although
>macros are less of a burden than functions.   Or should we define the form of
>the macro names and recommend that an implementation define only those
>that have an efficient hardware implementation?).
>  
>
Potentially the macros help with usability, performance, and 
implementation. But having a lot of macros suffers from the same 
usability problems as Alternative 1. Having some of the macros be 
optional might help implementors but would confuse the API and hurt 
portability. An optimizing implementation can replace a call with 
constant second and third arguments to one of the four basic functions 
with something efficient (if available), so I don't see the macros as 
essential for performance. Most uses of this functionality (performance 
or otherwise) won't need the inexact exception and can use the simple 
expressions in the current proposal, e.g., (uint64_t)ceilf128(x).

>_______________________________________________
>Cfp-interest mailing list
>Cfp-interest at oakapple.net
>http://mailman.oakapple.net/mailman/listinfo/cfp-interest
>
>
>  
>