On Wed, Oct 29, 2014 at 9:48 AM, Eelco Hoogendoorn < 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> > wrote: > >> Eelco Hoogendoorn <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 >> http://mail.scipy.org/mailman/listinfo/numpy-discussion >> > > > _______________________________________________ > NumPy-Discussion mailing list > 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
