On 29.10.2014 19:40, Henry Gomersall wrote:
There could be an argument that this sort of capability should be added to the pyfftw package, as a package level config.
Something like:
import pyfftw pyfftw.default_threads = 4
I think that would be great, though probably slightly off-topic here.
import pyfftw.interfaces.numpy_fft as fft
The wisdom code can be added at the package import level too, but that doesn't need anything more.
If NumPy/SciPy provided interfaces to different FFT implementations, implementation specific routines (e.g. wisdom load/save or creation of byte-aligned empty arrays in the pyfftw case) could be made available through a subpackage, e.g. np.fft.implementation_specific. That subpackage then exposed routines specific to the implementation that lives below the simple interfaces. For implementation-specific configuration, perhaps a user-level configuration file or set of environment variables could be read on import of the specific implementation. At the very heart of allowing NumPy to use different FFT implementations could be a definition of an intermediate layer, much like LAPACK is for linear algebra. This probably would have to happen at the C-level. I'm only wildly speculating here as I don't have enough experience with interfaces to different FFT libraries, so I don't know whether the individual interfaces are close enough to be able to define a suitable "common interface". Alex