[Numpy-discussion] What does fftn take as parameters?

[Roger Binns]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 06/12/11 10:45, Paul Anton Letnes wrote:
> As a side note: since the built-in search isn't really all that good, 
> would it be possible to put a customized google search box there
> instead?

It is easy since Sphinx is being used. Copy searchbox.html from the sphinx
basic theme into the templates directory and alter the form to use Google
custom search instead.

> First google hit, "numpy axis": 
> http://www.scipy.org/Tentative_NumPy_Tutorial

It is still somewhat confusing but I guess trial and error will work it
out.  It isn't at all obvious that you can do multiple FFTs at once from
the doc as everything is written in the singular.

> If you are using numpy functions like FFT, you are indeed converting to
> arrays.

I have no issue with that.  The data comes in over the network and is
supplied to the fft function as input so it doesn't really make any
difference whether I convert it into the numpy array type or the fft
function does internally - it is still only done once.

> and if you are treating the returned array as a list, you are probably
> (among other things) indexing it in an inefficient way.

I iterate over it once feeding the values into a separate calculation.

> If you are passing multidimensional lists here and there, you must have
> a lot of overhead memory use.

The data structures are less than 10MB in Python's internal PyObject
representation.  The machines being used have 32GB of memory.  There is
only one explicit or implicit conversion between different formats.

> I'm guessing that it's not your bottleneck (as others have suggested).
> 
I'm doing work directed by a matlab/embedded developer and he is obsessed
with performance.  I'm trying to interpret his advice to do all the ffts
at once in the context of the numpy fft apis.  If you look at the fftw
apis they go on about plans and reusing them so I assumed there was
something to all this :-)

I'm currently rewriting the non-FFT bits in C because they were far too
slow.  It is competing against a pure integer C algorithm that gives the
same output but has an O(n^2) time.

Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)

iEYEARECAAYFAk7eefMACgkQmOOfHg372QRAwACfXFK34pCgv32Xn3eri9FJbvis
+XYAoNcUCILHVcQ6ri353Kp0YPrw0EbS
=Z0KE
-----END PGP SIGNATURE-----