[Numpy-discussion] FFTS for numpy's FFTs (was: Re: Choosing between NumPy and SciPy functions)

Eelco Hoogendoorn hoogendoorn.eelco at gmail.com
Wed Oct 29 05:48:05 EDT 2014


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

On Tue, Oct 28, 2014 at 6:21 PM, Sturla Molden <sturla.molden at gmail.com>
wrote:

> 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 pros
> > 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.
>
> Sturla
>
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at scipy.org
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20141029/60fc6f8c/attachment.html>


More information about the NumPy-Discussion mailing list