[SciPy-dev] Dropping djbfft ?

[Robert Kern]

On Mon, May 12, 2008 at 10:11 PM, Nathan Bell <wnbell at gmail.com> wrote:
> On Mon, May 12, 2008 at 9:44 PM, Robert Kern <robert.kern at gmail.com> wrote:
>  >  I'd drop FFTW and MKL support first before djbfft because they are not
>  >  compatible with the scipy license.
>
>  I don't see how this addresses David's argument.

Sure it does. He wants to reduce the number of combinations of
optional libraries to support. Dropping any one of them reduces that
number.

>  While being the "fastest BSD-compatible FFT for power of 2 problem
>  sizes" achieves a certain Pareto optimality, wouldn't it be more
>  productive to provide better support for actively maintained libraries
>  that are faster and more general?

Not if their licenses conflict with scipy's, no. I think it's a waste
of time to support optional backends instead of scipy itself. These
optional backends will always be second-class citizens since official
distributions won't (or shouldn't) include them. As with UMFPACK, I
think that optional components, particularly incompatibly-licensed
components, lead to more trouble than they are worth.

I'd drop djbfft, too, if we can move to a system where external
packages can register their implementations instead of having to build
everything in. Or if we could absorb djbfft like we did FFTPACK so it
is not an optional component.

>  How large is the djbfft + SciPy user base?

I don't think you'll ever get a confident answer to that question, for
any combination of "foo" + scipy. Speculating will get us nowhere.

-- 
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