[Numpy-discussion] FFTS for numpy's FFTs (was: Re: Choosing between NumPy and SciPy functions)
cournape at gmail.com
Wed Oct 29 06:33:08 EDT 2014
On Wed, Oct 29, 2014 at 9:48 AM, Eelco Hoogendoorn <
hoogendoorn.eelco at gmail.com> wrote:
> My point isn't about speed; its about the scope of numpy. typing
> np.fft.fft isn't more or less convenient than using some other symbol from
> the scientific python stack.
> Numerical algorithms should be part of the stack, for sure; but should
> they be part of numpy? I think its cleaner to have them in a separate
> package. Id rather have us discuss how to facilitate the integration of as
> many possible fft libraries with numpy behind a maximally uniform
> interface, rather than having us debate which fft library is 'best'.
I would agree if it were not already there, but removing it (like
Blas/Lapack) is out of the question for backward compatibility reason. Too
much code depends on it.
> On Tue, Oct 28, 2014 at 6:21 PM, Sturla Molden <sturla.molden at gmail.com>
>> Eelco Hoogendoorn <hoogendoorn.eelco at gmail.com> wrote:
>> > Perhaps the 'batteries included' philosophy made sense in the early
>> days of
>> > numpy; but given that there are several fft libraries with their own
>> > and cons, and that most numpy projects will use none of them at all, why
>> > should numpy bundle any of them?
>> Because sometimes we just need to compute a DFT, just like we sometimes
>> need to compute a sine or an exponential. It does that job perfectly well.
>> It is not always about speed. Just typing np.fft.fft(x) is convinient.
>> NumPy-Discussion mailing list
>> NumPy-Discussion at scipy.org
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the NumPy-Discussion