Home > Archive > C > October 2005 > FFTW change from complex struct to float[2]
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
FFTW change from complex struct to float[2]
|
|
| spasmous@yahoo.com 2005-10-24, 6:55 pm |
| I'm looking into upgrading from version 2 to version 3 of the FFT code
package FFTW (www.fftw.org). The two versions are incompatible - a lot
of it has to do with changing from a complex struct with two members
(eg. a.re and a.im) to a two element array float[2] (eg. a[0] and a[1])
to hold the real and imaginary parts.
So whereas before
fftw_complex a[1000];
would give you 1000 structs with the following members a[i].re and
a[i].im, you now have
fftw_complex a[1000];
existing as float a[2][1000].
I'm wondering what advantages this change has - I mean, why would one
break compatibility for this?
| |
| Charles Mills 2005-10-24, 6:55 pm |
| spasmous@yahoo.com wrote:
> I'm looking into upgrading from version 2 to version 3 of the FFT code
> package FFTW (www.fftw.org). The two versions are incompatible - a lot
> of it has to do with changing from a complex struct with two members
> (eg. a.re and a.im) to a two element array float[2] (eg. a[0] and a[1])
> to hold the real and imaginary parts.
>
> So whereas before
>
> fftw_complex a[1000];
>
> would give you 1000 structs with the following members a[i].re and
> a[i].im, you now have
>
> fftw_complex a[1000];
>
> existing as float a[2][1000].
>
> I'm wondering what advantages this change has - I mean, why would one
> break compatibility for this?
Perhaps check the project FAQ...
http://www.fftw.org/faq/section3.html#fftw2to3
-Charlie
| |
|
|
| stevenj@alum.mit.edu 2005-10-28, 6:55 pm |
| spasmous@yahoo.com wrote:
> I'm looking into upgrading from version 2 to version 3 of the FFT code
> package FFTW (www.fftw.org). The two versions are incompatible - a lot
> of it has to do with changing from a complex struct with two members
> (eg. a.re and a.im) to a two element array float[2] (eg. a[0] and a[1])
> to hold the real and imaginary parts.
This and other changes are described in the manual:
http://www.fftw.org/doc/Upgrading-f...-version-2.html
(The change in fftw_complex is really the least of the changes.)
> So whereas before
>
> fftw_complex a[1000];
>
> would give you 1000 structs with the following members a[i].re and
> a[i].im, you now have
>
> fftw_complex a[1000];
>
> existing as float a[2][1000].
>
> I'm wondering what advantages this change has - I mean, why would one
> break compatibility for this?
Defining fftw_complex as double[2] is guaranteed to be binary
compatible with the C complex type in the 1999 ANSI C standard (and is
also guaranteed to be binary compatible with the C++ complex<double>
template class). In fact, if you #include <complex.h> before
<fftw3.h>, then the interface will use the C99 complex type, which is a
great convenience. See also:
http://www.fftw.org/doc/Complex-numbers.html
in the manual. In contrast, a struct { double re, im; } type, which
was the old type, is strictly speaking not binary-compatible with
double[2], since the compiler is allowed to add padding. This is why
we switched.
(In practice, the difference is mostly academic, because on every
system in modern use the two are binary compatible. The only exception
that I have ever heard of was some old Cray system. But, since we were
changing many other parts of the API anyway, we figured we might as
well be standard-conforming.)
Cordially,
Steven G. Johnson
| |
| William Hughes 2005-10-28, 6:55 pm |
|
stevenj@alum.mit.edu wrote:
> spasmous@yahoo.com wrote:
>
> This and other changes are described in the manual:
>
> http://www.fftw.org/doc/Upgrading-f...-version-2.html
>
> (The change in fftw_complex is really the least of the changes.)
>
>
> Defining fftw_complex as double[2] is guaranteed to be binary
> compatible with the C complex type in the 1999 ANSI C standard (and is
> also guaranteed to be binary compatible with the C++ complex<double>
> template class). In fact, if you #include <complex.h> before
> <fftw3.h>, then the interface will use the C99 complex type, which is a
> great convenience. See also:
>
> http://www.fftw.org/doc/Complex-numbers.html
>
> in the manual. In contrast, a struct { double re, im; } type, which
> was the old type, is strictly speaking not binary-compatible with
> double[2], since the compiler is allowed to add padding. This is why
> we switched.
>
> (In practice, the difference is mostly academic, because on every
> system in modern use the two are binary compatible. The only exception
> that I have ever heard of was some old Cray system. But, since we were
> changing many other parts of the API anyway, we figured we might as
> well be standard-conforming.)
>
Don't be too certain this is just academic.
You also have to take into acount future implementations. What
about the machine on which 128 bit reads are much faster than
64 bit reads. An implementation on such a machine might well
choose 64 bit doubles for backward compatibility and
add padding to struct { double re, im; }.
-William Hughes
| |
| spasmous@yahoo.com 2005-10-28, 6:55 pm |
|
stevenj@alum.mit.edu wrote:
> spasmous@yahoo.com wrote:
>
> This and other changes are described in the manual:
>
> http://www.fftw.org/doc/Upgrading-f...-version-2.html
>
> (The change in fftw_complex is really the least of the changes.)
>
> (snip)
Thanks for your comments, I like the new interface much better. The
only issue is getting everyone in my lab who uses the fftw_complex type
to update their code - I guess biting the bullet occasionally isn't a
bad thing.
|
|
|
|
|