>> 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.ee...@gmail.com <mailto:hoogendoorn.ee...@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.mol...@gmail.com <mailto:sturla.mol...@gmail.com>> wrote:
Eelco Hoogendoorn <hoogendoorn.ee...@gmail.com
<mailto:hoogendoorn.ee...@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@scipy.org <mailto:NumPy-Discussion@scipy.org>
http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org <mailto:NumPy-Discussion@scipy.org>
http://mail.scipy.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
http://mail.scipy.org/mailman/listinfo/numpy-discussion
