Re: [eigen] Eigen/FFT

[ Thread Index | Date Index | More Archives ]

Gael Guennebaud wrote:
On Tue, Jun 23, 2009 at 1:59 PM, Benoit Jacob<jacob.benoit.1@xxxxxxxxx> wrote:
2009/6/23 Tim Hutt <tdhutt@xxxxxxxxx>:
 I think the default behavior of Eigen/FFT should favor correctness and generality over speed.
1) Scaling:
Other libraries (FFTW,IMKL,KISSFFT)  do not perform scaling, so there is a constant gain incurred after the forward&inverse transforms , so IFFT(FFT(x)) = Kx;  this is done to avoid a vector-by-value multiply.  The downside is that algorithms that worked correctly in Matlab/octave don't behave the same way once implemented in C++.
Simple solution, have FFT(x) and FFT_unscaled(x). That way people
won't be surprised by the results but they can still be optimised

if there is no true advantage in knowing that at compile time, I'd
prefer to see only one function:

FFT(..., int options = 0)

possible usages: FFT(x), FFT(x, Eigen::Unscaled), ...

I'm sure needs for other options will come.

I like options flags vs. other interfaces.
There's at least two needed options:
Eigen::FFT::Unscaled // do not perform the 1/N scaling to model invertibility Eigen::FFT::HalfSpectrum // use only right half+1 the spectral bins for even transform lengths, left half is implied by conjugate symmetry

and maybe
Eigen::FFT::PiRotate // spectra are rotated by pi radians resulting in digital frequency range [-pi:pi) rather than default [0:2pi)

Mail converted by MHonArc 2.6.19+