[Cfp-interest 3107] Re: [SC22WG14.25653] N3240 2024/04/14 Gustedt, Remove imaginary types

[Jₑₙₛ Gustedt]

Hi,
thanks for looking into this!

on Tue, 21 May 2024 12:27:23 -0700 you (James Thomas
<jaswthomas at sbcglobal.net>) wrote:

> This note comments on N3240 "Remove imaginary types” and N3206 “The
> future of imaginary types".

Maybe you have not seen the more recent version N3263?

> 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. 

Although I asked for it several times, that claim has not yet been
proven, I only have hearsay. Do you have a link to such an
implementation or a document that describes it? Is it widely used,
accessible, or just an "academic" show case? Does this implementation
support C17 and then C23 in a reasonable time frame?

> 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.

They *could* offer performance advantages. I suspect that on modern
platforms and applications that would typically use them (mostly HPC
code, I guess) this would just be a micro-optimization that goes down
in the noise.

> > 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

Yes, but neither implementations nor users seem to care a lot. In a
HPC world that is dominated by applications that use `-ffast-math` and
similar such considerations seem not to be pre-dominant.

> > “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

Taken care of in N3263

> > 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.

Taken care of in N3263

> 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.

Are you saying that even the existing specification of complex types
in clause 6 is defective?

Removing imaginary types (more or less syntactically) should in no way
remove meaning from the definition of the complex types because they
are not used for their definition.

> 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 really good if you could invest that time in N3263.

> It would be helpful to indicate the subclauses for which no change
> is proposed.

This request unfortunately comes too late for this review cycle. But
if you are interested in the detailed changes, you could still look at
the diffs on the git platform.

For the editorial changes or reorganization of the resulting text
after removal, or for moving contents from the annex to the main body,
I would be all open for that. But I'd suggest to do that in a second
phase; we are sufficiently early in the review cycle that the FP SG,
for example, would have much latitude to propose such changes.

Thanks
Jₑₙₛ

-- 
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::