<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Some followup, including suggestion for how to proceed ...<br><div><br><blockquote type="cite"><div>On Feb 5, 2024, at 9:49 AM, Jim Thomas <jaswthomas@sbcglobal.net> wrote:</div><br class="Apple-interchange-newline"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">Some thoughts related to Issue 1 in <a href="https://wiki.edg.com/pub/CFP/WebHome/C26C.HTM">https://wiki.edg.com/pub/CFP/WebHome/C26C.HTM</a> ...<div><div><br></div><div>Back to the definitions of errors. 7.12.1 says:</div></div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div>… a domain error occurs if and only if an input argument is outside the domain over which the mathematical function is defined. </div></div></blockquote><div><div><br></div><div>and </div><div><br></div></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><div>… 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, <b>log(0.0)</b>).</div></div></blockquote><div><div><br></div><div>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 <b>log(0.0)</b> is in program font, which is appropriate: a pole error occurs for the execution of <b>log(0.0)</b> because the mathematical function log(x) has a pole at 0.)</div></div></div></div></blockquote><blockquote type="cite"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><div><br></div><div>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 <b>log(0.0)</b>. The pole error definition implies the mathematical function’s range does include an infinity, and the parenthetical example says a pole error occurs for <b>log(0.0)</b>. </div><div><br></div><div>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 <b>log(0.0)</b> causes a pole error and not a domain error, as I believe is the general understanding.</div></div></div></div></blockquote><div><br></div>1a Suggest we review these definitions with an eye toward rewording them to clarify that the mathematical functions include infinity. </div><div><br></div><div>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:</div><div><br></div><div>*) For a function of n variables "a finite argument" is intended to mean an n-tuple of finite arguments.</div><div><br></div><div><blockquote type="cite"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><div><br></div><div>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.</div><div><br></div><div>For some math library functions, it’s may not be clear what the mathematical function is, e.g. <b>atan2</b>, and <b>logb</b>. For <b>pow</b> the mathematical function might appear to be x^y but IEC 60559 defines <b>pow</b> for some cases where x^y is undefined, e.g. <b>pow(</b>0<b>,</b> 0<b>)</b> = 1, thus the mathematical function corresponding to <b>pow</b> is a piecewise function. </div></div></div></div></blockquote><div><br></div>1b Suggest we consider how to clarify what is meant by "the mathematical function".</div><div><br><blockquote type="cite"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><div><br></div><div>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), </div></div></div></div></blockquote><div><br></div>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.</div><div>.<br><blockquote type="cite"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><div>but his meaning is not clear in the standard. We should consider proposing a clarification.</div></div></div></div></blockquote><div><br></div>1c Suggest we consider how to clarify what is meant by "required error".<br><blockquote type="cite"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><div><br></div><div>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. </div></div></div></div></blockquote><div><br></div>1d Suggest we review function by function (including <b>tgamma</b> and <b>lgamma</b>) what “error may occur” is intended to mean. Then consider how to clarify what “error may occur” means (or use other words).</div><div><br></div><div><blockquote type="cite"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><div><br></div><div>An error can't be required unless IEC 60559 allows a corresponding floating-point exception. For example, a non-IEC 60559 implementation might regard <b>atan2(0, 0)</b> 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 <b>atan2(0, 0)</b> as a domain error. </div></div></div></div></blockquote><div><br></div>I meant “ … can not be required to report …”. This is just a reminder of the constraint on the specification.</div><div><br></div><div>The handing of overflow is different for errno and exceptions. Was that a legacy case?</div><div><br></div><div>- Jim Thomas</div><div><br><blockquote type="cite"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><div><br></div><div>These are not “easy” issues.</div><div><br></div><div>I suggest CFP defer discussion of Issue 1, and first clarify the broader issues.</div></div><div><br></div><div>- Jim Thomas</div><div><br></div></div></div></blockquote></div><br></body></html>