Re: Complex numbers in compilers - upcoming GNU Tools Cauldron.
On 9/12/23 11:25, Richard Biener wrote: On Tue, Sep 5, 2023 at 10:44 PM Toon Moene wrote: This is even obvious in weather forecasting software I have to deal with *today* (all written in Fortran). Some models use complex variables to encode the "spectral" (wave-decomposed) computations in parts where that is useful - others just "degrade" those algorithms to explicitly use reals. Lack of applications / benchmarks using complex numbers is also a problem for any work on this. Yes, a certain amount of circular "reasoning" is at work here. However, there is sufficient Fortran programming out there to study how to compile complex number arithmetic ... LAPACK and its test programs. I realize that they are not "benchmarks" in the sense that they do not give you a measure how to speed up the code the compiler generates; but they are real-life complex number algorithms coded in a programming language that had complex number support from the beginning. Hope this helps, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: Complex numbers in compilers - upcoming GNU Tools Cauldron.
> On Sep 12, 2023, at 7:12 AM, Martin Uecker via Gcc wrote: > > Am Dienstag, dem 12.09.2023 um 11:25 +0200 schrieb Richard Biener via Gcc: >>> ... >> >> Lack of applications / benchmarks using complex numbers is also a >> problem for any work on this. > > I could probably provide some examples such as a FFT, > complex Gaussian random number generation, mandelbrot > set computation, etc. Another nice one might be NEC-2, an electromagnetic field analyzer used to model antennas and similar problems. paul
Re: Complex numbers in compilers - upcoming GNU Tools Cauldron.
Am Dienstag, dem 12.09.2023 um 11:25 +0200 schrieb Richard Biener via Gcc: > On Tue, Sep 5, 2023 at 10:44 PM Toon Moene wrote: > > > > This is going to be an interesting discussion. > > > > In the upcoming GNU Tools Cauldron meeting the representation of complex > > numbers in GCC will be discussed from the following "starting point": > > > > "Complex numbers are used to describe many physical phenomenons and are > > of prime importance in data signal processing. Nevertheless, despite > > being part of the C and C++ standards since C99, they are still not > > completely first class citizens in mainstream compilers." > > > > *This* is from the Fortran 66 Standard (http://moene.org/~toon/f66.pdf - > > a photocopy of the 1966 Standard): > > > > - - - - - > > > > Chapter 4. Data Types: > > ... > > 4.2.4 Complex Type. > > > > A complex datum is processor approximation to the value of a complex number. > > ... > > > > - - - - - > > > > I can recall people complaining about the way complex arithmetic was > > handled by compilers since the late 70s. > > > > This is even obvious in weather forecasting software I have to deal with > > *today* (all written in Fortran). Some models use complex variables to > > encode the "spectral" (wave-decomposed) computations in parts where that > > is useful - others just "degrade" those algorithms to explicitly use reals. > > Lack of applications / benchmarks using complex numbers is also a > problem for any work on this. > I could probably provide some examples such as a FFT, complex Gaussian random number generation, mandelbrot set computation, etc. Martin
Re: Complex numbers in compilers - upcoming GNU Tools Cauldron.
On Tue, Sep 5, 2023 at 10:44 PM Toon Moene wrote: > > This is going to be an interesting discussion. > > In the upcoming GNU Tools Cauldron meeting the representation of complex > numbers in GCC will be discussed from the following "starting point": > > "Complex numbers are used to describe many physical phenomenons and are > of prime importance in data signal processing. Nevertheless, despite > being part of the C and C++ standards since C99, they are still not > completely first class citizens in mainstream compilers." > > *This* is from the Fortran 66 Standard (http://moene.org/~toon/f66.pdf - > a photocopy of the 1966 Standard): > > - - - - - > > Chapter 4. Data Types: > ... > 4.2.4 Complex Type. > > A complex datum is processor approximation to the value of a complex number. > ... > > - - - - - > > I can recall people complaining about the way complex arithmetic was > handled by compilers since the late 70s. > > This is even obvious in weather forecasting software I have to deal with > *today* (all written in Fortran). Some models use complex variables to > encode the "spectral" (wave-decomposed) computations in parts where that > is useful - others just "degrade" those algorithms to explicitly use reals. Lack of applications / benchmarks using complex numbers is also a problem for any work on this. Richard. > Kind regards, > > -- > Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 > Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Complex numbers in compilers - upcoming GNU Tools Cauldron.
This is going to be an interesting discussion. In the upcoming GNU Tools Cauldron meeting the representation of complex numbers in GCC will be discussed from the following "starting point": "Complex numbers are used to describe many physical phenomenons and are of prime importance in data signal processing. Nevertheless, despite being part of the C and C++ standards since C99, they are still not completely first class citizens in mainstream compilers." *This* is from the Fortran 66 Standard (http://moene.org/~toon/f66.pdf - a photocopy of the 1966 Standard): - - - - - Chapter 4. Data Types: ... 4.2.4 Complex Type. A complex datum is processor approximation to the value of a complex number. ... - - - - - I can recall people complaining about the way complex arithmetic was handled by compilers since the late 70s. This is even obvious in weather forecasting software I have to deal with *today* (all written in Fortran). Some models use complex variables to encode the "spectral" (wave-decomposed) computations in parts where that is useful - others just "degrade" those algorithms to explicitly use reals. Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
