[Cfp-interest 3106] N3240 2024/04/14 Gustedt, Remove imaginary types

[James Thomas]

This note comments on N3240 "Remove imaginary types” and N3206 “The future of imaginary types". C references are to N3219. The comments are mine and have not been reviewed by CFP.
 
> 1 Problem description …
 
The problem description should be correct. Presumably it is the basis for SC22WG14 decisions about the proposal. 
 
It says 

> “Optional imaginary types, indicated by the keyword _Imaginary, have no current implementation that would be known to WG14, and we are not aware of any plans for implementing them.”

The notable lack of implementions is a valid concern, though there is a supported full implementation.
 
It says N3206 “described a number of problems with these types.“ The problem description in N3206 concludes with
> To summarize:
> 
> Imaginary types are in a state where they never would have made it into the C standard if we would be apply the same standards for new features that we have, now. 
I assume this refers to the claim (earlier in the problem statement) that imaginary types
 
> “are not operational because it is not possible to map their mathematical properties to our type/operator/conversion model as-is.”

This claim is based on a misunderstanding of the usual arithmetic conversions, which determine a common corresponding real type, not a common real type. (The fact that there is a full implementation provides a practical validation of the specification.)
> Imaginary types could be an optimization opportunity, but no platform that I know of has yet taken advantage of this. 
I’d say: Imaginary types offer performance advantages, but platforms have not taken advantage of this by implementing the types.
> One could even hope that modern optimization compilers are able to track values that are known to have a real or imaginary part that is zero, and then to optimize the operations for these values. So the whole idea of imaginary types would be obsolete nowadays. 
Treating a complex operand with a zero part as if it were real or imaginary can change the result and is not a valid optimization.
 
The problem description in N3206 also says 

> “implementions that would start to provide imaginary types from one version to another would probable put their user base into trouble.”

This could be addressed by removing the Annex G requirement that the macro I be defined to be _Imaginary_I. (Then the implementation wouldn’t need to change the macro I, and to use imaginary I users could undefine I and redefine it to _Imaginary_I.)
 
N3206 and N3240 don’t acknowledge the problem that imaginary types were intended to help solve: how to treat special values in a way that is efficient and consistent with ISO/IEC 60559. As noted in email discussion this can be done (without imaginary types) by accessing the real and imaginary parts directly, e.g. yi * (u + vi) could be computed by CMPLX(-y * v, y * u).
 
> 4.1 Changes to Clause 6 …
 
“imaginary type” also appears in: 
6.7.2 #6
6.7.2 Example 5
 
> 4.2 Changes to Clause 7.3 (Complex arithmetic) …
 
The semantic difference between the mathematical unit i and the C macro I (defined as _Complex_I) should be emphasized.

The change proposed for 7.3.9.3 is not desirable. For example, CMPLX(0, INFINITY) should be 0 + inf i, but (double complex)((double)(0) + _Complex_I * (double)(INFINITY)) = 0 + 0i + (0 + i) * inf = 0 + 0i) + (NaN + inf i) = NaN + inf i. Better to remove the entire note.
 
The fact that z and creal(z)+cimag(z)*I are not equivalent expressions needs noting and some explanation.
 
> 4.3 Optional editorial changes …
 
_Complex_I should be explicitly defined to have real part +0 and imaginary part 1.
 
> 6 Appendix: replacement of Annex G …
 
The parts of C23 G.5 that don’t depend on imaginary types should be retained. Further, the definitions of the arithmetic operators for real and complex operands should be incorporated into the main body of C. Without that specification, "complex op real" operations are unnecessarily too loosely defined. The usual arithmetic conversions don’t require converting the real operand to complex, but they don’t say how the results are computed which allows the troublesome conversions to complex.
 
For the paragraph starting “Each of the functions casin, catan, …” it must be clear that the mathematical imaginary unit i does not behave like the C macro I (defined to be _Complex_I). See comment above under 4.2.
 
I haven’t checked all the Appendix in detail. It would be helpful to indicate the subclauses for which no change is proposed.

- Jim Thomas
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20240521/3dfb2b14/attachment.htm>