[Cfp-interest 2983] Re: [SC22WG14.24550] background regarding complex and imaginary types

Jₑₙₛ Gustedt jens.gustedt at inria.fr
Fri Jan 19 02:51:05 PST 2024


Jim,
thanks for that paper, this is indeed helpful!

So I take it that there has only been one historic implementation of
imaginary types, and that implementation is not maintained any more?

For the take on the i suffix, I don't agree. Integrating this into the
language as a proper literals is much more that just having `I`. In
fact, with such literals an application that uses complex numbers
would not even necessarily have to include `<complex.h>` anymore. With
C23, presence of any header file can be tested with `__has_include`
and so we can separate support for complex numbers in section 6 from
support of complex numerical algorithms in section 7. Basically the
macros in the header that are merely type support and not "real"
library would become obsolete.

So this is definitively not just cosmetics.

Also I don't get the point on using `y*I` and not being able to use
the suffix, there. I don't see `y*1.IF` as much more complex to write
than that.

Currently I don't see that any of the existing implementations that
have support for complex could even switch to use imaginary types,
because since we have type inspection (C11 `_Generic` for example) the
value of `I` is pretty much part of the corresponding ABI. (And C23
`auto` and `typeof` will enforce this.)

The example of multiplication with an pure imaginary value and some
complex infinity shows that this might have been a good idea, but also
that nobody in the application world seems ever to have cared enough
about such boundary cases to motivate an implementation of this
feature.

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 ::
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 195 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.oakapple.net/pipermail/cfp-interest/attachments/20240119/fa38774d/attachment.bin>


More information about the Cfp-interest mailing list