[Cfp-interest 3272] Re: Specification of complex operators

[Damian McGuckin]

On Wed, 11 Sep 2024, Jim Thomas wrote:

> I agree some of the suggested changes don?t fit and will make some changes.

I tried to massage/improve your words but fell abysmally short.

> 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:
> 
> 1. Not support complex at all.
> 
> 2. Support complex as specified in the main body of the standard (excluding
> Annex G).
> 
> 3. Support complex as specified in the main body of the standard extended by
> Annexes F and G.
> 
> 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.

While I understand WG14's ideas, I found leaving stuff in Annex G and even 
moving all of 7.3 back INTO Annex G made for a more readable document. And 
it can still be structured to satisfy 1/2/3 above. I did not realise that 
there was any part in Annex F related to complex except for footnote 454.

> Implementations that don?t support ISO/IEC 60559 via Annexes F and G might
> have other ideas about what a complex infinity should be.

Scary thought. That definition of complex infinity is mathematical.

> 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 cproj function can be 
> specified without it, e.g.
>
>       The cproj functions compute ..., except that all complex values
>       with an infinite real or imaginary part (even if the other part
>       is a NaN) project to ... 
> 
> On a different matter, given that I is now _Complex_I, even for Annex G
> implementations, the expression in the code block 
>
>       INFINITY + I * copysign(0.0, cimag(z))
> 
> 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,

See my earlier comments.

> nonetheless we should consider replacing the expression in the code 
> block with:
>
>       CMPLX(INFINITY, copysign(0.0, cimag(z)))

Wise idea. That also reduces/simplifies the explanation.

> This would be in line with generally encouraging users who might have 
> any interest in infinities or the sign of zeros to use CMPLX(A, B) 
> instead of A + I * B.

Agreed - Damian