Help solving compatibility with FFTW functions

Started by
6 comments, last by Concentrate 12 years, 11 months ago
I'm trying to store fftw_complex in a vector, but I soon came to realize that fftw_complex is of type double, which is unfortunate, since they are not assignable. So you see, I cannot store then in a vector. So I figure, I would
create a wrapper as follows :
[source]

class ComplexWrapper
{
private:
fftw_complex data;
public:
ComplexWrapper(): data() {}
double& operator[](int i){ return data; }
//make is copyable
ComplexWrapper(const ComplexWrapper& w){
data[0] = w.data[0]; data[1] = w.data[1];
}
//make it assignable
ComplexWrapper& operator = (const ComplexWrapper& w){
data[0] = w.data[0]; data[1] = w.data[1];
return *this;
}
operator double* (){ return &data; }
};
//...
std::vector<ComplexWrapper> _frequencyDomainData;
[/source]

and the call :

_fftwPlan = fftw_plan_dft_r2c_1d(_currentSample.size(), &_currentSample[0], &_frequencyDomainData[0],FFTW_MEASURE);


and I receive a conversion error:

error: cannot convert 'SDL_OpenGL::MusicAnalyzer::ComplexWrapper*' to 'double (*)[2]' for argument '3' to 'fftw_plan_s* fftw_plan_dft_r2c_1d(int, double*, double (*)[2], unsigned int)'




I know its expecting an array-of-double[2], but I guess thats not what I provided. Any help on solving this conversion?
Edge cases will show your design flaws in your code!
Visit my site
Visit my FaceBook
Visit my github
Advertisement
What is the wrapper buying you? Why don't you just use the FFTW types?
the docs state that fftw_complex is of type double[2] not double.

Additionaly they say that there is native support for compley numbers on many compilers through the headers <complex.h> (c) or <complex> (c++)
complex<T> is a templated complex number and said to be binary compatible to the fftw_complex typedef. So you can just pass a pointer to complex<double>
to the fftw functions.

Alternatively I think it would be much simpler to just do:
[source]
struct Complex {
double r;
double i;
};
[/source]

What is the wrapper buying you? Why don't you just use the FFTW types?


We'll the size might change so I needed to use a vector, but double[2] is not assignable thus can't be in vector.


[color=#1C2837][size=2]the docs state that fftw_complex is of type double[2] not double.

Additionaly they say that there is native support for compley numbers on many compilers through the headers <complex.h> © or <complex> (c++)
complex<T> is a templated complex number and said to be binary compatible to the fftw_complex typedef. So you can just pass a pointer to complex<double>
to the fftw functions.

Alternatively I think it would be much simpler to just do:
[size=2]?1234struct Complex { double r; double i;};[/quote][size=2]I just feel dirty doing that. Exchanging ComplexWrapper for std::complex<double>, thus create a std::vector< std::complex<double> > does not help, in that I get the same conversion error except from 'std::complex<double>*' to double(*)[2]. [size=2]And btw, the reason why I had ComplexWrapper wrapping fftw_complex instead of what you recommended is to try to be cache friendly, since fftw_complex is an array[2]. Not too much help, but was just a thought.[size=2]Any other ideas?
Edge cases will show your design flaws in your code!
Visit my site
Visit my FaceBook
Visit my github
You can probably just reinterpret_cast &frequencyDomainData[0] to a double(*)[2].

[color="#1C2837"]And btw, the reason why I had ComplexWrapper wrapping fftw_complex instead of what you recommended is to try to be cache friendly, since fftw_complex is an array[2].


What's more cache friendly about that?

[quote name='D.Chhetri' timestamp='1305992250' post='4813872']
[color="#1C2837"]And btw, the reason why I had ComplexWrapper wrapping fftw_complex instead of what you recommended is to try to be cache friendly, since fftw_complex is an array[2].


What's more cache friendly about that?
[/quote]

99.9% it is places in the same cache line, so when you acces one, the other is more likely to be stored in cache. I'm not so sure about structure, although POD is probably the same way.
Edge cases will show your design flaws in your code!
Visit my site
Visit my FaceBook
Visit my github

You can probably just reinterpret_cast &frequencyDomainData[0] to a double(*)[2].


I sure hope thats stable.
Edge cases will show your design flaws in your code!
Visit my site
Visit my FaceBook
Visit my github

This topic is closed to new replies.

Advertisement