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

[Jim Thomas]

> On Sep 11, 2024, at 3:00 PM, Jim Thomas <jaswthomas at sbcglobal.net> wrote:
> 
> 
> 
>> On Sep 7, 2024, at 11:45 PM, Damian McGuckin <damianm at esi.com.au> wrote:
>> 
>> 
>> I agree 100% that such words need to be said.
>> 
>> 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
>> they overly complicate 6.2.5 and 6.5.6 and 6.5.7.
> 
> I agree some of the suggested changes don’t fit and will make some changes.

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.

Note that the definitions for “complex * complex”, “complex / complex”, and “real / complex” could be removed and perhaps considered as a separate proposal.

- Jim Thomas

> 
>> 
>> 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.
> 
> 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.
> 
>> 
>> That said, the concept of a "complex infinity" is referenced in 7.3.9.5 but not defined until G.2.
> 
> Good point.
> 
>> I would suggest that G.2 be moved into the start 7.3, i.e. 7.3.1.
> 
> 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 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, nonetheless we should consider replacing the expression in the code block with:
> 
> CMPLX(INFINITY, copysign(0.0, cimag(z)))
> 
> 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.
> 
> - Jim Thomas
> 
>> 
>> Or maybe 7.3 needs to move to Annex G.
>> 
>> Thanks - Damian
>> 
>> Pacific Engineering Systems International ..... 20D Grose St, Glebe NSW 2037
>> Ph:+61-2-8571-0847 .. Fx:+61-2-9692-9623 | unsolicited email not wanted here
>> Views & opinions here are mine and not those of any past or present employer
> 
> _______________________________________________
> Cfp-interest mailing list
> Cfp-interest at oakapple.net
> http://mailman.oakapple.net/mailman/listinfo/cfp-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20240914/43203901/attachment-0001.htm>