On Mon, Oct 27, 2014 at 2:24 PM, Eelco Hoogendoorn < hoogendoorn.ee...@gmail.com> wrote:
> The same occurred to me when reading that question. My personal opinion is > that such functionality should be deprecated from numpy. I don't know who > said this, but it really stuck with me: but the power of numpy is first and > foremost in it being a fantastic interface, not in being a library. > > There is nothing more annoying than every project having its own array > type. The fact that the whole scientific python stack can so seamlessly > communicate is where all good things begin. > > In my opinion, that is what numpy should focus on; basic data structures, > and tools for manipulating them. Linear algebra is way too high level for > numpy imo, and used by only a small subsets of its 'matlab-like' users. > > When I get serious about linear algebra or ffts or what have you, id > rather import an extra module that wraps a specific library. > We are not always "getting serious" about linalg, just a quick call to pinv or qr or matrix_rank or similar doesn't necessarily mean we need a linalg library with all advanced options. "@" matrix operations and linear algebra are "basic" stuff. > > On Mon, Oct 27, 2014 at 2:26 PM, D. Michael McFarland <dm...@dmmcf.net> > wrote: > >> A recent post raised a question about differences in results obtained >> with numpy.linalg.eigh() and scipy.linalg.eigh(), documented at >> >> http://docs.scipy.org/doc/numpy/reference/generated/numpy.linalg.eigh.html#numpy.linalg.eigh >> and >> >> http://docs.scipy.org/doc/scipy/reference/generated/scipy.linalg.eigh.html#scipy.linalg.eigh >> , >> respectively. It is clear that these functions address different >> mathematical problems (among other things, the SciPy routine can solve >> the generalized as well as standard eigenproblems); I am not concerned >> here with numerical differences in the results for problems both should >> be able to solve (the author of the original post received useful >> replies in that thread). >> >> What I would like to ask about is the situation this illustrates, where >> both NumPy and SciPy provide similar functionality (sometimes identical, >> to judge by the documentation). Is there some guidance on which is to >> be preferred? I could argue that using only NumPy when possible avoids >> unnecessary dependence on SciPy in some code, or that using SciPy >> consistently makes for a single interface and so is less error prone. >> Is there a rule of thumb for cases where SciPy names shadow NumPy names? >> >> I've used Python for a long time, but have only recently returned to >> doing serious numerical work with it. The tools are very much improved, >> but sometimes, like now, I feel I'm missing the obvious. I would >> appreciate pointers to any relevant documentation, or just a summary of >> conventional wisdom on the topic. >> > Just as opinion as user: Most of the time I don't care and treat this just as different versions. For example in the linalg case, I use by default numpy.linalg and switch to scipy if I need the extras. pinv is the only one that I ever seriously compared. Some details are nicer, np.linalg.qr(x, mode='r') returns the reduced matrix instead of the full matrix as does scipy.linalg. np.linalg.pinv is faster but maybe slightly less accurate (or defaults that make it less accurate in corner cases). scipy often has more overhead (and isfinite check by default). I just checked, I didn't even know scipy.linalg also has an `inv`. One of my arguments for np.linalg would have been that it's easy to switch between inv and pinv. For fft I use mostly scipy, IIRC. (scipy's fft imports numpy's fft, partially?) Essentially, I don't care most of the time that there are different ways of doing essentially the same thing, but some better information about the differences would be useful. Josef > >> Regards, >> Michael >> _______________________________________________ >> 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
