[Cfp-interest 3016] Re: about C26 Issue 1

Sun Mar 3 10:10:34 PST 2024

Hi, I agreed to look into this "easy" issue on the 7 Feb 2024 call. Fred
reported the issue and Jim provided significant background below.

A refinement of the description of exceptional cases in gamma and log gamma
foliates into a tangle of issues tracing back to language in 754. Here are
minimal changes intended to improve reader understanding.

Proposal 1 -- IEEE 754/IEC 60559 sect. 9.2, included here in CFP as
background for the C proposals that follow.
Current:

divideByZero: An operation that has a simple pole for some finite
floating-point operand shall signal the divideByZero exception and return
an infinity by default.

Proposed:

divideByZero: An operation that has a singularity for some finite
floating-point operand, where the mathematical result tends to infinity,
shall signal the divideByZero exception and return an infinity by default.

Proposal 2 -- C sect 7.12.1 para 3
Current:

Similarly, a pole error (also known as a singularity or infinitary) occurs
if and only if the mathematical function has an exact infinite result as
the finite input argument(s) are approached in the limit (for example,
log(0.0)). The description of each function lists any required pole errors;
an implementation may define additional pole errors, provided that such
errors are consistent with the mathematical definition of the function. On
a pole error, the function returns an implementation-defined value; if the
integer expression math_errhandling & MATH_ERRNO is nonzero, the integer
expression errno acquires the value ERANGE; if the integer expression
math_errhandling & MATH_ERREXCEPT is nonzero, the "divide-by-zero"
floating-point exception is raised.

Proposed:

Similarly, a singularity error occurs if and only if the mathematical
function tends to infinity as the finite input argument(s) are approached
in the limit (for example, log(0.0)). The description of each function
lists any required singularity errors; an implementation may define
additional singularity errors, provided that such errors are consistent
with the mathematical definition of the function. On a singularity error,
the function returns an implementation-defined value; if the integer
expression math_errhandling & MATH_ERRNO is nonzero, the integer expression
errno acquires the value ERANGE; if the integer expression math_errhandling
& MATH_ERREXCEPT is nonzero, the "divide-by-zero" floating-point exception
is raised.

Proposal 3 -- C sect 7.12.x, Change 25 instances
Current:

pole error

Proposed:

singularity error

Proposal 4 -- C sect 1.12.8.3 para 2 on log gamma
Current:

A pole error may occur if x is a negative integer or zero.

Proposed:

A domain error or singularity error may occur if x is a negative integer or
zero.

Proposal 5 -- C sect 1.12.8.4 para 2 on log gamma
Current:

A domain error or a pole error may occur if x is a negative integer or zero.

Proposed:

A domain error or singularity error may occur if x is a negative integer or
zero.

DISCUSSION -- item by item

Proposal 1 -- The use of "pole" in 754-2019 is not best. Refer to the
Mathematical Discussion below for some elaboration on singularities. Given
the decades of "divide-by-zero" exceptions behind us, why fuss about the
name, even if some cases are not, strictly speaking, divide by zero?

Proposals 2 & 3 -- The current C usage "exact infinite result" seems to
descend from the language of the real numbers augmented by signed infinity.
The "exact" may suggest a distinction from overflow to infinity, where a
result is finite but too large to represent (and the Inexact exception is
raised).

BONUS ITEM: 7.2.1 para 1 talks about "domain error". Whose domain? There
are two functions at play here, the mathematical function defined over the
real numbers, and the computer function, defined over a finite set enhanced
with signed zero and signed infinity. This is a topic of its own.

Proposals 4 & 5 -- The domain vs. singularity error matter appears in item
(2) just above. Jim calls out that zero is in the domain of gamma() in IEEE
arithmetic, because the sign of zero determines the sign of the resulting
infinity. This language will change if the special cases from annex section
F.10 are brought into the body of the standard.

MATHEMATICAL DISCUSSION -- singularities in 3 flavors

Briefly, the language of the exceptions in this note pertains to the
complex domain. An "isolated singularity" x of f() is value for which f()
is analytic in a punctured disc around x, but excluding x. An isolated
singularity may take exactly one of three forms:

   1. Removable singularity – a case such as  f(x) = sin(x)/x, which can be
   defined as 1.0 at x=0, resulting in a function analytic at the removable
   singularity.

   2. Pole – a case such as f(x) = 1/x, which tends to infinity at x but
   and for which f(x)*p(x) is bounded, for a polynomial p() of sufficient
   degree (the "order" of the pole). If the degree of p() is one, it's a
   "simple pole". (This is the source of the "simple pole" language in 754.)

   3. Essential singularity – a case such as f(x) = log(x) at zero, which
   cannot be bounded by any polynomial, and remarkably takes every complex
   value arbitrarily close to x, depending on the direction of approach.

