| Re: [eigen] FFT for Eigen |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/eigen Archives
]
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] FFT for Eigen
- From: Rohit Garg <rpg.314@xxxxxxxxx>
- Date: Tue, 19 May 2009 10:00:04 -0700
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=t7jqGImOOkMclhd1wiVc1ypqu9cM5ek0qE6zVcTVGgM=; b=MOhcaOyYmJcg45XZu2gF9lznUUIg3cgkrnZTv7N6To2RLzb+zoZ0TAfu++Ab9DX0t8 9Gzdr7abUJ3iOfMp67VUZdmlxxuWkOcRkTED5awp8oW0EOcE9uCt2kMMeFnFor24ok81 AaR33lpXw44O4hyZwxJ6p/eDuYpJjs4hvXKQQ=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=mvZHdx/Ar5J3Vi4JX+V+W9Cl8SG8xHx2YevEqLUPnrKLyjNWSrE37gMB+40ZAG4ViZ 172R/MBrOH9eXaHMoIje9Pw9SK9I4IcoDMmXXYRjngqX0/uAGMMC55PpqfoRaCqNa6MY MKKqpsMo8zGhwD+aZY0PdQCa3TFDXUGvgkr/0=
This is probably not a good idea. I believe that they should be stored
in the interleaved format. I'll be happy to pitch in with SSE2/3
intrinsics code for complex multiplication, division if neccessary. I
think we should go the standard way as many other libraries and
std::complex use it.
So far, on this discussion, the only reason for not using the
interleaved format that I have seen is that it is tricky to multiply
using that. Is there any other reason?
IMHO, we shouldn't lose compatibility with ~90% of other complex
libraries/formats just to simplify multiplication.
On Tue, May 19, 2009 at 5:49 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> I can believe that this is probably a very efficient storage scheme.
> We could offer this as an option if really it's not too hard to
> implement (i didn't start thinking about this).
>
> The default should remain the current for many reasons, but as an
> option why not.
>
> Cheers,
> Benoit
>
>
> 2009/5/19 Márton Danóczy <marton78@xxxxxxxxx>:
>>> I concur: I don't think that it would be very useful to have complex
>>> matrices with the real and imaginary parts stored separately. Most
>>> operations -- and the more costly ones -- would run slower in such a
>>> scheme. The basic issue here is memory locality.
>>
>> What about storing them packet by packet? That is, in case of floats,
>> four real parts followed by four imaginary parts. That would not be
>> too hard to implement and vectorization of component-wise operations
>> would be trivial. And I think even FFTW can handle that using the guru
>> interface, by setting up a split fft plan with a stride of
>> 2*packetsize.
>>
>> Marton
>>
>>
>>
>
>
>
--
Rohit Garg
http://rpg-314.blogspot.com/
Senior Undergraduate
Department of Physics
Indian Institute of Technology
Bombay