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

Pierre-Andre Noel noel.pierre.andre at gmail.com
Wed Oct 29 13:03:20 EDT 2014


 >> 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 agree with the above.

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

And I definitely agree with that too.

I think that numpy.fft should be left there in its current state 
(although perhaps as deprecated). Now scipy.fft should have a good 
generic algorithm as default, and easily allow for different 
implementations to be accessed through the same interface.

Pierre-André

On 10/29/2014 03:33 AM, David Cournapeau wrote:
>
>
> On Wed, Oct 29, 2014 at 9:48 AM, Eelco Hoogendoorn 
> <hoogendoorn.eelco at gmail.com <mailto: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.
>
> David
>
>
>     On Tue, Oct 28, 2014 at 6:21 PM, Sturla Molden
>     <sturla.molden at gmail.com <mailto:sturla.molden at gmail.com>> wrote:
>
>         Eelco Hoogendoorn <hoogendoorn.eelco at gmail.com
>         <mailto: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 <mailto:NumPy-Discussion at scipy.org>
>         http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
>
>     _______________________________________________
>     NumPy-Discussion mailing list
>     NumPy-Discussion at scipy.org <mailto: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/b717c4ac/attachment.html>


More information about the NumPy-Discussion mailing list