[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