Re: [Numpy-discussion] Choosing between NumPy and SciPy functions
On Fri, Oct 31, 2014 at 3:07 PM, Benjamin Root wrote: > Just to throw in my two cents here. I feel that sometimes, features are > tried out first elsewhere (possibly in scipy) and then brought down into > numpy after sufficient shakedown time. So, in some cases, I wonder if the > numpy version is actually more refined than the scipy version? Of course, > there is no way to know this from the documentation, which is a problem. > Didn't scipy have nanmean() for a while before Numpy added it in version > 1.8? Not that often, and these usually get actively deprecated eventually. Most duplications are of the form Stefan discusses. -- Robert Kern ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Choosing between NumPy and SciPy functions
On Fri, Oct 31, 2014 at 11:07 AM, Benjamin Root wrote: > Just to throw in my two cents here. I feel that sometimes, features are > tried out first elsewhere (possibly in scipy) and then brought down into > numpy after sufficient shakedown time. So, in some cases, I wonder if the > numpy version is actually more refined than the scipy version? Of course, > there is no way to know this from the documentation, which is a problem. > Didn't scipy have nanmean() for a while before Numpy added it in version > 1.8? > That's true for several functions in scipy.stats. And we have more deprecation in scipy.stats in favor of numpy pending. part of polynomials is another case, kind of. But I don't remember any other ones in my time. (There is also a reverse extension for scipy binned_stats based on the np.histogram code.) Josef > > Ben Root > > On Fri, Oct 31, 2014 at 10:26 AM, D. Michael McFarland > wrote: > >> Stefan van der Walt writes: >> >> > On 2014-10-27 15:26:58, D. Michael McFarland wrote: >> >> 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'm not sure if you've received an answer to your question so far. My >> > advice: use the SciPy functions. SciPy is often built on more extensive >> > Fortran libraries not available during NumPy compilation, and I am not >> > aware of any cases where a function in NumPy is faster or more extensive >> > than the equivalent in SciPy. >> >> The whole thread has been interesting reading (now that I've finally >> come back to it...got busy for a few days), but this is the sort of >> answer I was hoping for. Thank you. >> >> Best, >> 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
Re: [Numpy-discussion] Choosing between NumPy and SciPy functions
Just to throw in my two cents here. I feel that sometimes, features are tried out first elsewhere (possibly in scipy) and then brought down into numpy after sufficient shakedown time. So, in some cases, I wonder if the numpy version is actually more refined than the scipy version? Of course, there is no way to know this from the documentation, which is a problem. Didn't scipy have nanmean() for a while before Numpy added it in version 1.8? Ben Root On Fri, Oct 31, 2014 at 10:26 AM, D. Michael McFarland wrote: > Stefan van der Walt writes: > > > On 2014-10-27 15:26:58, D. Michael McFarland wrote: > >> 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'm not sure if you've received an answer to your question so far. My > > advice: use the SciPy functions. SciPy is often built on more extensive > > Fortran libraries not available during NumPy compilation, and I am not > > aware of any cases where a function in NumPy is faster or more extensive > > than the equivalent in SciPy. > > The whole thread has been interesting reading (now that I've finally > come back to it...got busy for a few days), but this is the sort of > answer I was hoping for. Thank you. > > Best, > 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
Re: [Numpy-discussion] Choosing between NumPy and SciPy functions
Stefan van der Walt writes: > On 2014-10-27 15:26:58, D. Michael McFarland wrote: >> 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'm not sure if you've received an answer to your question so far. My > advice: use the SciPy functions. SciPy is often built on more extensive > Fortran libraries not available during NumPy compilation, and I am not > aware of any cases where a function in NumPy is faster or more extensive > than the equivalent in SciPy. The whole thread has been interesting reading (now that I've finally come back to it...got busy for a few days), but this is the sort of answer I was hoping for. Thank you. Best, Michael ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] Generalize hstack/vstack --> stack; Block matrices like in matlab
To make the last point more concrete the implementation could look something like this (note that I didn't test it and that it still takes some work): def bmat(obj, ldict=None, gdict=None): return matrix(stack(obj, ldict, gdict)) def stack(obj, ldict=None, gdict=None): # the old bmat code minus the matrix calls if isinstance(obj, str): if gdict is None: # get previous frame frame = sys._getframe().f_back glob_dict = frame.f_globals loc_dict = frame.f_locals else: glob_dict = gdict loc_dict = ldict return _from_string(obj, glob_dict, loc_dict) if isinstance(obj, (tuple, list)): # [[A,B],[C,D]] arr_rows = [] for row in obj: if isinstance(row, N.ndarray): # not 2-d return concatenate(obj, axis=-1) else: arr_rows.append(concatenate(row, axis=-1)) return concatenate(arr_rows, axis=0) if isinstance(obj, N.ndarray): return obj I basically turned the old `bmat` into `stack` and removed the matrix calls. Best, Stefan On Wed, Oct 29, 2014 at 3:59 PM, Stefan Otte wrote: > Hey, > > there are several ways how to proceed. > > - My proposed solution covers the 80% case quite well (at least I use > it all the time). I'd convert the doctests into unittests and we're > done. > > - We could slightly change the interface to leave out the surrounding > square brackets, i.e. turning `stack([[a, b], [c, d]])` into > `stack([a, b], [c, d])` > > - We could extend it even further allowing a "filler value" for non > set values and a "shape" argument. This could be done later as well. > > - `bmat` is not really matrix specific. We could refactor `bmat` a bit > to use the same logic in `stack`. Except the `matrix` calls `bmat` and > `_from_string` are pretty agnostic to the input. > > I'm in favor of the first or last approach. The first: because it > already works and is quite simple. The last: because the logic and > tests of both `bmat` and `stack` would be the same and the feature to > specify a string representation of the block matrix is nice. > > > Best, > Stefan > > > > On Tue, Oct 28, 2014 at 7:46 PM, Nathaniel Smith wrote: >> On 28 Oct 2014 18:34, "Stefan Otte" wrote: >>> >>> Hey, >>> >>> In the last weeks I tested `np.asarray(np.bmat())` as `stack` >>> function and it works quite well. So the question persits: If `bmat` >>> already offers something like `stack` should we even bother >>> implementing `stack`? More code leads to more >>> bugs and maintenance work. (However, the current implementation is >>> only 5 lines and by using `bmat` which would reduce that even more.) >> >> In the long run we're trying to reduce usage of np.matrix and ideally >> deprecate it entirely. So yes, providing ndarray equivalents of matrix >> functionality (like bmat) is valuable. >> >> -n >> >> >> ___ >> 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
