<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;"><br><div><br><blockquote type="cite"><div>On Apr 10, 2024, at 10:26 PM, Damian McGuckin <damianm@esi.com.au> wrote:</div><br class="Apple-interchange-newline"><div><div><br>I am reworking these two Annexes. Most of the changes I will suggest apply to the special cases and how they are written/described with a view to<br>making them more clear.<br><br>This can be regarded as a summary of emails over the last few weeks.<br><br>Special Cases are handled inconsistently both between Annex F and Annex G, and within Annex F itself (sometimes), and Annex G itself (often). That<br>inconsistency makes these sections difficult reading.<br><br>I will note what I perceive as the problem, and then follow that text by a suggested solution marked '->'<br><br>In the following discussion. I will use INF to imply +INFINITY<br></div></div></blockquote><div><br></div><b>INFINITY</b> is a C macro. Unless specifically involving the macro, mathematical expressions are better expressed with a mathematical infinity symbol (else “infinite” or “inf" in ordinary font). <br><blockquote type="cite"><div><div><br>In G.6.1, Clause 10 introduces the 'cis(y)' function, Euler's formula. Because the existing 'cexp' function from the C standard itself with a purely imaginary argument provides the same mathematics, I suggest we<br>use that instead.<br><br>-> the use of 'cis(y)' will be replaced by 'cexp(iy)'.<br></div></div></blockquote><div><br></div>cis() is a mathematical function. <b>cexp()</b> is a C library function. They are not interchangeable.<br><blockquote type="cite"><div><div><br>Annex F uses a mathematical relationship such as 0 < x < INF to qualify the<br>domain of a function's argument for which a special case holds. On the other<br>hand, Annex G uses mathematical words like positive finite 'x' for the same<br>domain, wording which is less succinct and is sometimes inconsistently used<br><br>-> Mathematical relationships are now used to qualify domains for special cases<br><br>Mention of whether or not a floating-point exception is raised for a special<br>case currently appears after the result but before the domain qualification<br>inequality or words. In such clauses, I would suggest that<br><br>* the domain is the most important part of the qualification but it gets<br> lost visually in the words talking about the floating-point exception,<br><br>* the domain is no longer seen in roughly the same location on a line<br> compared to other clauses where no exception is raised.<br><br>-> Any floating-point exception now appears AFTER the domain qualification.<br><br>Note that the approaches of mathematical relationships (inequalities mostly) and ensuring the domain qualification immediately follows the result make<br><br>* a domain qualification, clear, far more obvious, and more readable;<br><br>* it easier to check these domains for accuracy and consistency.<br><br>For some special cases, the domain qualification 'runs on' immediately after<br>the complex 'number' which is result, i.e.<br><br><span class="Apple-tab-span" style="white-space:pre"> </span><function> ( <argument> ) returns <result> for +0 < y < INF<br><br>Elsewhere, a comma separates the two:<br><br><span class="Apple-tab-span" style="white-space:pre"> </span><function> <argument> ) returns <result> , for +0 < y < INF<br><br>The former is consistent with most of Annex F and is hence the chosen style.<br><br>-> No comma now appears before the domain qualification for a special case<br><br>Given a pair of functions 'cf()' and its inverse 'caf()', e.g. ccosh() and<br>cacosh(), where both accept a complex argument and return a complex result,<br>if<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>cf ( NaN + i 0 ) = NaN + i 0 .........(1)<br><br>and does not raise a floating-point exception, then, by definition, the inverse<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>caf ( NaN + i 0 ) = NaN + i 0 .........(2)<br></div></div></blockquote><div><br></div><div>The inverse property only applies for restricted domains where both functions are one-to-one. sqr(-1) = 1 doesn’t mean sqrt(1) = -1.</div><blockquote type="cite"><div><div><br>and by assumption, it too does not raise a floating-point exception.<br><br>Annex G forgot this mathematical definition and returns NaN + i NaN for<br>both 'cacosh' and 'catanh'. It also chose to raise the floating-point<br>exception for these cases which is inconsistent.<br><br>-> A 'NaN + i 0' argument will be correctly and consistently handled<br></div></div></blockquote><div><br></div><div>The mathematical functions can be defined by cosh(z) = (e^z + e^(-z))/2 and acosh(z) = log(z + sqrt(z+1)*sqrt(z-1)).</div><div><br></div><div>cosh(x + i0) has imaginary component +0i for any number x. Thus it’s appropriate to define <b>ccosh(</b>NaN + i0<b>)</b> to be NaN + i0. On the other hand, acosh(x + iy) has a branch cut along the x axis for x < 1, and there acosh(x + 0i) does not have a +0i or any other invariant imaginary component. So <b>cacosh(</b>NaN + 0i<b>)</b> must return NaN + iNaN.</div><div><br></div><blockquote type="cite"><div><div><br>The above scenario also happens for an argument of '+0 + i NAN' passed<br>to 'casinh'. The same solution applies.<br><br>-> A '0 + i NaN' argument will be correctly and consistently handled<br><br>For functions which satisfy:<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>f(conj(z)) = conj(f(z))<br><br>Annex G says it only provides special case specifications for such functions<br>in the upper half of the complex half-plane because any cases in the lower<br>half of the complex half-plane are implied by that conjugate rule. </div></div></blockquote><div><br></div>No, it doesn’t say it only provides specification in the upper half-plane. It says "the specifications for the upper half plane imply the specifications in the lower half-plane.” With this understanding, the conjugate rule can be used selectively where it seems to result in a better (easier to understand) spec. </div><div><br></div><div>- Jim Thomas</div><div><br><blockquote type="cite"><div><div>Not all<br>special cases are consistent with this approach.<br><br>-> Complex half plane special cases are now handled consistently<br><br>If anybody has any comments, suggestions or objections to those '->' approaches, please let me know.<br><br>I will post the changes subsequently after a bit more QA on the extensive list by Jerome and Jim.<br><br>Thanks - Damian<br>_______________________________________________<br>Cfp-interest mailing list<br>Cfp-interest@oakapple.net<br>http://mailman.oakapple.net/mailman/listinfo/cfp-interest<br></div></div></blockquote></div><br></body></html>