[boost] fft

From: Ken Appleby (ken_at_[hidden])
Date: 2002-09-24 05:35:25

Date: Sun, 22 Sep 2002 18:55:49 -0600
From: Jason D Schmidt <jd.schmidt_at_[hidden]>

> Excerpts from
> Date: 22 Sep 2002 10:02:42 +0200
> From: Gabriel Dos Reis <gdr_at_[hidden]>
> In-Reply-To: Jason D Schmidt's message of "Sat, 21 Sep 2002 17:48:25
> -0600"
>
> The prototype is:
> | template <const size_t cPoints, class value_type>
> | std::valarray<std::complex<value_type> > fft(const
> | std::valarray<std::complex<value_type> >& data).

> >This prototype suggests that you're not computing "in-place".  That is
> >regrettable because that is commonly used.
> >However, it would worth investigating how much of the abstraction
> penalty
> >the Named Return Value Optimization removes.
>
> Actually, the computation is actually done in-place; here's how:
> ...

Doesn't this prototype mean that the fft function will
- allocate and initialise a local array for the result,
- copy the contents out to the caller's array on return,
- free the local result array?

For std::valarray the allocation must be on the heap, and the initialisation
is in fact unnecessary but unavoidable.  So I think there could be
performance
drawbacks to this design.  Heap allocation and freeing on every call to
fft()
should definitely be avoided, in my opinion.  Allowing the caller to manage
memory and pass in references or iterators to both the data and result
arrays
would avoid all of these extra overheads.

Or perhaps the allocation copying and freeing of the local/result array can
be avoided
by designing an FFT class rather than a function?  The copying of the
result could be avoided by allowing the caller access to the result array in
the FFT
instance.

Ken Appleby