<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 id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Sep 11, 2024, at 3:00 PM, 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;"><br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Sep 7, 2024, at 11:45 PM, Damian McGuckin <damianm@esi.com.au> wrote:</div><br class="Apple-interchange-newline"><div><div><br>I agree 100% that such words need to be said.<br><br>So I took the words from around those locations and then merged the new words into a document and the new words look totally out of place. And<br>they overly complicate 6.2.5 and 6.5.6 and 6.5.7.<br></div></div></blockquote><div><br></div>I agree some of the suggested changes don’t fit and will make some changes.</div></div></div></blockquote><div><br></div><div>I wasn’t able to find a better place for the operator specification proposed in [Cfp-interest 3262], which I suggest we review as is.</div><div><br></div><div>Note that t<span style="font-size: 10pt; font-family: Cambria, serif;">he definitions for “complex </span><b style="font-family: Calibri, sans-serif;"><span style="font-size: 10pt; font-family: "Courier New";">*</span></b><span style="font-size: 10pt; font-family: Cambria, serif;"> complex”, “complex </span><b style="font-family: Calibri, sans-serif;"><span style="font-size: 10pt; font-family: "Courier New";">/</span></b><span style="font-size: 10pt; font-family: Cambria, serif;"> complex”, and “real </span><b style="font-family: Calibri, sans-serif;"><span style="font-size: 10pt; font-family: "Courier New";">/</span></b><font face="Cambria, serif" size="2"> complex” could be removed and perhaps considered as a separate proposal.</font></div><div><font face="Cambria, serif" size="2"><br></font></div><div><font face="Cambria, serif" size="2">- Jim Thomas</font></div><p class="MsoNormal" style="margin: 0in; font-size: medium; font-family: Calibri, sans-serif;"><span style="font-size: 10pt; font-family: Cambria, serif;"><o:p></o:p></span></p><div><br></div><blockquote type="cite"><div><div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div><br><blockquote type="cite"><div><div><br>I believe this sort of stuff needs to stay in Annex G. That way people who have no need to think about complex types do not have to be confused.<br></div></div></blockquote><div><br></div>Complex arithmetic is an optional feature of C, though it is specified in the main body of C (including the <complex.h> library). Annex G extends this specification for implementations that support ISO/IEC 60559 via Annex F. A conforming C implementation can deal with complex in three ways:</div><div><br></div><div>1. Not support complex at all.</div><div><br></div><div>2. Support complex as specified in the main body of the standard (excluding Annex G).</div><div><br></div><div>3. Support complex as specified in the main body of the standard extended by Annexes F and G.</div><div><br></div><div>The point of the proposal (as I understand was requested by WG14) is to move specification that does not depend on ISO/IEC 60559 out of Annex G into the main body of C.</div><div><br><blockquote type="cite"><div><div><br>That said, the concept of a "complex infinity" is referenced in 7.3.9.5 but not defined until G.2. </div></div></blockquote><div><br></div>Good point.</div><div><br><blockquote type="cite"><div><div>I would suggest that G.2 be moved into the start 7.3, i.e. 7.3.1.<br></div></div></blockquote><div><br></div></div><div>Implementations that don’t support ISO/IEC 60559 via Annexes F and G might have other ideas about what a complex infinity should be. I think it would be better to avoid referring to a complex value as an infinity outside of Annex G. Fortunately, this seems to be the only such reference, and it’s not needed because the <b>cproj</b> function can be specified without it, e.g. </div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div>The <b>cproj</b> functions compute ..., except that all complex values with an infinite real or imaginary part (even if the other part is a NaN) project to ... </div><div><br></div></blockquote><div>On a different matter, given that <b>I</b> is now <b>_Complex_I</b>, even for Annex G implementations, the expression in the code block </div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><b>INFINITY + I * copysign(0.0, cimag(z))</b></div></blockquote><div><br></div><div>can get the sign of zero wrong if the implementation doesn't follow the rules for mixed domain operations which currently apply only to Annex G. We’re looking into moving those rules into the main body of the standard, nonetheless we should consider replacing the expression in the code block with:</div><div><br></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;"><div><b>CMPLX(INFINITY, copysign(0.0, cimag(z)))</b></div></blockquote><div><br></div><div>This would be in line with generally encouraging users who might have any interest in infinities or the sign of zeros to use <b>CMPLX(</b>A<b>, </b>B<b>)</b> instead of A <b>+ I *</b> B.</div><div><br></div><div>- Jim Thomas</div><div><br><blockquote type="cite"><div><div><br>Or maybe 7.3 needs to move to Annex G.<br><br>Thanks - Damian<br><br>Pacific Engineering Systems International ..... 20D Grose St, Glebe NSW 2037<br>Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here<br>Views & opinions here are mine and not those of any past or present employer<br></div></div></blockquote></div><br></div>_______________________________________________<br>Cfp-interest mailing list<br>Cfp-interest@oakapple.net<br>http://mailman.oakapple.net/mailman/listinfo/cfp-interest<br></div></blockquote></div><br></body></html>