[Cfp-interest] (SC22WG14.15443) Augmented operations specification (N2274)

[Jim Thomas]

Below is a message to WG14 from Joseph Myers and my suggested responses (which I have not sent to WG14 yet). N2274 is CFP’s draft specification for C support for the 754 augmented operations.

David and Mike, note that the first three items are possible issues for 754. 

- Jim Thomas

> On Jul 25, 2018, at 8:23 AM, Joseph Myers <joseph at codesourcery.com> wrote:
> 
> There seem to be some places where the augmented operations specification 
> in N2274 is either under-specified, or inconsistent with the proposed 
> operations in draft IEEE 754-2018.
> 
> * For addition and subtraction, N2274 says "These functions raise 
> floating-point exceptions like the computation of h, except that they 
> raise the “inexact” floating-point exception only when the computation of 
> h overflows.".  But 754 draft 2.40 says "This operation never signals 
> underflow; its subnormal and zero results are exact.”.  

> For the case of 
> exact subnormal h, with the FENV_EXCEPT pragma from TS 18661-5 used to 
> change the handling of exact underflow, what are the results?  Under 754 
> draft 2.40 it's clear that the exact subnormal result is returned, no 
> exception occurs and so alternate exception handling results in no 
> difference to the results.  But N2274 would seem to suggest that the exact 
> underflow in h would be affected by alternate exception handling.

754 addition and subtraction to do not signal underflow for exact underflow cases, but multiplication does (see comment about multiplication below). Is that intentional? Once this is clarified, N2274 should be changed (if necessary) to match. If underflow is not to be signaled, change N2274 (for addition and subtraction) to "except that they raise the “inexact” floating-point exception only when the computation of h overflows and they never raise the “underflow” floating-point exception."

> 
> * If the high part of the result for any of these functions is nonzero, 
> but the low part is an exact zero, what sign does that low part have?  
> There are references to, for example, x+y-h which is exactly 
> representable.  But this doesn't say what rounding mode is used to 
> evaluate the exact zero x+y-h.  Is it roundTiesToZero, thus always 
> resulting in +0 for the low part in such cases because of roundTiesToZero 
> being covered by the wording for exact zero signs for all modes that 
> aren't roundTowardNegative?  (I don't see anything to specify this sign of 
> an exact zero low part with nonzero high part in either N2274 or 
> P754-240.)

Agree. This case isn’t covered by 754 or N2274.

> 
> * What about exact underflow for multiplication.  Does it ever signal the 
> exception with alternate exception handling consequences?  N2274 appears 
> to say it occurs when exact underflow occurs for the low part.  P754-240 
> appears to suggest, by omission, that it does not occur, because the only 
> conditions it describes for underflow are when the low part is inexact.

My reading of 754 is that exact underflow for multiplication does signal underflow. It says "This operationʼs exceptional behavior is the same as multiplication (see 5.4.1) using roundTiesToZero, with the following additional specifications.” The additional specifications don’t say underflow is not signaled. 

> 
> * For multiplication, N2274 says "A domain error occurs when the 
> computation of h is invalid.".  That's fine when it's invalid because it's 
> 0*Inf.  But what about if it's sNaN*anything?  TS 18661-1 says "Whether a 
> signaling NaN input causes a domain error is implementation-defined.".  I 
> don't think N2274 should add further requirements for these functions, 
> unlike all others, to have a domain error for sNaN inputs (i.e., a new 
> requirement to set errno for sNaN inputs if math_errhandling & MATH_ERRNO 
> is nonzero).


Agree. N2274 change needed. Change to "A domain error occurs for one infinite argument and one zero argument.” 


> 
> -- 
> Joseph S. Myers
> joseph at codesourcery.com