[Cfp-interest] WG14 IEEE 754-C binding meeting minutes 2018/07/25

Jim Thomas jaswthomas at sbcglobal.net
Thu Aug 16 12:19:31 PDT 2018



> On Jul 26, 2018, at 3:59 PM, Fred J. Tydeman <tydeman at tybor.com> wrote:
> 
> On Wed, 25 Jul 2018 11:24:55 -0500 Rajan Bhakta wrote:
>> 
>>   Fred: Recheck 'Functions and infinity' issues with 754 draft 238. - 
>> 
> 
> IEEE 754 vs 18661 (and C17) for infinity
> 
> Possible global issue:  754 uses an unsigned infinity and C uses +/-infinity.
> One such example is: remainder(x,inf) vs remainder(x,+/-inf).
> But, a counter example is: cosh(+/-inf) is +inf
> 
> I am assuming that 754's unsigned infinity is the same as +/-infinity.

I believe 754 has resolved that it uses unsigned inf when the sign doesn’t matter. Cfp use of +/- seems ok.
> 
> roundeven - ok
> round - ok
> trunc - ok
> ceil - ok
> floor - ok
> rint - ok
> 
> nextup - ok
> nextdown - ok
> remainder - ok
> remquo - ok
> 
> quantize - ok
> quantum - CFP has: If x is NaN, the result is NaN.
>          754 has no mention about NaN.

That’s the default behavior. Should we remove the statement from P2?

> 
> scaleb - ok
> logb - ok
> 
> fadd - Do we need to add something to Annex F for fadd(+inf,-inf)?
> fsub - Do we need to add something to Annex F for fsub(+inf,+inf)?
> fmul - Do we need to add something to Annex F for fmul(0,inf)? 
> fdiv - Do we need to add something to Annex F for fdiv(inf,inf), fdiv(0,0)?
> ffma - Do we need to add something to Annex F for ffma(inf,0,z), ffma(+inf,+y,-inf)?
> fsqrt - Do we need to add something to Annex F for fsqrt(-inf)?

We cover these implicitly by saying they’re fully specified in 60559. But for consistency in documentation style, with sqrt for example, we would state these cases explicitly. Maybe we could make a general statement that they handle 0 and inf arguments like +, -, *, /, fma, and sqrt, respectively.

> convertFromInt - ok
> 
> convertToInteger...
> fromfp - ok
> ufromfp - ok
> fromfpx - ok
> ufromfpx - ok
> lround - ok
> 
> canonicalize - ok
> 
> scanf,... - ok
> printf,... - ok
> 
> copy - ok
> negate - ok
> fabs - ok
> copysign - ok
> 
> encode - ok
> decode - ok
> 
> compares - ok
> iseqsig - ok
> 
> is754* - ok
> 
> fpclassify - ok
> signbit - ok
> isnormal - ok
> isfinite - ok
> iszero - ok
> issubnormal - ok
> isinf - ok
> isnan - ok
> issignaling - ok
> iscanonical - ok
> radix - ok
> totalorder - differ for NaN payloads (but not in change to Std C)
> totalordermag - differ for NaN payloads (but not in change to Std C)

I suppose this could be a CR for P1. Is a CR needed?

>  Do we need to change the above two to take pointers to floating types,
>  so as to not trigger signaling NaNs?

Good question. Seems like yes.
> 
> samequantum - ok;  Do we need to worry about signaling NaNs that trigger?

Yes, we need to say something else here. Is there any reason samequantum shouldn’t have the default behavior for signaling NaNs? Mike?

> 
> *flags - ok
> 
> ================
> 
> exp - ok
> expm1 - ok
> exp2 - ok
> exp2m1 - ok
> exp10 - ok
> exp10m1 - ok
> log - ok
> log2 - ok
> log10 - ok
> logp1 - ok
> log2p1 - ok
> log10p1 - ok
> hypot - ok
> rsqrt - ok
> compound - 
> cfp is missing:
>   754: compound(+/-0,n) is 1
>   754: compound(+inf,n) is +inf for n>0
>   754: compound(+inf,n) is +0 for n<0
>   754: compound(qNaN,n) is qNaN for n!=0
> rootn - 
> replace cfp rootn(+/-inf,n) with
>   754: rootn(+inf,n) is +inf for n>0
>   754: rootn(+inf,n) is +0 for n<0
>   754: rootn(-inf,n) is -inf for odd n>0
>   754: rootn(-inf,n) is -0 for odd n<0
>   754: rootn(-inf,n) is qNaN and "invalid" for even n>0
>   754: rootn(-inf,n) is qNaN and "invalid" for even n<0
> pown - 
> replace cfp pown(+/-inf,n) with
>   754: pown(+inf,n) is +inf for n>0
>   754: pown(+inf,n) is +0 for n<0
>   754: pown(-inf,n) is -inf for odd n>0
>   754: pown(-inf,n) is +inf for even n>0
>   754: pown(-inf,n) is -0 for odd n<0
>   754: pown(-inf,n) is +0 for even n<0
> pow - 
> 754: pow(+/-0,-inf) no exception
> cfp: pow(+/-0,-inf) may raise div-by-zero
> powr - 
> cfp is missing:
>   powr(x,qNaN) is qNaN for x>=0
>   powr(qNaN,y) is qNaN

Looks like we need to add some cases.

> sin - ok
> cos - ok
> tan - ok
> sinpi - ok
> cospi - ok
> tanpi - ok
> asin - ok
> acos - ok
> atan - ok
> atan2 - ok
> asinpi - ok
> acospi - ok
> atanpi - ok
> atan2pi - ok
> sinh - ok
> cosh - ok
> tanh - ok
> asinh - ok
> acosh - ok
> atanh - ok
> 
> *rounddir - ok
> *modes - ok
> 
> For the reduction functions, it appears to me that 754 requires
> intermediate computations to not overflow or underflow.  That
> contradicts [1] in 7.12.13b; but matches F.10.10b [2].
> 
> reducsum - 
> 754 has: A sum of infinities of different signs signals the invalid
>          operation exception.
> CFP has: returns a NaN and raises the "invalid" floating-point
>          exception if any two members of array p are infinities with
>          different signs.
> One reading of 754's requirement is the running sum and an array
> element are the two items in question.  So, sum([NaN, +inf, -inf],3)
> when process left to right would NOT raise invalid for 754, but must
> raise invalid for CFP.
> reducdot - same problem as reducsum.  Also, once a NaN is found, must
> the remaining vector items be done (which might raise invalid)?
> reducsumsq - ok
> reducsumabs - ok
> scaledprod - same issue as reducsum.
> scaledprodsum - same issue as reducsum.
> scaledproddiff - same issue as reducsum.

754 is still discussing these. We’ll need a review, and probably update, when 754 is finalized.

- Jim Thomas

> 
> augadd - ok
> augsub - ok
> augmul - ok
> 
> min - ok
> max - ok
> minNum - ok
> maxNum - ok
> minMag - ok
> maxMag - ok
> minMagNum - ok
> maxMagNum - ok
> 
> payload - ok
> 
> 
> ---
> Fred J. Tydeman        Tydeman Consulting
> 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
> Savers sleep well, investors eat well, spenders work forever.
> 
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest




More information about the Cfp-interest mailing list