<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 2, 2024, at 5:25 PM, Damian McGuckin <damianm@esi.com.au> wrote:</div><br class="Apple-interchange-newline"><div><div><br>Jim, I am reformatting this email a bit because it is hard to see who said what. I was chasing consistency.<br><br><blockquote type="cite">On Sat, 16 Mar 2024, Damian McGuckin wrote:<br>The special case is mentioned:<br><br> csinh(x + i * INFINITY) returns NaN + i * NaN for positive<br> finite x<br>is given.<br>Given the mathematics, I think the domain in the draft is wrong and<br>should have read 'finite non-zero x'<br></blockquote><br>On Tue, 2 Apr 2024, Jim Thomas wrote:<br><br><blockquote type="cite">The domain is implicitly extended to cover finite nonzero x by the<br>requirements in the first bullet:<br><br> ?csinh(conj(z)) = conj(csinh(z)) and csinh is odd.<br></blockquote><br>Yes (but no from a consistency perspective)<br><br>I agree that:<br><br>The 1st item in that line says that whatever is good for +y is good for -y.<br></div></div></blockquote><div><br></div>It says if csinh(x + iy) is u + iv, then csin(x - iy) is u - iv.</div><div><br><blockquote type="cite"><div><div><br>The 2nd item in that line says that whatever is good for +x is good for -x.<br></div></div></blockquote><div><br></div>It says casinh(-z) is -csinh(z).<br><div><br></div><blockquote type="cite"><div><div><br>But exploiting that second fact is an extremely inconsistent extrapolation because no other bullet point for any special case in all Annex G exploits the odd-ness or even-ness of the function in the description of a domain as far as I can see.<br></div></div></blockquote><div><br></div>Not true. Conjugate and odd and even properties are used to extend definitions particularly involving 0 and infinity components. This avoids extra bullets for cases where x or y are -0 or -inf. For example, from the second bullet</div><div><br></div><div><span class="Apple-tab-span" style="white-space:pre"> </span>csinh(+0 + i0) returns +0 + i0.</div><div><br></div><div>it follow from the first bullet (conjuge and odd) that</div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div>csinh(+0 - i0) returns +0 - i0</div><div>csinh(-0 - i0) returns -0 - i0</div><div>csinh(-0 + i0) returns -0 + i0</div></blockquote><div><br></div><div>For the bullet in question </div><div><br></div><div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>csinh(x + i inf) returns NaN + iNaN … for positive finite x<br></div><div><br></div></div><div>it follows from the first bullet (and the fact that -NaN and NaN refer to the same value) that</div><div><br></div><div><div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>csinh(x - i inf) returns NaN + iNaN … for positive finite x<br></div><div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>csinh(x - i inf) returns NaN + iNaN … for negative finite x<br></div></div><div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>csinh(x + i inf) returns NaN + iNaN … for negative finite x<br></div></div><div><br></div><div>Just changing “postitive finite x" to "finite non-zero x” would still need the first bullet to infer a definition for x - i inf. </div><div><br></div></div></div><div><blockquote type="cite"><div><div><br>I was chasing consistency in this description.<br><br>I also said (but I hit the 'x' key twice - sorry)<br><br><blockquote type="cite"> As the special case in<br><br> a) the 6th bullet point says 'finite non-zero x?,<br></blockquote><br>The 6th bullet point does not exploit the odd'ness of the function when it describes the doamin, so why should the 5th bullet point.<br></div></div></blockquote><div><br></div>The 6th bullet could be written to not depend on the first bullet because -NaN is NaN.</div><div><br></div><div>- Jim Thomas</div><div><br><blockquote type="cite"><div><div><br>Also, in G.6.3.6 ctanh(), the 4th and 6th bullet points do not exploit the odd'ness of the function when the domain is described either.<br><br>The description as it stands in the 5th bullet point is an outlier<br><br>For consistency with both bullet point 6 in csinh(), and again in tanh() and elsewhere such as ccosh(), we need<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>finite non-zero<br><br>in bullet point 5.<br><br>Ignore my comment about overlap. Changing to 'finite non-zero' covers it.<br><br>I also belated note that ccosh() and csinh() uses the following ordering<br>for the special cases for the 3rd through 6th special cases"<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>0 + i INF<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>0 + i NAN<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>x + i INF<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>x + i NAN<br><br>and yet ctanh() shuffles these cases around and inconsistently uses<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>0 + i INF<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>x + i INF<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>0 + i NAN<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>x + i NAN<br><br>which is confusing. It should be rearranged.<br><br>You also noted that:<br><br><blockquote type="cite">(n3219 has an erroneous periodic the middle of the first bullet. That typo has been reported to the C editor.)<br></blockquote><br>Yes. Sorry. I missed that.<br><br>Thanks - Damian</div></div></blockquote></div><br></body></html>