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



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/