|Re: [eigen] A complex FFT for Eigen|
[ Thread Index |
| More lists.tuxfamily.org/eigen Archives
- To: eigen@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [eigen] A complex FFT for Eigen
- From: "Benoit Jacob" <jacob.benoit.1@xxxxxxxxx>
- Date: Fri, 28 Nov 2008 03:12:00 +0100
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=SV0o4mrcJ50oQ7NQxLQzUlKazJVDrYSCbU29OeOwGAM=; b=ZnaZsRMI8tugr/oqHcOOChXb9rzmF+g6Q9sJ/IKUwbTmw3hrZ7N6oDQ/gTFHvp0ZcL afvKTJNgY3X6AxjBrM4XLiyYA3Qjt8SEnVqLa4KE5EePBXmtNbxKqw586yJLRc1etpn6 3QnvFJB7Ymd/fhMPgFvaK1ip4f5dQ/1KQolGc=
- Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=uEgJLkIIINUc4cejdqXY1pvAHkUnxF2ai3QIYF8Y+I5kQPjzS4Ezfs6sRsJ+pt4Cm5 cqm0CaHldGpS8eYQfxsNb9XjixEcJRH3x3ykvBuLfcIVh0yWi8QWztVrcp0HISTuq64d XpRiS8Irqsk1DEFjMvAQwuL8XQRArAOSWCuCc=
2008/11/27 Tim Molteno <tim@xxxxxxxxxxxxxxxxxxx>:
> I'd love to vectorize this better. I'll look into this, but ran into the
> issue of addressing sub-vectors in-place. I could not work out how to do it
> in Eigen. How do I carry out operations like
> data[1:N] += data[N+1:2N]
assuming that data is a vector of length 2N :
data.start<N>() += data.end<N>();
data.start<N>() += data.segment<N>(N);
(I think that segment only got that name after beta1 so you should use
trunk and "make doc" instead of using the online documentation).
> In other words, can I create a vector object that refers into part of
> another vector object?
> I tried using MatrixBlock objects, but could not get it to work?
Yes Eigen::Block is exactly what you need here and the above-mentioned
start/end/segment methods return objects of type Block.
> I think that FFT's are inherently non-local operations.
OK, so be it, then :)
> There might be
> better ways of doing this, but as it stands this code is pretty fast for an
> FFT and extremely small and lightweight, so I'd rather vectorize the apply
> function first as this is where most of the computation is happening.
Good to know.
As I said for now Eigen doesn't vectorize operations involve complex
numbers but I don't see anything making it impossible in theory, I'll
think about that when I can.
So, from Matthias's and your answers, I gather that there is no
generalization to non-complex numbers or to non-power-of-two sizes.
What about dynamic-size: are there, in your experience, use cases
where the size N isn't known at compile-time and it's be useful to
have a FFT able to handle any size N as a runtime parameter? If yes,
that's also something that we want.
Why are fft() and ifft() methods of a class CFFT ? I'd suggest either
making them static methods, or global functions. In Eigen, we tend to
do the latter as it makes for shorter calling syntax.
Let's give us a bit more time to determine whether we want FFT inside
Eigen -- don't want to sound un-enthusiastic, it's rather that I'm
currently busy and I don't want to make the wrong decision.
Anybody reading this, opinions?