On Thu, Apr 7, 2016 at 4:04 PM Stéfan van der Walt <stef...@berkeley.edu> wrote:
> On 7 April 2016 at 11:17, Chris Barker <chris.bar...@noaa.gov> wrote: > > np.col_vector(arr) > > > > which would be a synonym for np.reshape(arr, (-1,1)) > > > > would that make anyone happy? > > I'm curious to see use cases where this doesn't solve the problem. > > The most common operations that I run into: > > colvec = lambda x: np.c_[x] > > x = np.array([1, 2, 3]) > A = np.arange(9).reshape((3, 3)) > > > 1) x @ x (equivalent to x @ colvec(x)) > 2) A @ x (equivalent to A @ colvec(x), apart from the shape) > 3) x @ A > 4) x @ colvec(x) -- gives an error, but perhaps this should work and > be equivalent to np.dot(colvec(x), rowvec(x)) ? > > If (4) were changed, 1D arrays would mostly* be interpreted as row > vectors, and there would be no need for a rowvec function. And we > already do that kind of magic for (2). > > Stéfan > > * not for special case (1) > > Thinking this over a bit more, I think a broadcasting transpose that errors out on arrays that are less than 2D would cover the use cases of which I'm aware. The biggest things to me are having a broadcasting 2D transpose and having some form of transpose that doesn't silently pass 1D arrays through unchanged. Adding properties like colvec and rowvec has less bearing on the use cases I'm aware of, but they both provide nice syntax sugar for common reshape operations. It seems like it would cover all the needed cases for simplifying expressions involving matrix multiplication. It's not totally clear what the semantics should be for higher dimensional arrays or 2D arrays that already have a shape incompatible with the one desired. Best, -Ian Henriksen
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
