Re: [eigen] Eigen/FFT

[Mark Borgerding <mark@xxxxxxxxxxxxxx>]

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
> > >       
> > +1
> >     
>
> 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.
>
> gael
>   
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)