![](https://secure.gravatar.com/avatar/764323a14e554c97ab74177e0bce51d4.jpg?s=120&d=mm&r=g)
On Mon, May 12, 2008 at 8:53 PM, David Cournapeau <david@ar.media.kyoto-u.ac.jp> wrote:
Robert Kern wrote:
Neither djbfft vs. fftw nor djbfft vs. MKL are definitive comparisons. Not everyone can use GPLed code or proprietary code.
I understand that, I was merely answering to the fact that djbfft is the fastest. We have fftpack for people who do not care so much about speed, no ? IOW, I understand there are people who care about speed, people who care about open source, and people who care about not depending on both GPL and proprietary code. We support all this, and can still do it without depending on djbfft. But do we need to satisfy all the combinations of the above ?
I'd drop FFTW and MKL support first before djbfft because they are not compatible with the scipy license. Perhaps this subsystem just needs to be redesigned. I think a lot of the complexity derives from the fact that we're doing the dispatching in C. If we moved the dispatching up to Python and just let external packages register themselves, we can probably save ourselves a substantial number of headaches. By separating the backend implementations, each can actually be unit-tested instead of integration-tested, and no one has to face a combinatorial explosion. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco