Since the last post on my python wrappers for FFTW, I’ve advanced the code substantially.
It now supports all the basic transforms using the same unified pythonic interface in which the transform is inferred from the dtype. In addition, I’ve added support for importing and exporting wisdom. Wisdom is FFTW’s way of remembering plans that have already been created, thereby speeding up the planning process in future. In particular, the slow planning routines like FFTW_MEASURE will benefit at the first running it the wisdom can be loaded from disk.
The wisdom routines don’t actually write to disk at present, this is because the nice api feature of FFTW that makes this trivial wasn’t added until FFTW 3.3 which is not widely distributed yet. I’ve written the code for this, but commented it out at present. The wisdom is exported as a tuple of strings, which can be pickled and saved as necessary. I suppose the strings could be saved too, but I’ve not tried this. There may be some problems with unicode conversions (which the output from FFTW is not), but I’m happy to be proven wrong on this.
My next goal is to implement the numpy fft interface, making pyfftw a drop in replacement for numpy.fft. The one small problem I’ve encountered so far is that numpy.fft will happily run over repeated axes, which FFTW doesn’t seem to like (at least, using my wrappers). I may just ignore this limitation – who is likely to use it anyway? (serious question!)
As usual, code on github, release on python package index, and docs here.
Henry,
Upon updating pyFFTW I see that the test suite has been changed around. I haven’t done much with unit test, and I can’t seem to find the right way to run the tests… I’m sure it is something easy I’m missing, but any help would be appreciated. Ultimately, I just want to make sure pyfftw can see the right fftw3 libraries.
Thanks,
Andy
Apologies for the slow reply. To run everything, the easiest way is to use the auto-discovery capability: “python -m unittest discover” in the top level directory (with –verbose if you want to detail all the tests that are running). Does this solve the problem?
Works like a charm, I hadn’t seen the discover module. That made the difference since I couldn’t figure out how to tell it where to find the tests etc.
Is there anything fromt the tests that you are particularly interested in for benchmarking?
Not really; I have thought about writing a proper benchmarking script, but I haven’t quite been able to muster the enthusiasm. If you want to benchmark them, I’d be very interested in the results (and the code)!
There is at least one bug in the interfaces code in the latest release in which the returned array is the same as the internal array in a cached object, so potential badness happens if you assume it’s unchanging. It’s fixed in master.
I should also really write a blog post on the big changes.