Re: [Numpydiscussion] Numpy BoF at SciPy 2014  quick report
Having just reread the PEP I'm concerned that this proposal leaves at least one major (?) trap for naive users, namely x = np.array([1, 10]) print X.T@x which will print 101, not [[1, 10], [10, 100]]
Yes, I know why this is happening but it's still a problem  the user said, "I'm thinking matrices" when they wrote @ but the x.T had done the "wrong" thing before the @ kicked in. And yes, a savvy user would have written x = np.ones([[1, 10]]) (but then np.dot(x, x.T) isn't a scalar).
This is the way things are at present, but with the new @ syntax coming in I think we should consider fixing it.
I can think of three possibilities: 1. Leave this as a trap for the unwary, and a reason for people to stick to np.matrix (np.matrix([1, 10]) behaves "correctly") 2. Make x.T a syntax error for 1D arrays. It's a noop and IMHO a trap. 3. Make x.T promote the shape == (2,) array to (1, 2) and return a (2, 1) array. This may be too magic, but it's my preferred solution.
R
Implementation of @ (matrix multiplication)
 will be in 3.5 ~ 18months
 no work started yet  have to make sure we do it.
 @@ was not added.
 The PEP for numpy is welldefined. Not much thinking to be done. (Good for a sprint)
On Do, 20140717 at 09:48 0400, Robert Lupton the Good wrote:
Having just reread the PEP I'm concerned that this proposal leaves at least one major (?) trap for naive users, namely x = np.array([1, 10]) print X.T@x which will print 101, not [[1, 10], [10, 100]]
Yes, I know why this is happening but it's still a problem  the user said, "I'm thinking matrices" when they wrote @ but the x.T had done the "wrong" thing before the @ kicked in. And yes, a savvy user would have written x = np.ones([[1, 10]]) (but then np.dot(x, x.T) isn't a scalar).
This is the way things are at present, but with the new @ syntax coming in I think we should consider fixing it.
I can think of three possibilities:
 Leave this as a trap for the unwary, and a reason for people to stick to np.matrix (np.matrix([1, 10]) behaves "correctly")
 Make x.T a syntax error for 1D arrays. It's a noop and IMHO a trap.
 Make x.T promote the shape == (2,) array to (1, 2) and return a (2, 1) array. This may be too magic, but it's my preferred solution.
Making it a warning may be another option. Changing `.T` to promote to 2d (also maybe to actually only transpose the last two axes for higher D arrays), could be nice, but getting there might take quite a long FutureWarning or even Error > new feature cycle...
 Sebastian
R
Implementation of @ (matrix multiplication)
 will be in 3.5 ~ 18months
 no work started yet  have to make sure we do it.
 @@ was not added.
 The PEP for numpy is welldefined. Not much thinking to be done. (Good for a sprint)
NumPyDiscussion mailing list NumPyDiscussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpydiscussion
On Fri, Jul 18, 2014 at 9:03 AM, Sebastian Berg sebastian@sipsolutions.net wrote:
On Do, 20140717 at 09:48 0400, Robert Lupton the Good wrote:
Having just reread the PEP I'm concerned that this proposal leaves at least one major (?) trap for naive users, namely x = np.array([1, 10]) print X.T@x which will print 101, not [[1, 10], [10, 100]]
Yes, I know why this is happening but it's still a problem  the user said, "I'm thinking matrices" when they wrote @ but the x.T had done the "wrong" thing before the @ kicked in. And yes, a savvy user would have written x = np.ones([[1, 10]]) (but then np.dot(x, x.T) isn't a scalar).
This is the way things are at present, but with the new @ syntax coming in I think we should consider fixing it.
I can think of three possibilities: 1. Leave this as a trap for the unwary, and a reason for people to stick to np.matrix (np.matrix([1, 10]) behaves "correctly") 2. Make x.T a syntax error for 1D arrays. It's a noop and IMHO a trap. 3. Make x.T promote the shape == (2,) array to (1, 2) and return a (2, 1) array. This may be too magic, but it's my preferred solution.
Making it a warning may be another option. Changing `.T` to promote to 2d (also maybe to actually only transpose the last two axes for higher D arrays), could be nice, but getting there might take quite a long FutureWarning or even Error > new feature cycle...
Hmm, just the other day I wrote some code that relies on the current behavior. I was writing a function that could work both on 3vectors and arrays of 3vectors. To unpack the input into the separate components, I did:
x, y, z = vector.T
Which works correctly whether `vector` is shaped (3,) or (N, 3).
On Fri, Jul 18, 2014 at 2:03 AM, Sebastian Berg sebastian@sipsolutions.net wrote:
On Do, 20140717 at 09:48 0400, Robert Lupton the Good wrote:
Having just reread the PEP I'm concerned that this proposal leaves at
least one major (?) trap for naive users, namely
x = np.array([1, 10]) print X.T@x
which will print 101, not [[1, 10], [10, 100]]
Yes, I know why this is happening but it's still a problem  the user
said, "I'm thinking matrices" when they wrote @ but the x.T had done the "wrong" thing before the @ kicked in. And yes, a savvy user would have written x = np.ones([[1, 10]]) (but then np.dot(x, x.T) isn't a scalar).
This is the way things are at present, but with the new @ syntax coming
in I think we should consider fixing it.
I can think of three possibilities: 1. Leave this as a trap for the unwary, and a reason for people to
stick to np.matrix (np.matrix([1, 10]) behaves "correctly")
2. Make x.T a syntax error for 1D arrays. It's a noop and IMHO
a trap.
3. Make x.T promote the shape == (2,) array to (1, 2) and return a
(2, 1) array. This may be too magic, but it's my preferred solution.
Making it a warning may be another option. Changing `.T` to promote to 2d (also maybe to actually only transpose the last two axes for higher D arrays), could be nice, but getting there might take quite a long FutureWarning or even Error > new feature cycle...
I've toyed some with the idea of adding a flag bit for transpose of 1d arrays. It would flip with every transpose and be ignored for non 1d arrays. A bit of a hack, but would allow for a column/row vector distinction.
Chuck
On Fri, Jul 18, 2014 at 6:18 AM, Charles R Harris <charlesr.harris@gmail.com
wrote:
I've toyed some with the idea of adding a flag bit for transpose of 1d arrays. It would flip with every transpose and be ignored for non 1d arrays. A bit of a hack, but would allow for a column/row vector distinction.
very cool! I've thought for a while that one of the major things lacking from numpy.matrix was row and column vectors. To do linear algebra naturally, you really need those.
This may be a really lightweight way to get that  without the distinction between "arrays" and "matrixes", which I think we're trying to get rid of with the @ operator.
when would this flag be used?
 linear algebra operations (mostly @  anything else?)
 broadcasting???
neat idea, anyway.
CHB
On 7/18/2014 4:03 AM, Sebastian Berg wrote:
Changing `.T` to promote to 2d (also maybe to actually only transpose the last two axes for higher D arrays), could be nice, but getting there might take quite a long FutureWarning or even Error > new feature cycle.
Considering the extent of implied breakage, I hope this will not be considered. Also, there are already nice ways to add an axis (even optionally, with `atleast_2d`).
I think having `.T` as a noop on a 1d array is correct behavior. I would not change it. However I can understand preferring an error. (Mathematica considers it an error.)
Alan Isaac
participants (6)

Alan G Isaac

Charles R Harris

Chris Barker

Robert Kern

Robert Lupton the Good

Sebastian Berg