On Tue, May 27, 2008 at 3:14 PM, Robert Kern <robert.kern@gmail.com> wrote:
I would definitely *not* use environment variables as the sole control of FFT backend selection. If I have to restart my IPython session just because I forgot to set the right environment variable, I will be very unhappy.
Oh yes, I certainly agree it should not be the sole way to control it. It could, maybe, used to force it, and even then, I am not sure it is that useful.
For FFTs, I would probably keep the backend functions in a module-level list. On import, the package would try to import the backends it knows could be bundled in scipy.fftpack and insert them into the list. Probably, these would just be the optimized versions; the default FFTPACK versions would be kept separate. If an import fails, it would be a good idea to format the traceback into a string and store it in an accessible location for debugging unintentional ImportErrors. Each API function (e.g. rfft()) would check its list for an optimized implementation and use it or else fall back to the default. Each implementation module (e.g. scipy.fftpack._fftw3, or whatever you have named them; I haven't reviewed your code, yet) would have an explicit registration function that puts its implementations (all or a subset, e.g. _fftw3.register() or _fftw3.register('fft', 'rfft')) at the top of the lists
Registration aside, that's more or less what I have done so far.
handle power-of-two only implementations. This is probably the only real special case we have to handle, so we can probably do it explicitly instead of coming up with an overly generic solution.
I thought about changing the C Api to return an error code for invalid input, and writing a python wrapper which calls the default backend when an error is returned. This way, I can treat any kind of error without too much burden. cheers, David