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 stefan.o...@gmail.com 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 n...@pobox.com wrote: On 28 Oct 2014 18:34, Stefan Otte stefan.o...@gmail.com 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
Re: [Numpy-discussion] Choosing between NumPy and SciPy functions
Stefan van der Walt ste...@sun.ac.za writes: On 2014-10-27 15:26:58, D. Michael McFarland dm...@dmmcf.net 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] 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 dm...@dmmcf.net wrote: Stefan van der Walt ste...@sun.ac.za writes: On 2014-10-27 15:26:58, D. Michael McFarland dm...@dmmcf.net 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
On Fri, Oct 31, 2014 at 11:07 AM, Benjamin Root ben.r...@ou.edu 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 dm...@dmmcf.net wrote: Stefan van der Walt ste...@sun.ac.za writes: On 2014-10-27 15:26:58, D. Michael McFarland dm...@dmmcf.net 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
On Fri, Oct 31, 2014 at 3:07 PM, Benjamin Root ben.r...@ou.edu 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
