Re: [eigen] Eigen is slow with complex matrices

[ Thread Index | Date Index | More Archives ]

I guess the main thing I'd like to implement before it "goes live" is the solidification of the interface.
* moving the scaling and real-fft-spectral format up to the main Eigen::FFT class rather than the helper implementation class
* implement the functions for (MatrixBase * dst, const MatrixBase & src)

Not more than a few hours work. I should be able to get to that within a week.

-- Mark

On 10/20/2009 11:18 AM, Benoit Jacob wrote:
Yes, in this case i'd be ok to skip unsupported, because it's already
been discussed many times and it's clear that it's useful and

CC'ing Mark.

Mark, could you update us on what you think is left to do before that
can be included in Eigen?

It's true that the sooner this gets merged, the longer the testing it
gets before we release 3.0, the better.


2009/10/20 Rohit Garg<rpg.314@xxxxxxxxx>:
Well..., if it is good enough, then why not merge into core eigen
directly, instead of unsupported if mark will be maintaining the FFT
backend/kissfft part of FFT for foreseeable future.

At any rate, stuff merged into development branch, never committed to
stable, can always be removed from the devel branch at a later date.
After all, there is *no* guarantees whatsoever on the unstable branch.
If we have the docs for it (part of eigen-unstable-docs of course),
putting it into eigen-devel will get much more testing done. ATM, I
don't think it has been tested in the wild yet. At least the FFTW
backend can be in eigen-devel, since it is fairly small and benign.

On Mon, Oct 19, 2009 at 7:40 PM, Benoit Jacob<jacob.benoit.1@xxxxxxxxx>  wrote:
2009/10/19 Rohit Garg<rpg.314@xxxxxxxxx>:
AFAIR, some work was done to add complex number support, compatible
with std::complex. It is sitting in the FFT fork.
Good point, i had forgotten about it.

  What happened to it?
It's still there.

Also, when can we see the FFT work being merged back into eigen
I wrote to Mark recently to ask, he replied that he still had to
implement a few suggestions that had been made.

However, re-reading, these didn't sound like very crucial points (it
was about "formatting options and I/O"), so it seems as if the FFT
module is already good enough to be merged to unsupported/ ? Need
informed feedback here.


Rohit Garg

Senior Undergraduate
Department of Physics
Indian Institute of Technology

Mail converted by MHonArc 2.6.19+