FFTW change from complex struct to float[2]

[spasmous]

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]

sp******@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

[spasmous]

Charles Mills wrote:

Perhaps check the project FAQ...
http://www.fftw.org/faq/section3.html#fftw2to3

Now, why didn't I think of that? Thanks :)

[stevenj]

sp******@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-fr...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]

st*****@alum.mit.edu wrote:

sp******@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-fr...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.)

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]

st*****@alum.mit.edu wrote:

sp******@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-fr...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.