Re: [Numpy-discussion] ndarray.T2 for 2D transpose
On Fri, Apr 8, 2016 at 4:04 PM Alan Isaac wrote:
> On 4/8/2016 5:13 PM, Nathaniel Smith wrote:
> > he doesn't want 2d matrices, he wants
> > tools that make it easy to work with stacks of 2d matrices stored in
> > 2-or-more-dimensional arrays.
>
>
> Like `map`?
>
> Alan Isaac
>
>
Sorry if there's any misunderstanding here.
Map doesn't really help much. That'd only be good for dealing with three
dimensional cases and you'd get a list of arrays, not a view with the
appropriate
axes swapped.
np.einsum('...ji', a)
np.swapaxes(a, -1, -2)
np.rollaxis(a, -1, -2)
all do the right thing, but they are all fairly verbose for such a simple
operation.
Here's a simple example of when such a thing would be useful.
With 2D arrays you can write
a.dot(b.T)
If you want to have that same operation follow the existing gufunc
broadcasting
semantics you end up having to write one of the following
np.einsum('...ij,...kj', a, b)
a @ np.swapaxes(a, -1, -2)
a @ np.rollaxis(a, -1, -2)
None of those are very concise, and, when I look at them, I don't usually
think
"that does a.dot(b.T)."
If we introduced the T2 syntax, this would be valid:
a @ b.T2
It makes the intent much clearer. This helps readability even more when
you're
trying to put together something that follows a larger equation while still
broadcasting correctly.
Does this help make the use cases a bit clearer?
Best,
-Ian Henriksen
___
NumPy-Discussion mailing list
NumPy-Discussion@scipy.org
https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ndarray.T2 for 2D transpose
On 4/8/2016 5:13 PM, Nathaniel Smith wrote: he doesn't want 2d matrices, he wants tools that make it easy to work with stacks of 2d matrices stored in 2-or-more-dimensional arrays. Like `map`? Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ndarray.T2 for 2D transpose
On Fri, Apr 8, 2016 at 5:11 PM, Charles R Harris wrote: > > > On Fri, Apr 8, 2016 at 2:52 PM, wrote: > >> >> >> On Fri, Apr 8, 2016 at 3:55 PM, Charles R Harris < >> charlesr.har...@gmail.com> wrote: >> >>> >>> >>> On Fri, Apr 8, 2016 at 12:17 PM, Chris Barker >>> wrote: >>> On Fri, Apr 8, 2016 at 9:59 AM, Charles R Harris < charlesr.har...@gmail.com> wrote: > Apropos column/row vectors, I've toyed a bit with the idea of adding a > flag to numpy arrays to indicate that the last index is one or the other, > and maybe neither. > I don't follow this. wouldn't it ony be an issue for 1D arrays, rather than the "last index". Or maybe I'm totally missing the point. But anyway, are (N,1) and (1, N) arrays insufficient for representing column and row vectors for some reason? If not -- then we have a way to express a column or row vector, we just need an easier and more obvious way to create them. *maybe* we could have actual column and row vector classes -- they would BE regular arrays, with (1,N) or (N,1) dimensions, and act the same in every way except their __repr__. and we're provide handy factor functions for them. These were needed to complete the old Matrix class -- which is no longer needed now that we have @ (i.e. a 2D array IS a matrix) >>> >>> One problem with that approach is that `vrow @ vcol` has dimension 1 x >>> 1, which is not a scalar. >>> >> >> I think it's not supposed to be a scalar, if @ breaks on scalars >> >> `vrow @ vcol @ a >> > > It's supposed to be a scalar and the expression should be written `vrow @ > vcol * a`, although parens are probably desireable for clarity `(vrow @ > vcol) * a`. > if a is 1d or twod vcol, and vrow and vcol could also be 2d arrays (not a single row or col) this is just a part of a long linear algebra expression 1d dot 1d is different from vrow dot vcol A dot 1d is different from A dot vcol. There intentional differences in the linear algebra behavior of 1d versus a col or row vector. One of those is dropping the extra dimension. We are using this a lot to switch between 1-d and 2-d cases. And another great thing about numpy is that often code immediately generalizes from 1-d to 2d with just some tiny adjustments. (I haven't played with @ yet) I worry that making the 1-d arrays suddenly behave ambiguously as weird 1-d/2-d mixture will make code more inconsistent and more difficult to follow. shortcuts and variations of atleast_2d sound fine, but not implicitly Josef > > Chuck > > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ndarray.T2 for 2D transpose
On Fri, Apr 8, 2016 at 2:09 PM, Alan Isaac wrote: > On 4/8/2016 4:28 PM, Ian Henriksen wrote: >> >> 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. > > > > This comment, like much of this thread, seems to long > for the matrix class but not want to actually use it. > > It seems pretty simple to me: if you want everything > forced to 2d, always use the matrix class. If you want > to use arrays, they work nicely now, and they work > as expected once you understand what you are > working with. (I.e., *not* matrices.) Note the word "broadcasting" -- he doesn't want 2d matrices, he wants tools that make it easy to work with stacks of 2d matrices stored in 2-or-more-dimensional arrays. -n -- Nathaniel J. Smith -- https://vorpus.org ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ndarray.T2 for 2D transpose
On Fri, Apr 8, 2016 at 2:52 PM, wrote: > > > On Fri, Apr 8, 2016 at 3:55 PM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> >> >> On Fri, Apr 8, 2016 at 12:17 PM, Chris Barker >> wrote: >> >>> On Fri, Apr 8, 2016 at 9:59 AM, Charles R Harris < >>> charlesr.har...@gmail.com> wrote: >>> Apropos column/row vectors, I've toyed a bit with the idea of adding a flag to numpy arrays to indicate that the last index is one or the other, and maybe neither. >>> >>> I don't follow this. wouldn't it ony be an issue for 1D arrays, rather >>> than the "last index". Or maybe I'm totally missing the point. >>> >>> But anyway, are (N,1) and (1, N) arrays insufficient for representing >>> column and row vectors for some reason? If not -- then we have a way to >>> express a column or row vector, we just need an easier and more obvious way >>> to create them. >>> >>> *maybe* we could have actual column and row vector classes -- they would >>> BE regular arrays, with (1,N) or (N,1) dimensions, and act the same in >>> every way except their __repr__. and we're provide handy factor functions >>> for them. >>> >>> These were needed to complete the old Matrix class -- which is no longer >>> needed now that we have @ (i.e. a 2D array IS a matrix) >>> >> >> One problem with that approach is that `vrow @ vcol` has dimension 1 x 1, >> which is not a scalar. >> > > I think it's not supposed to be a scalar, if @ breaks on scalars > > `vrow @ vcol @ a > It's supposed to be a scalar and the expression should be written `vrow @ vcol * a`, although parens are probably desireable for clarity `(vrow @ vcol) * a`. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ndarray.T2 for 2D transpose
On 4/8/2016 4:28 PM, Ian Henriksen wrote: 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. This comment, like much of this thread, seems to long for the matrix class but not want to actually use it. It seems pretty simple to me: if you want everything forced to 2d, always use the matrix class. If you want to use arrays, they work nicely now, and they work as expected once you understand what you are working with. (I.e., *not* matrices.) Btw, numpy.outer(a, b) produces an outer product. This may be off topic, but it seemed to me that some of the discussion overlooks this. I suggest that anyone who thinks numpy is falling short in this area point out how Mma has addressed this shortcoming. Wolfram will never be accused of a reluctance to add functions when there is a perceived need ... Cheers, Alan Isaac ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ndarray.T2 for 2D transpose
On Fri, Apr 8, 2016 at 3:55 PM, Charles R Harris wrote: > > > On Fri, Apr 8, 2016 at 12:17 PM, Chris Barker > wrote: > >> On Fri, Apr 8, 2016 at 9:59 AM, Charles R Harris < >> charlesr.har...@gmail.com> wrote: >> >>> Apropos column/row vectors, I've toyed a bit with the idea of adding a >>> flag to numpy arrays to indicate that the last index is one or the other, >>> and maybe neither. >>> >> >> I don't follow this. wouldn't it ony be an issue for 1D arrays, rather >> than the "last index". Or maybe I'm totally missing the point. >> >> But anyway, are (N,1) and (1, N) arrays insufficient for representing >> column and row vectors for some reason? If not -- then we have a way to >> express a column or row vector, we just need an easier and more obvious way >> to create them. >> >> *maybe* we could have actual column and row vector classes -- they would >> BE regular arrays, with (1,N) or (N,1) dimensions, and act the same in >> every way except their __repr__. and we're provide handy factor functions >> for them. >> >> These were needed to complete the old Matrix class -- which is no longer >> needed now that we have @ (i.e. a 2D array IS a matrix) >> > > One problem with that approach is that `vrow @ vcol` has dimension 1 x 1, > which is not a scalar. > I think it's not supposed to be a scalar, if @ breaks on scalars `vrow @ vcol @ a Josef` > > Chuck > > ___ > NumPy-Discussion mailing list > NumPy-Discussion@scipy.org > https://mail.scipy.org/mailman/listinfo/numpy-discussion > > ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ndarray.T2 for 2D transpose
On Thu, Apr 7, 2016 at 4:04 PM Stéfan van der Walt wrote: > On 7 April 2016 at 11:17, Chris Barker 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
Re: [Numpy-discussion] ndarray.T2 for 2D transpose
On Fri, Apr 8, 2016 at 12:17 PM, Chris Barker wrote: > On Fri, Apr 8, 2016 at 9:59 AM, Charles R Harris < > charlesr.har...@gmail.com> wrote: > >> Apropos column/row vectors, I've toyed a bit with the idea of adding a >> flag to numpy arrays to indicate that the last index is one or the other, >> and maybe neither. >> > > I don't follow this. wouldn't it ony be an issue for 1D arrays, rather > than the "last index". Or maybe I'm totally missing the point. > > But anyway, are (N,1) and (1, N) arrays insufficient for representing > column and row vectors for some reason? If not -- then we have a way to > express a column or row vector, we just need an easier and more obvious way > to create them. > > *maybe* we could have actual column and row vector classes -- they would > BE regular arrays, with (1,N) or (N,1) dimensions, and act the same in > every way except their __repr__. and we're provide handy factor functions > for them. > > These were needed to complete the old Matrix class -- which is no longer > needed now that we have @ (i.e. a 2D array IS a matrix) > One problem with that approach is that `vrow @ vcol` has dimension 1 x 1, which is not a scalar. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ndarray.T2 for 2D transpose
On Fri, Apr 8, 2016 at 9:59 AM, Charles R Harris wrote: > Apropos column/row vectors, I've toyed a bit with the idea of adding a > flag to numpy arrays to indicate that the last index is one or the other, > and maybe neither. > I don't follow this. wouldn't it ony be an issue for 1D arrays, rather than the "last index". Or maybe I'm totally missing the point. But anyway, are (N,1) and (1, N) arrays insufficient for representing column and row vectors for some reason? If not -- then we have a way to express a column or row vector, we just need an easier and more obvious way to create them. *maybe* we could have actual column and row vector classes -- they would BE regular arrays, with (1,N) or (N,1) dimensions, and act the same in every way except their __repr__. and we're provide handy factor functions for them. These were needed to complete the old Matrix class -- which is no longer needed now that we have @ (i.e. a 2D array IS a matrix) Note: this is not very well thought out! -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R(206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception chris.bar...@noaa.gov ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ndarray.T2 for 2D transpose
On 7 April 2016 at 15:03, Stéfan van der Walt wrote: > 4) x @ colvec(x) -- gives an error, but perhaps this should work and > be equivalent to np.dot(colvec(x), rowvec(x)) ? Sorry, that should have been 4) colvec(x) @ x Stéfan ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
Re: [Numpy-discussion] ndarray.T2 for 2D transpose
On Thu, Apr 7, 2016 at 4:03 PM, Stéfan van der Walt wrote: > On 7 April 2016 at 11:17, Chris Barker 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). > Apropos column/row vectors, I've toyed a bit with the idea of adding a flag to numpy arrays to indicate that the last index is one or the other, and maybe neither. Chuck ___ NumPy-Discussion mailing list NumPy-Discussion@scipy.org https://mail.scipy.org/mailman/listinfo/numpy-discussion
