[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