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

Jim Thomas jaswthomas at sbcglobal.net
Thu Aug 23 15:34:22 PDT 2018 


> On Aug 16, 2018, at 12:19 PM, Jim Thomas <jaswthomas at sbcglobal.net> wrote:
> 
> 
> 
>> On Jul 26, 2018, at 3:59 PM, Fred J. Tydeman <tydeman at tybor.com <mailto: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.

Here’s a suggestion:

To F.10.10a (TS 18661-1), append the paragraph:

	[2] These functions treat zero and infinite arguments like the corresponding operation or function: +, -, *, /, fma, sqrt.

> 
>> 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.

I think a CR will be need for this one. Suggestion for the change:

In F.10.12.1 (TS 18661-1), change:

int totalorder(double x, double y);

to:

int totalorder(double * x, double * y);

and similarly for the other prototypes in F.10.12.1 and F.10.12.2.

In F.10.12.1 (TS 18661-1), change:

Description

[2] The totalorder functions determine whether the total order relationship, defined by IEC 60559, is true for the ordered pair of its arguments x, y. These functions are fully specified in IEC 60559. These functions are independent of the current rounding direction mode and raise no floating-point exceptions, even if an argument is a signaling NaN.

Returns

[3] The totalorder functions return nonzero if and only if the total order relation is true for the ordered pair of its arguments x, y.

to:

Description

[2] The totalorder functions determine whether the total order relationship, defined by IEC 60559, is true for the ordered pair *x, *y. These functions are fully specified in IEC 60559. These functions are independent of the current rounding direction mode and raise no floating-point exceptions, even if *x or *y is a signaling NaN.

Returns

[3] The totalorder functions return nonzero if and only if the total order relation is true for the ordered pair *x, *y.

and similarly for F.10.12.2.


>> 
>> 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?

Suggestion:

In 7.12.11a.2#2 (TS 18661-2), change the last sentence from:

The samequantumdN functions raise no floating-point exception.

to:

The samequantumdN functions raise no floating-point exception if neither argument is a signaling NaN.


> 
>> 
>> *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
I think cfp and 754 agree except for rootn(-inf, n) for even n > 0:

cfp says it’s the same as rootn(-0, n) for even n < 0 (without div-by-zero), which cfp and 754 both say is +inf.
754 says it's qNaN with invalid.

We can ask 754 to review/confirm this case. As usual, cfp needs to match 754. If cfp needs to change this case, it seems better to list out the cases for rootn(+/-inf, n) like 754 does, rather than relay on identity with rootn(+/-0, -n) 

>>  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
Aren’t cfp and 754 equivalent for pown?

>> pow - 
>> 754: pow(+/-0,-inf) no exception
>> cfp: pow(+/-0,-inf) may raise div-by-zero
We’ve already addressed the pow issue with a CR for C (N2271).

>> powr - 
>> cfp is missing:
>>  powr(x,qNaN) is qNaN for x>=0
>>  powr(qNaN,y) is qNaN
Why does 754 state these cases? They’re covered by its general specification for NaNs in 9.2. 

- Jim Thomas

> 
> 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
> 
> 
> _______________________________________________
> 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/20180823/2ee2930e/attachment-0001.html

More information about the Cfp-interest mailing list