<br><br><div><span class="gmail_quote">On 8/2/07, <b class="gmail_sendername">Warren Focke</b> <<a href="mailto:focke@slac.stanford.edu">focke@slac.stanford.edu</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br><br>On Thu, 2 Aug 2007, Lars Friedrich wrote:<br><br>> What I understood is that numpy uses FFTPACK's algorithms.<br><br>Sort of.  It appears to be a hand translation from F77 to C.<br><br>> From <a href="http://www.netlib.org/fftpack">
www.netlib.org/fftpack</a> (is this the right address?) I took that<br>> there is a single-precision and double-precision-version of the<br>> algorithms. How hard would it be (for example for me...) to add the<br>> single-precision versions to numpy? I am not a decent C-hacker, but if
<br>> someone tells me, that this task is not *too* hard, I would start<br>> looking more closely at the code...<br><br>It shouldn't be hard.  fftpack.c will make a single-precision version if<br>DOUBLE is not defined at compile time.
<br><br>> Would it make sense, that if one passes an array of dtype =<br>> numpy.float32 to the fft function, a complex64 is returned, and if one<br>> passes an array of dtype = numpy.float64, a complex128 is returned?
<br><br>Sounds like reasonable default behavior.  Might be useful if the caller<br>could overrride it.</blockquote><div><br>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 double precision, so there it could make a difference.
<br><br>Chuck<br></div><br></div><br>