The simple observation is that not all singularities encountered in the
math library are poles. It's inelegant to bend the term "pole" rather than
use a mathematically correct term like "singularity". I have initiated
discussion of a possible change to 754, but C can use robust terminology
independent of 754.

-Jerome Coonen
 650.996.4738
 jcoonen at gmail.com

On Tue, Feb 6, 2024 at 2:51 PM Jim Thomas <jaswthomas at sbcglobal.net> wrote:

> Some followup, including suggestion for how to proceed ...
>
> On Feb 5, 2024, at 9:49 AM, Jim Thomas <jaswthomas at sbcglobal.net> wrote:
>
> Some thoughts related to Issue 1 in
> https://wiki.edg.com/pub/CFP/WebHome/C26C.HTM ...
>
> Back to the definitions of errors. 7.12.1 says:
>
> … a domain error occurs if and only if an input argument is outside the
> domain over which the mathematical function is defined.
>
>
> and
>
> … a pole error (also known as a singularity or infinitary) occurs if and
> only if the mathematical function has an exact infinite result as the
> finite input argument(s) are approached in the limit (for example,
> *log(0.0)*).
>
>
> Domain and pole errors are defined in terms of mathematical functions. The
> pole error definition obscures this fact by referring to “an exact infinite
> result”, though “exact” isn’t applicable to mathematical function results.
> (Note that  *log(0.0)* is in program font, which is appropriate: a pole
> error occurs for the execution of *log(0.0)* because the mathematical
> function log(x) has a pole at 0.)
>
>
> Does the mathematical function’s range include an infinity? The domain
> error definition doesn’t say, but if an infinity were not included, a
> domain error would occur for *log(0.0)*. The pole error definition
> implies the mathematical function’s range does include an infinity, and the
> parenthetical example says a pole error occurs for *log(0.0)*.
>
> I think the mathematical functions should have the range of the extended
> real numbers, i.e. of the real numbers together with infinity. Then poles
> are at points within the domain, and *log(0.0)* causes a pole error and
> not a domain error, as I believe is the general understanding.
>
>
> 1a Suggest we review these definitions with an eye toward rewording them
> to clarify that the mathematical functions include infinity.
>
> For the pole error definition, maybe “… if and only if the mathematical
> function has an infinite value where a finite argument *) is approached in
> the limit.” where the footnote is:
>
> *) For a function of n variables "a finite argument" is intended to mean
> an n-tuple of finite arguments.
>
>
> Unlike domain and pole errors, range errors are defined in terms of
> implementation limitations. This seems right, because range errors are
> about limitations of the approximation, not about the mathematical function.
>
> For some math library functions, it’s may not be clear what the
> mathematical function is, e.g. *atan2*, and *logb*. For *pow* the
> mathematical function might appear to be x^y but IEC 60559 defines *pow*
> for some cases where x^y is undefined, e.g. *pow(*0*,* 0*)* = 1, thus the
> mathematical function corresponding to *pow* is a piecewise function.
>
>
> 1b Suggest we consider how to clarify what is meant by "the mathematical
> function".
>
>
> 7.12.1 says “The description of each function lists any required
> domain/pole/range errors”. I think CFP agreed that this means these are the
> errors that are required to be reported (via errno or exceptions),
>
>
> Not quite right. Underflow range errors are not required to be reported.
> For underflow, a required range error would mean one where whether it is
> reported is implementation defined.
> .
>
> but his meaning is not clear in the standard. We should consider proposing
> a clarification.
>
>
> 1c Suggest we consider how to clarify what is meant by "required error".
>
>
> 7.12.1 says the implementation is free to report domain/pole/range errors
> in other cases, provided the definition of the error fits. Given this, what
> is the intended meaning of, “a domain/pole/range error may occur” in a
> function description? It might just note a case that fits the definition of
> the error for which the implementation may (but is not required to) report
> the error. Or it might mean the definition fits for some implementations
> but not for others. Or it might mean that the implementation can determine
> whether the definition fits.
>
>
> 1d Suggest we review function by function (including *tgamma* and *lgamma*)
> what “error may occur” is intended to mean. Then consider how to clarify
> what “error may occur” means (or use other words).
>
>
> An error can't be required unless IEC 60559 allows a corresponding
> floating-point exception. For example, a non-IEC 60559 implementation might
> regard *atan2(0, 0)* to be a domain error. However, IEC 60559 defines the
> result and does not allow an “invalid” floating-point exception in this
> case. Thus, IEC 60559 implementations can not be allowed to report *atan2(0,
> 0)* as a domain error.
>
>
> I meant “ … can not be required to report …”. This is just a reminder of
> the constraint on the specification.
>
> The handing of overflow is different for errno and exceptions. Was that a
> legacy case?
>
> - Jim Thomas
>
>
> These are not “easy” issues.
>
> I suggest CFP defer discussion of Issue 1, and first clarify the broader
> issues.
>
> - Jim Thomas
>
>
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20240303/ed9a55ca/attachment-0001.htm>