[cfp-interest 3564] Re: C23 possible defect: output bounds of imprecise math functions

[Jim Thomas]

Paul Zimmermann pointed out that correctly rounded library functions might yield a result that is outside the range of the corresponding mathematical function in cases where the range is an interval with an endpoint that is not representable in the format. However, specification of some functions in C 7.12 state that the function returns a value in such an interval. For example, 7.12.5.2 says

---------
Description
2 The asin functions compute the principal value of the arc sine of x. A domain error occurs for arguments not in the interval [−1, +1]. A range error occurs if nonzero x is too close to zero.
Returns
3 The asin functions return arcsin x in the interval [−π/2, +π/2] radians.
---------

Should C require its library function results to be in the range of the corresponding mathematical function when a correctly rounded result might not be?

As noted in previous email, regarding the similar situation for its atan operation, ISO/IEC 60559 9.2.1 says

---------
For some formats under some rounding attributes the rounded magnitude range of atan (atan2) might exceed the unrounded magnitude of π/2 (π). A programmer must then take care to properly handle any anomalous manifold jump that might occur under the inverse operation.
---------

Thus, ISO/IEC 60559 prioritizes correct rounding over range bounds. I’m not aware of any place that ISO/IEC 60559 makes an exception to correct rounding for its floating-point operations to preserve a property of the corresponding mathematical operation.

The following rewrite of the asin specification above exemplifies a way to remove the range bound requirement:

---------
Description
2 The asin functions compute the principal value of the arc sine of x, which is in the interval [−π/2, +π/2] radians. A domain error occurs for arguments not in the interval [−1, +1]. A range error occurs if nonzero x is too close to zero.
Returns
3 The asin functions return the principal value of arcsin x.
---------

A similar change can be made in the other relevant subclauses:

7.12.5.1 The acos functions
7.12.5.3 The atan functions
7.12.5.4 The atan2 functions


- Jim Thomas



> On Aug 9, 2025, at 4:18 PM, Jim Thomas <jaswthomas at sbcglobal.net> wrote:
> 
> The issue for CFP is what to do about C specification that might be inconsistent with correct rounding, like 7.12.5.2 #3:
> 
> The asin functions return arcsin x in the interval [−pi/2, +pi/2] radians.
> 
> I think the purpose of the range qualification should be to identify the primary branch of the multivalued mathematical function, not to strictly bound the range of the library function.
> 
> - Jim Thomas
> 
> 
>> On Aug 9, 2025, at 3:39 PM, Jim Thomas <jaswthomas at sbcglobal.net> wrote:
>> 
>> Paul,
>> 
>> Thanks for the correction!
>> 
>> Note that ISO/IEC 60559 9.2.1 says
>> 
>> For some formats under some rounding attributes the rounded magnitude range of atan (atan2) might exceed the unrounded magnitude of π/2 (π). A programmer must then take care to properly handle any anomalous manifold jump that might occur under the inverse operation.
>> 
>> prioritizing correct rounding over range bounds. I’m not aware of any place that ISO/IEC 60559 makes an exception to correct rounding for its floating-point operation to preserve a property of the corresponding mathematical operation. 
>> 
>> - Jim
>> 
>> 
>>> On Jul 18, 2025, at 11:36 PM, Paul Zimmermann <Paul.Zimmermann at inria.fr> wrote:
>>> 
>>>> Correctly rounded functions, e.g. sqrt(x) per Annex F, won’t return out-of-range values. C reserves cr_ prefixed names for correctly rounded math functions.
>>> 
>>> however correct rounding is not always compatible with range constraints,
>>> see the example in section 6.4 from https://dl.acm.org/doi/pdf/10.1145/3747840.
>>> 
>>> Maybe the CFP group might decide what to do in that case.
>>> 
>>> Paul
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20250815/a55a4bd9/attachment.htm>