Document: WG14 N1499

Remove error/no error choices in math functions


Submitter: Fred J. Tydeman (USA)
Submission Date: 2010-06-17
Subject: Remove error/no error choices in math functions

Currently, several of the math library functions allow implementations too much choice as when to indicate errors. That is, one implementation may indicate an error, while another implementation may indicate no error for the same function call, e.g., atanh(1.0). This makes writing portable applications difficult.

There are two proposals here. They are independent of each other. They should each have their own vote. As written, these two proposals have no impact on current implementations. They are giving guidance and future directions.

On the other hand, if we decide to make these changes normative now, then change proposal 1 "should" to "shall" and remove the "Recommended Practice".

Proposal 1: add recommended practices.

7.12.4.4 The atan2 functions

Recommended Practice

atan2(zero,zero) should not be a domain error.

7.12.5.3 The atanh functions

Recommended Practice

atanh(+/-1.0) should be a pole error

7.12.6.5 The ilogb functions

Recommended Practice

ilogb(zero) should be a domain error. ilogb(infinity) should be a domain error. ilogb(NaN) should be domain error.

7.12.6.7 The log functions

Recommended Practice

log(zero) should be a pole error.

7.12.6.8 The log10 functions

Recommended Practice

log10(zero) should be a pole error.

7.12.6.9 The log1p functions

Recommended Practice

log1p(-1.0) should be a pole error.

7.12.6.10 The log2 functions

Recommended Practice

log2(zero) should be a pole error.

7.12.6.11 The logb functions

Recommended Practice

logb(zero) should be a pole error.

7.12.7.4 The pow functions

Recommended Practice

pow(zero,zero) should not be a domain error. pow(zero,less than zero) should be a pole error.

7.12.8.3 The lgamma functions

Recommended Practice

lgamma(zero) should be a pole error. lgamma(negative integer) should be a pole error.

7.12.8.4 The tgamma functions

Recommended Practice

tgamma(zero) should be a pole error. tgamma(negative integer) should be a domain error.

7.12.9.5 The lrint and llrint functions

Recommended Practice

lrint(too large) should be a domain error. llrint(too large) should be a domain error.

7.12.9.7 The lround and llround functions

Recommended Practice

lround(too large) should be a domain error. llround(too large) should be a domain error.

7.12.10.1 The fmod functions

Recommended Practice

If y is zero and x is not a NaN, fmod(x,y) should be a domain error.

7.12.10.2 The remainder functions

Recommended Practice

If y is zero and x is not a NaN, remainder(x,y) should be a domain error.

7.12.10.3 The remquo functions

Recommended Practice

If y is zero and x is not a NaN, remquo(x,y,quo) should be a domain error.

7.12.11.3 The nextafter functions

Recommended Practice

nextafter(+largest finite,+infinite) should be a range error. nextafter(-largest finite,-infinite) should be a range error.

7.12.11.4 The nexttoward functions

Recommended Practice

nexttoward(+largest finite,larger finite or infinite) should be a range error. nexttoward(-largest finite,-(larger finite or infinite)) should be a range error.

Proposal 2: add obsolescent features.

Add a new section to 7.29 Future library directions: 7.29.N Math <math.h:>

The following error conditions are obsolescent features.

Add the following to the Rationale for <math.h>:

For the same function call, having one implementation indicate an error and another implementation indicate no error makes it difficult to write portable application code. An example of this is: atanh(1.0); where one implementation calls it a pole error, while another implementation indicates no error. This ambiguity may be removed in a future revision of the standard.