[Numpy-discussion] Syntax Improvement for Array Transpose

Sun Jun 23 17:27:51 EDT 2019

On Sun, 2019-06-23 at 17:12 -0400, Marten van Kerkwijk wrote:
> Hi All,
> 
> I'd love to have `.T` mean the right thing, and am happy that people
> are suggesting it after I told Steward this was likely off-limits
> (which, in fairness, did seem to be the conclusion when we visited
> this before...). But is there something we can do to make it possible
> to use it already but ensure that code on previous numpy versions
> breaks? (Or works, but that seems impossible...)
> 
> For instance, in python2, one had `from __future__ import division
> (etc.); could we have, e.g., a `from numpy.__future__ import
> matrix_transpose`, which, when imported, implied that `.T` just did
> the right thing without any warning? (Obviously, since that
> __future__.matrix_transpose wouldn't exist on older versions of
> numpy, it would correctly break the code when used with those.)
> 

If I remember correctly, this is actually possible but hacky. So it
would probably be nicer to not go there. But yes, you are right, that
would mean that we practically limit `.T` to 2-D arrays for at least 2
years.

> Also, a bit more towards the original request in the PR of a
> hermitian transpose, if we're trying to go for `.T` eventually having
> the obvious meaning, should we directly move towards also having `.H`
> as a short-cut for `.T.conj()`? We could even expose that only with
> the above future import - otherwise, the risk of abuse of `.T` would
> only grow...

This opens the general question of how many and which attributes we
actually want on ndarray. My first gut reaction is that I am -0 on it,
but OTOH, for some math it is very nice and not a huge amount of
clutter...

> 
> Finally, on the meaning of `.T` for 1-D arrays, the sensible choices
> would seem to (1) error; or (2) change shape to `(n, 1)`. Since while
> writing this sentence I changed my preference twice, I guess I should
> go for erroring (I think we need a separate solution for easily
> making stacks of row/column vectors).

Probably an error is good, which is nice, because we can just tag on a
warning and not worry about it for a while ;).

> 
> All the best,
> 
> Marten
> 
> On Sun, Jun 23, 2019 at 4:37 PM Sebastian Berg <
> sebastian at sipsolutions.net> wrote:
> > On Sun, 2019-06-23 at 19:51 +0000, Hameer Abbasi wrote:
> > > +1 for this. I have often seen (and sometimes written) code that
> > does
> > > this automatically, and it is a common mistake.
> > 
> > Yeah, likely worth a short. I doubt many uses for the n-dimensional
> > axis transpose, so maybe a futurewarning approach can work. If not,
> > I
> > suppose the solution is the deprecation for ndim != 2.
> > 
> > Another point about the `.T` is the 1-dimensional case, which
> > commonly
> > causes confusion. If we do something here, should think about that
> > as
> > well.
> > 
> > - Sebastian
> > 
> > 
> > > 
> > > However, we will need some way to filter for intent, as the
> > people
> > > who write this code are the ones who didn’t read docs on it at
> > the
> > > time, and so there might be a fair amount of noise even if it
> > fixes
> > > their code.
> > > 
> > > I also agree that a transpose of an array with ndim > 2 doesn’t
> > make
> > > sense without specifying the order, at least for the applications
> > I
> > > have seen so far.
> > > 
> > > Get Outlook for iOS
> > >  
> > > From: NumPy-Discussion <
> > > numpy-discussion-bounces+einstein.edison=gmail.com at python.org> on
> > > behalf of Eric Wieser <wieser.eric+numpy at gmail.com>
> > > Sent: Sunday, June 23, 2019 9:24 PM
> > > To: Discussion of Numerical Python
> > > Subject: Re: [Numpy-discussion] Syntax Improvement for Array
> > > Transpose
> > >  
> > > This might be contentious, but I wonder if, with a long enough
> > > deprecation cycle, we can change the meaning of .T. That would
> > look
> > > like:
> > > 
> > > * Emit a future warning on `more_than_2d.T` with a message like
> > "in
> > > future .T will transpose just the last two dimensions, not all
> > > dimensions. Use are.transpose() if transposing all {n} dimensions
> > is
> > > deliberate"
> > > * Wait 5 releases or so, see how many matches Google / GitHub has
> > for
> > > this warning.
> > > * If the impact is minimal, change .T
> > > * If the impact is large, change to a deprecation warning
> > > 
> > > An argument for this approach: a good amount of code I've seen in
> > the
> > > wild already assumes T is a 2d transpose, and as a result does
> > not
> > > work correctly when called with stacks of arrays. Changing T
> > might
> > > fix this broken code automatically.
> > > 
> > > If the change would be too intrusive, then keeping the
> > deprecation
> > > warning at least prevents new users deliberately using .T for >2d
> > > transposes, which is possibly valuable for readers.
> > > 
> > > Eric
> > > 
> > > 
> > > On Sun, Jun 23, 2019, 12:05 Stewart Clelland <
> > > stewartclelland at gmail.com> wrote:
> > > > Hi All,
> > > > 
> > > > Based on discussion with Marten on github, I have a couple of
> > > > suggestions on syntax improvements on array transpose
> > operations.
> > > > 
> > > > First, introducing a shorthand for the Hermitian Transpose
> > > > operator. I thought "A.HT" might be a viable candidate.
> > > > 
> > > > Second, the adding an array method that operates like a normal
> > > > transpose. To my understanding,
> > > > "A.tranpose()" currently inverts the usual order of all
> > dimensions.
> > > > This may be useful in some applications involving tensors, but
> > is
> > > > not what I would usually assume a transpose on a multi-
> > dimensional
> > > > array would entail. I suggest a syntax of "A.MT" to indicate a
> > > > transpose of the last two dimensions by default, maybe with
> > > > optional arguments (i,j) to indicate which two dimensions to
> > > > transpose.
> > > > 
> > > > I'm new to this mailing list format, hopefully I'm doing this
> > right
> > > > :)
> > > > 
> > > > Thanks,
> > > > Stew
> > > > _______________________________________________
> > > > NumPy-Discussion mailing list
> > > > NumPy-Discussion at python.org
> > > > https://mail.python.org/mailman/listinfo/numpy-discussion
> > > > 
> > > 
> > > _______________________________________________
> > > NumPy-Discussion mailing list
> > > NumPy-Discussion at python.org
> > > https://mail.python.org/mailman/listinfo/numpy-discussion
> > _______________________________________________
> > NumPy-Discussion mailing list
> > NumPy-Discussion at python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> 
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion at python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190623/f5323642/attachment.sig>