<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 Aug 27, 2024, at 7:12 PM, Damian McGuckin <damianm@esi.com.au> wrote:</div><br class="Apple-interchange-newline"><div><div><br>Thanks Jim, I thought I had gone through Annex G to catch the last of those.<br><br>On Tue, 27 Aug 2024, Jim Thomas wrote:<br><br><blockquote type="cite">Below is a link to a draft proposal per action item:<br> Jim: Draft proposal to remove instances of imaginary<br> lingering in draft.<br>https://wiki.edg.com/pub/CFP/WebHome/C2Y proposal - lingering references to<br>imaginary type-20240827.pdf<br></blockquote><br>I do not want to pick at straws but in G.3.2#5,<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>return x + I * y<br><br>is perfectly legal as 7.3.1 says that I is equivalent to _Complex_I. (unless a programmer is crazy enough to redefine the macro I - uggh!)<br></div></div></blockquote><div><br></div>It’s legal, but not correct for the use here.</div><div><br><blockquote type="cite"><div><div><br>I actually think that we could even say in 7.3.9.3#3<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>CMPLX(x, y) returns x + I * y<br><br>Because this is exactly what it does! Very succinct.<br></div></div></blockquote><div><br></div><div>No. They would be equivalent if macro <b>I</b> had imaginary type, but <b>I</b> is now (after integration N3274) defined to be <b>_Complex_I</b> whose value is +0 + 1 i<b>.</b> </div><div><br></div><div><b>CMPLX(-0.0, 1.0)</b> evaluates to -0 + i</div><div><b>(-0.0) + I * (1.0)</b> evaluates to -0 + (+0 + i) (1.0) -> -0 + (+0 + i) -> (-0 + 0) + i -> +0 + i (with default rounding mode).</div><div><br></div><div><b>CMPLX(0.0, INFINITY)</b> evaluates to 0 + inf i</div><div><b>0.0 + I * INFINITY</b> evaluates to +0 + (+0 + i) inf -> +0 + (0 inf) + (1 inf) i -> +0 + NaN + inf i -> NaN + inf i</div><div><br></div><div>If macro <b>I</b> has complex type (which is always the case now) it is generally unsuitable for use where infinities or the sign of zeros matter, as they do in G.3.2 #5 and #7.</div><div><br></div><div>- Jim Thomas</div><div><br></div><blockquote type="cite"><div><div><br>Note that we could be creating a rod for our own back (or that of somebody else if we are not around in 2029 or 2038 when IEEE 754 might or might not have complex arithmetic). I can already see a problem with the definition of the term "complex type" (which was hinted at by the mistake somebody else made in talking about "complex floating type" in paragraph 7.27#10 of the current document)<br><br>Note that my corrections address that mistake in 7.27#10 because there is no such that as a "complex floating type".<br><br>But they do not address the fundamental issue if we see imaginary types come back at a later date (if IEEE 754 precipitates that). Note that when the C standard talks about "real types" now, it does so in the almost strict mathematical sense. When it currently talks about "complex types" it is normally talking about C types. But that is a whole new problem. To follow what the standard does for "real types", i.e. the standard floating types, decimal floating types, and integers, yes, integers, we would have to define "complex types" as a combination of only a single category<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>complex floating types<br><br>and change a gazillion places in the standard. Not a tiny task.<br><br>Then, complex types can retain its mathematical meaning. And at a later stage, if the C type "imaginary" makes a comeback, then we can add<br><br><span class="Apple-tab-span" style="white-space:pre"> </span>imaginary floating types<br><br>to the concept of "complex types".<br><br>But changing the C standard to handle this very distant scenario is NOT worth it. It is happens post 2038, most of us won't have to worry about it as we will be long out of the picture and lying on a beach in retirmenet or otherwise.<br><br>- Damian</div></div></blockquote></div><br></body></html>