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 < > sebast...@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....@python.org> on > > > behalf of Eric Wieser <wieser.eric+nu...@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 < > > > stewartclell...@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@python.org > > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > > > > > > > > > _______________________________________________ > > > NumPy-Discussion mailing list > > > NumPy-Discussion@python.org > > > https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > > NumPy-Discussion mailing list > > NumPy-Discussion@python.org > > https://mail.python.org/mailman/listinfo/numpy-discussion > > _______________________________________________ > NumPy-Discussion mailing list > NumPy-Discussion@python.org > https://mail.python.org/mailman/listinfo/numpy-discussion
signature.asc
Description: This is a digitally signed message part
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion