<div dir="ltr"><div>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.</div><div><br></div><div>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'.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Oct 28, 2014 at 6:21 PM, Sturla Molden <span dir="ltr"><<a href="mailto:sturla.molden@gmail.com" target="_blank">sturla.molden@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>Eelco Hoogendoorn <<a href="mailto:hoogendoorn.eelco@gmail.com">hoogendoorn.eelco@gmail.com</a>> wrote:<br>
<br>
> Perhaps the 'batteries included' philosophy made sense in the early days of<br>
> numpy; but given that there are several fft libraries with their own pros<br>
> and cons, and that most numpy projects will use none of them at all, why<br>
> should numpy bundle any of them?<br>
<br>
</span>Because sometimes we just need to compute a DFT, just like we sometimes<br>
need to compute a sine or an exponential. It does that job perfectly well.<br>
It is not always about speed. Just typing np.fft.fft(x) is convinient.<br>
<div class="HOEnZb"><div class="h5"><br>
Sturla<br>
<br>
_______________________________________________<br>
NumPy-Discussion mailing list<br>
<a href="mailto:NumPy-Discussion@scipy.org">NumPy-Discussion@scipy.org</a><br>
<a href="http://mail.scipy.org/mailman/listinfo/numpy-discussion" target="_blank">http://mail.scipy.org/mailman/listinfo/numpy-discussion</a><br>
</div></div></blockquote></div><br></div>