Path: csiph.com!news.mixmin.net!eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: structs passed by copy Date: Sun, 22 Jan 2023 16:01:13 -0800 Organization: None to speak of Lines: 63 Message-ID: <87o7qqglva.fsf@nosuchdomain.example.com> References: <76ec6d87-0f5d-4671-b4c8-7023e3da787an@googlegroups.com> <20230120230138.1225d36e5ad8e5f07401c67a@gmail.com> <1btu0jojlm.fsf@pfeifferfamily.net> <87edrnifxn.fsf@nosuchdomain.example.com> <87sfg2gszl.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain Injection-Info: reader01.eternal-september.org; posting-host="d34d0f49d825817f6e40612c0dbcdea1"; logging-data="3490553"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Kx+eIMguAywo2iEA1p1HM" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) Cancel-Lock: sha1:BA5uceC6ww1Kp0eIVUfQcBxuJHE= sha1:BaIN1plcQKRTdwxh3wYazd+lKjs= Xref: csiph.com comp.lang.c:168903 James Kuyper writes: > On 1/22/23 16:27, Keith Thompson wrote: >> James Kuyper writes: > ... >>> Just as it is extremely common for numbers to be pure-real, with no >>> imaginary part, it is not uncommon, when doing physics or engineering >>> using complex values, to have some of those quantities being calculated >>> to be guaranteed to be pure imaginary. Storing such quantities using >>> _Imaginary types reduces the space required by a factor of 2, which can >>> be important if you have huge arrays of them (not an uncommon feature of >>> physics/engineering programs). More importantly, I think, is that use of >>> such types should enable warnings about questionable uses of such types, >>> such as taking the Real part of them. >>> >>> It's certainly not impossible to work with such quantities efficiently >>> without using the _Imaginary types - before the introduction of those >>> types, they could have been stored as real values, with a comment >>> indicating that these real values are the imaginary component of the >>> actual value. However, making _Imaginary a part of the declaration of >>> such objects is better than relying upon people to notice such a comment. >> >> Thanks, I didn't know that. >> >> Given that imaginary types are useful, I wonder why they're not >> widely supported. Neither gcc 12.2.0 nor clang 15.0.0 supports >> `_Imaginary double`. >> >> And both predefine __STDC_IEC_559_COMPLEX__, which if I'm reading >> Annex G correctly implies that they're required to support imaginary >> types. I was wrong about this; see below. > I said that they could be useful. I didn't address how useful they would > be. I don't imagine that the usefulness is great. I hope the committee > had some evidence of actual demand for such a feature before deciding to > add it to the language. There are still a few things I'm curious about: Why did the committee choose to make complex numbers mandatory and imaginary numbers optional? I wouldn't expect imaginary numbers to be very difficult to implement once you have complex numbers. Nor would I expect users of one C implementation to have a greater need for them than users of another (which would have been a reasonable basis for making them optional). Have any C compilers implemented _Imaginary? (If not, it seems like a failed experiment.) A minor note: N1256 (C99) has a footnote in 7.3 referring to "informative annex G". N1570 (C11) has the same footnote. But Annex G is informative in C99, normative in C11. BTW, I was wrong about one thing: Support for _Imaginary is optional even for an implementation that predefines __STDC_IEC_559_COMPLEX__. `#ifdef _Imaginary_I` can be used to detect whether an implementation supports imaginary types. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for XCOM Labs void Void(void) { Void(); } /* The recursive call of the void */