An FFT[W] overhaul has been an itch of mine for
a while. Preliminary review of the problem led
to several goals related to your discussions
below:
(1) Migrate from FFTW2 to FFTW3
The first step is to replace the FFTW2 library
calls with the appropriate ones from FFTW3.
Although the API has changed, for basic usage
a simple conversion woul be possible.
(2) Unify the FFT and FFTW framework
To include:
[1] Make the input and outputs between the
implementations symmetric and identical
where possible. Ideally, we should be
able to take a forward FFT and an inverse
FFTW to get back the original---maaybe
within a scale factor.
[2] Fix the docs to make it clear what each
transform computes mathematically and
how they relate. Given the widespread
use and good performance of FFTW3, I
thought to standardize to their interface.
[3] Enable FFTW based threading support. By
that I mean to use the FFTW3 guru interface
which supports arbitrary strides of many
flavors. It is possible to use optimized
FFTW3 routines directly if given the dims
of the pidle involved.
NOTE: The complex elements no longer have
to be adjacent for FFTW3 so it should be
possible to have a generic FFT interface
that could call FFTW3 behind the scenes if
installed.
[4] Add support for the various flavors of DCT
type transforms. See the FFTW3 docs for
details.
(3) Refactor the complex data type appropriately
and add appropriate support or hooks for the
same.
Cheers,
Chris
Craig DeForest wrote:
> Hi, Hugh,
>
> Right now, the built-in fft code requires using separate variables to
> contain the
> real and imaginary components of the original array. For example, to
> find the
> Fourier transform of a real array $a nondestructively, one can:
>
> $ai = zeroes $a;
> $ar = copy $a;
> fft($ar,$ai);
> or
> $aa = copy $a;
> realfft($aa);
> $ar = $a->(0:$a->dim(0)/2-1);
> $ai = $a->($a->dim(0)/2:-1);
>
> The FFTW stuff requires running dim 0 across (real,imaginary), so one
> says
>
> $result = fftw $cplx
>
> where $cplx has size 2 in in the 0 dim. Different but also reasonable.
>
> I'm not sure whether the complex handling has to be changed, but I
> don't like that the built in fft stuff is automatically inplace. I've
> been complaining about that for a long time, but since I'm finally
> diving into the code I figure now's the time do something about it
> (provided that nobody pipes up and complains). Certainly I'm open to
> making the built-ins behave more like fftw if there's a desire to do so.
>
> Cheers,
> Craig
>
>
>
> On Mar 27, 2009, at 10:29 AM, Hugh Sasse wrote:
>
>> On Fri, 27 Mar 2009, Craig DeForest wrote:
>>
>>> I've been meaning to overhaul the internal FFT code for a long time,
>> [...]
>>> What's the consensus on how to overhaul FFT'ing? I am hesitant to
>>> ditch the internal FFT code entirely, because it's nice to have an
>>> internal fallback from the rather nice FFTW library (and hence avoid
>>> yet another dependency for basic operations like convolution).
>>
>> This isn't going to be consensus opinion, but I think complex numbers
>> are pretty important to useful FFT code. You told me:
>>
>> CD> PDL::Complex was never fully implemented, in the sense of
>> CD> overloading all the basic operators. Hence many operations will
>> CD> "fall through" to the PDL implementation that is under the hood.
>>
>> slightly reformatted.
>> See the thread starting
>> Message-ID: <[email protected]
>> Maybe there's nothing that can be done to simplify this, but I thought
>> It raise it given the opportunity.
>>
>> Hugh
>>
>
>
> _______________________________________________
> Perldl mailing list
> [email protected]
> http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
>
_______________________________________________
Perldl mailing list
[email protected]
http://mailman.jach.hawaii.edu/mailman/listinfo/perldl
