[Cfp-interest 1662] Re: intmax_t removal
Jim Thomas
jaswthomas at sbcglobal.net
Wed Jun 24 11:50:55 PDT 2020
For the Summary, I suggest saying more about why we’re recommending a change. The WG14 consideration of removing [u]intmax_t, sparked the CFP discussion. I think we concluded that changing the interfaces to not use [u]intmax_t would be better anyway (even if [u]intmax_t were not removed). Introducing type [u]intmax_t into an expression via a function return type could have unpredictable negative performance implications. For the compoundn, pown, and rootn functions, long long int appears to be more than adequate for applications.
The changes to compoundn, pown, and rootn seem straightforward. On further thought, the change to the fromfp functions does not. For example, what would the functions do if the input does not round to an integer of the given width?
The key point for IEC 60559 binding is that composing the function with a cast (or assignment) of the result to the desired integer type must have the behavior of the corresponding IEC 60559 conversion from floating-point to integer operation. For example, to convert from double to int128_t using to-nearest rounding without inexact, do
double d;
int128_t i128;
i128 = fromfp(d, FE_INT_UPWARD, INT128_WIDTH);
In the process of rewriting the Description for the fromfp functions, I wondered ...
Do we already have this functionality (without the fromfp functions)? For example, could the conversion above be done with
double d;
int128_t i128;
{
#pragma STDC FENV_ROUND FE_UPWARD
i128 =nearbyint(d); // or rint to raise inexact
}
The nearbyint rounds to integer value using the given rounding direction, and preserves infinities and NaNs. The assignment to i128 will raise invalid if the function result is infinite, NaN, or out of range.
Does this handle all the edge cases (infinities, NaNs, our of range values, exceptions) per IEC 60559? Does the scheme work for the combinations of floating and (signed and unsigned) integer types? If so, would this be an acceptable binding?
- Jim Thomas
>
> On Jun 22, 2020, at 3:01 PM, Fred J. Tydeman <tydeman at tybor.com> wrote:
>
> On Fri, 19 Jun 2020 10:11:01 -0700 (PDT) Fred J. Tydeman wrote:
>>
>> intmax_t removal: *from* return FP type same as argument.
>
> Attached is a first pass on just some of the functions.
> If you are happy with the direction, I will add the others.
>
>
>
> ---
> Fred J. Tydeman Tydeman Consulting
> tydeman at tybor.com <mailto:tydeman at tybor.com> Testing, numerics, programming
> +1 (702) 608-6093 Vice-chair of PL22.11 (ANSI "C")
> Sample C99+FPCE tests: http://www.tybor.com <http://www.tybor.com/>
> Savers sleep well, investors eat well, spenders work forever.
>
>
> Submitter:Fred J. Tydeman
> Submission Date: 2020-mm-dd
> Document: WG14 N2xxx
> Title: N2xxx: intmax_t and math functions
> Reference Documents: N2478
>
> Summary
>
> Due to issues raised by the WG14 committee with [u]intmax_t, several of the CFP related functions ([u]fromfp[x], compoundn, pown, rootn) should be changed to not use [u]intmax_t. In general, replace [u]intmax_t with the floating type used as the parameter.
> Change
>
> 7.12.9.10 The fromfp and ufromfp functions
> Synopsis
>
> 1 #include <stdint.h>
> #include <math.h>
> intmax_t fromfp(double x, int round, unsigned int width);
> intmax_t fromfpf(float x, int round, unsigned int width);
> intmax_t fromfpl(long double x, int round, unsigned int width);
> uintmax_t ufromfp(double x, int round, unsigned int width);
> uintmax_t ufromfpf(float x, int round, unsigned int width);
> uintmax_t ufromfpl(long double x, int round, unsigned int width);
> #ifdef __STDC_IEC_60559_DFP__
> intmax_t fromfpd32(_Decimal32 x, int round, unsigned int width);
> intmax_t fromfpd64(_Decimal64 x, int round, unsigned int width);
> intmax_t fromfpd128(_Decimal128 x, int round, unsigned int width);
> uintmax_t ufromfpd32(_Decimal32 x, int round, unsigned int width);
> uintmax_t ufromfpd64(_Decimal64 x, int round, unsigned int width);
> uintmax_t ufromfpd128(_Decimal128 x, int round, unsigned int width);
> #endif
>
>
> Description
> 2 The fromfp and ufromfp functions round x, using the math rounding direction indicated by round, to a signed or unsigned integer, respectively, of width bits, and return the result value in the integer type designated by intmax_t or uintmax_t, respectively. If the value of the round argument is not equal to the value of a math rounding direction macro, the direction of rounding is unspecified. If the value of width exceeds the width of the function type, the rounding is to the full width of the function type. The fromfp and ufromfp functions do not raise the "inexact" floating-point exception. If x is infinite or NaN or rounds to an integral value that is outside the range of any supported integer type of the specified width, or if width is zero, the functions return an unspecified value and a domain error occurs.
>
> 3 Returns
> The fromfp and ufromfp functions return the rounded integer value.
>
> 4 EXAMPLE Upward rounding of double x to type int, without raising the "inexact" floating-point exception, is achieved by
>
>
> (int)fromfp(x, FP_INT_UPWARD, INT_WIDTH)
>
>
> to
>
> 7.12.9.10 The fromfp and ufromfp functions
> Synopsis
>
> 1 #include <stdint.h>
> #include <math.h>
> intmax_t double fromfp(double x, int round, unsigned int width);
> intmax_t float fromfpf(float x, int round, unsigned int width);
> intmax_t long double fromfpl(long double x, int round, unsigned int width);
> uintmax_t double ufromfp(double x, int round, unsigned int width);
> uintmax_t float ufromfpf(float x, int round, unsigned int width);
> uintmax_t long double ufromfpl(long double x, int round, unsigned int width);
> #ifdef __STDC_IEC_60559_DFP__
> intmax_t _Decimal32 fromfpd32(_Decimal32 x, int round, unsigned int width);
> intmax_t _Decimal64 fromfpd64(_Decimal64 x, int round, unsigned int width);
> intmax_t _Decimal128 fromfpd128(_Decimal128 x, int round, unsigned int width);
> uintmax_t _Decimal32 ufromfpd32(_Decimal32 x, int round, unsigned int width);
> uintmax_t _Decimal64 ufromfpd64(_Decimal64 x, int round, unsigned int width);
> uintmax_t _Decimal128 ufromfpd128(_Decimal128 x, int round, unsigned int width);
> #endif
>
>
> Description
> 2 The fromfp and ufromfp functions round x, using the math rounding direction indicated by round, to a signed or unsigned integer, respectively, of width bits, and return the result value in the integer type designated by intmax_t or uintmax_t, respectivelyas in integer in floating-point format. If the value of the round argument is not equal to the value of a math rounding direction macro, the direction of rounding is unspecified. If the value of width exceeds the width of the function type, the rounding is to the full width of the function type. The fromfp and ufromfp functions do not raise the "inexact" floating-point exception. If x is infinite or NaN or rounds to an integral value that is outside the range of any supported integer type of the specified width, or if width is zero, the functions return an unspecified valuea NaN (if available, else HUGE_VAL) and a domain error occurs.
>
> 3 Returns
> The fromfp and ufromfp functions return the rounded integer value.
>
> 4 EXAMPLE Upward rounding of double x to type int, without raising the "inexact" floating-point exception; unsigned wrapping is not performed in the second call, is achieved by
>
>
> (int)fromfp(x, FP_INT_UPWARD, INT_WIDTH)
> fromfp(-3.0, FP_INT_UPWARD, UINT_WIDTH) /* domain error */
>
>
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net <mailto:Cfp-interest at oakapple.net>
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest <http://mailman.oakapple.net/mailman/listinfo/cfp-interest>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20200624/0c7ab6c8/attachment-0001.htm>
More information about the Cfp-interest
mailing list