469,330 Members | 1,269 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,330 developers. It's quick & easy.

FFTW change from complex struct to float[2]

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?

Nov 15 '05 #1
5 7657
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

Nov 15 '05 #2

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 :)

Nov 15 '05 #3
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

Nov 15 '05 #4

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

Nov 15 '05 #5

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.

Nov 15 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

7 posts views Thread by seia0106 | last post: by
6 posts views Thread by Stanley | last post: by
4 posts views Thread by Erica | last post: by
6 posts views Thread by mark | last post: by
3 posts views Thread by Fabio Garufi | last post: by
3 posts views Thread by Klaas Vantournhout | last post: by
11 posts views Thread by jacob navia | last post: by
9 posts views Thread by void main | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
reply views Thread by haryvincent176 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.