[Numpy-discussion] Syntax Improvement for Array Transpose

[Marten van Kerkwijk]

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.)

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...

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).

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190623/cf1910be/attachment.html>