Hello,
is there a way to tell numpy.fft.fft2 to use complex64 instead of
complex128 as output dtype to speed the up transformation?
Thanks
Lars
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/nump
Lars Friedrich wrote:
> Hello,
>
> is there a way to tell numpy.fft.fft2 to use complex64 instead of
> complex128 as output dtype to speed the up transformation?
>
As far as I can read from the fft code in numpy, only double is
supported at the moment, unfortunately. Note that you can get some
Hello,
David Cournapeau wrote:
> As far as I can read from the fft code in numpy, only double is
> supported at the moment, unfortunately. Note that you can get some speed
> by using scipy.fftpack methods instead, if scipy is an option for you.
What I understood is that numpy uses FFTPACK's alg
On Thu, 2 Aug 2007, Lars Friedrich wrote:
> What I understood is that numpy uses FFTPACK's algorithms.
Sort of. It appears to be a hand translation from F77 to C.
> From www.netlib.org/fftpack (is this the right address?) I took that
> there is a single-precision and double-precision-version
On 8/2/07, Warren Focke <[EMAIL PROTECTED]> wrote:
>
>
>
> On Thu, 2 Aug 2007, Lars Friedrich wrote:
>
> > What I understood is that numpy uses FFTPACK's algorithms.
>
> Sort of. It appears to be a hand translation from F77 to C.
>
> > From www.netlib.org/fftpack (is this the right address?) I too
On Thu, 2 Aug 2007, Charles R Harris wrote:
> On X86 machines the main virtue would be smaller and more cache friendly
> arrays because double precision arithmetic is about the same speed as single
> precision, sometimes even a bit faster. The PPC architecture does have
> faster single than doub
On Thu, 2 Aug 2007, Warren Focke wrote:
>
>
> On Thu, 2 Aug 2007, Lars Friedrich wrote:
>
>> versions to numpy? I am not a decent C-hacker, but if someone tells me,
>> that this task is not *too* hard, I would start looking more closely at the
>> code...
>
> It shouldn't be hard. fftpack.c wil
Hello,
thanks for your comments. If I got you right, I should look for a
FFT-code that uses SSE (what does this actually stand for?), which means
that it vectorizes 32bit-single-operations into larger chunks that make
efficient use of recent CPUs.
You mentioned FFTW and MKL. Is this www.fftw.o
Lars Friedrich wrote:
> Hello,
>
> thanks for your comments. If I got you right, I should look for a
> FFT-code that uses SSE (what does this actually stand for?), which means
> that it vectorizes 32bit-single-operations into larger chunks that make
> efficient use of recent CPUs.
>
>
http://
Lars Friedrich wrote:
> Hello,
>
> thanks for your comments. If I got you right, I should look for a
> FFT-code that uses SSE (what does this actually stand for?), which means
> that it vectorizes 32bit-single-operations into larger chunks that make
> efficient use of recent CPUs.
>
> You mentio
>
> MKL is from Intel (free as in beer on Linux and for academic purpose I
> think, but of course, you should check whether this applies to you).
AFAIK, the MKL is free for non-commercial purposes under Linux only, and
there is a special license for academics.
Matthieu
__
Lars Friedrich wrote:
> Hello,
>
> thanks for your comments. If I got you right, I should look for a
> FFT-code that uses SSE (what does this actually stand for?), which means
> that it vectorizes 32bit-single-operations into larger chunks that make
> efficient use of recent CPUs.
>
> You mentio
Thank you for your comments!
I will try this fftw3-scipy approach and see how much faster I can get.
Maybe this is enough for me...?
Lars
___
Numpy-discussion mailing list
Numpy-discussion@scipy.org
http://projects.scipy.org/mailman/listinfo/numpy-disc
13 matches
Mail list logo
