FFT module thoughts, was Re: [eigen] Eigen 3.0.5 Could NOT find FFTW |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
On 03/05/2012 04:21 PM, Trevor Irons wrote:
... if Mark is reading:
You had threatened to update the FFT module with 2D in the past. Are
there still plans for this?
Plans? Yes. Timely plans? Hmmm.... I am currently pursuing a Ph.D.,
while working nearly full-time and trying to spend time with my family.
Idle nights suitable for hacking are few and far between.
Here are some of the thoughts I have for ...
.... cleaning up the interface:
* Make correctly typed complex input a requirement for FFT::fft --
current version has a template the tries to do the right thing no
matter what (overambitious, at least for an initial version)
* Make separate real-optimized methods : rfft, rifft
o the original version that overloaded by scalar vs. complex
types is of minimal value and maximal headaches -- e.g. when
trying to perform proxied inverse FFTs, there is no way to
infer whether the result should be real
* Once the above things are done, then it should be easier to make
the returned proxy mode work properly. To allow code like:
o crossSpec += _dft.fft(x).cwiseProduct( _dft.fft(y) );
* Make the FFT operation unitary (all eigenvalues=1) by scaling
1/sqrt(n) for both directions -- this might be controversial because
it disagrees with Matlab. Thoughts anyone?
.... stability, testing enhancements:
* fix the CMake script FindFFTW -- I don't really know much about
CMake. The FindFFTW seems to do the right thing under linux, but
people are apparently having trouble in Windows. -- If you find a
bug, then you have 90% of the credentials needed to fix it !
.... features
* Add the Intel MKL backend
* 2-d FFTs
Anyone with thoughts on the above, or observations from their use of FFT?
-- Mark