By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
455,433 Members | 1,643 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 455,433 IT Pros & Developers. It's quick & easy.

FFTW change from complex struct to float[2]

P: n/a
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
Share this Question
Share on Google+
5 Replies


P: n/a
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

P: n/a

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

P: n/a
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

P: n/a

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

P: n/a

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.