Syntax Improvement for Array Transpose

classic Classic list List threaded Threaded
65 messages Options
1234
Reply | Threaded
Open this post in threaded view
|

Syntax Improvement for Array Transpose

sclel016
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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Syntax Improvement for Array Transpose

Eric Wieser
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 <[hidden email]> 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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Syntax Improvement for Array Transpose

Hameer Abbasi
+1 for this. I have often seen (and sometimes written) code that does this automatically, and it is a common mistake.

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.

 

From: NumPy-Discussion <numpy-discussion-bounces+einstein.edison=[hidden email]> on behalf of Eric Wieser <wieser.eric+[hidden email]>
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 <[hidden email]> 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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Syntax Improvement for Array Transpose

Sebastian Berg
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=[hidden email]> on
> behalf of Eric Wieser <[hidden email]>
> 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 <
> [hidden email]> 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
> > [hidden email]
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> >
>
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Syntax Improvement for Array Transpose

Andras Deak
On Sun, Jun 23, 2019 at 10:37 PM Sebastian Berg
<[hidden email]> wrote:
> 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.

Any chance that the n-dimensional transpose is being used in code
interfacing fortran/matlab and python? One thing the current
multidimensional transpose is good for is to switch between row-major
and column-major order. I don't know, however, whether this switch
actually has to be done often in code, in practice.

András
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Syntax Improvement for Array Transpose

Marten van Kerkwijk
In reply to this post by Sebastian Berg
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 <[hidden email]> 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=[hidden email]> on
> behalf of Eric Wieser <[hidden email]>
> 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 <
> [hidden email]> 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
> > [hidden email]
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> >
>
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Syntax Improvement for Array Transpose

Sebastian Berg
In reply to this post by Andras Deak
On Sun, 2019-06-23 at 23:03 +0200, Andras Deak wrote:

> On Sun, Jun 23, 2019 at 10:37 PM Sebastian Berg
> <[hidden email]> wrote:
> > 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.
>
> Any chance that the n-dimensional transpose is being used in code
> interfacing fortran/matlab and python? One thing the current
> multidimensional transpose is good for is to switch between row-major
> and column-major order. I don't know, however, whether this switch
> actually has to be done often in code, in practice.
>
I suppose there is a chance for that, to fix the order for returned
arrays (for input arrays you probably need to fix the memory order, so
that `copy(..., order="F")` or `np.ensure` is more likely what you
want.

Those users should be fine to switch over to `arr.transpose()`. The
question is mostly if it hits so much code that it is painful.

- Sebastian



> András
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Syntax Improvement for Array Transpose

Sebastian Berg
In reply to this post by Marten van Kerkwijk
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 <
> [hidden email]> 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=[hidden email]> on
> > > behalf of Eric Wieser <[hidden email]>
> > > 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 <
> > > [hidden email]> 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
> > > > [hidden email]
> > > > https://mail.python.org/mailman/listinfo/numpy-discussion
> > > >
> > >
> > > _______________________________________________
> > > NumPy-Discussion mailing list
> > > [hidden email]
> > > https://mail.python.org/mailman/listinfo/numpy-discussion
> > _______________________________________________
> > NumPy-Discussion mailing list
> > [hidden email]
> > https://mail.python.org/mailman/listinfo/numpy-discussion
>
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Syntax Improvement for Array Transpose

Eric Wieser
If I remember correctly, [numpy.future imports are] actually possible
but hacky. So it would probably be nicer to not go there.

There was some discussion of this at
https://stackoverflow.com/q/29905278/102441.
I agree with the conclusion we should not go there - in particular,
note that every builtin __future__ feature has been an
interpreter-level change, not an object-level change.
from __future__ import division changes the meaning of / not of int.__div__.
Framing the numpy change this way would mean rewriting Attribute(obj,
attr, Load) ast nodes to Call(np._attr_override, obj, attr), which is
obvious not interoperable with any other module wanting to do the same
thing.

This opens other unpleasant cans of worms about “builtin” modules that
perform attribute access:

Should getattr(arr, 'T') change behavior based on the module that calls it?
Should operator.itemgetter('T') change behavior ?

So I do not think we want to go down that road.

On Sun, 23 Jun 2019 at 14:28, Sebastian Berg <[hidden email]> wrote:

>
> 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 <
> > [hidden email]> 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=[hidden email]> on
> > > > behalf of Eric Wieser <[hidden email]>
> > > > 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 <
> > > > [hidden email]> 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
> > > > > [hidden email]
> > > > > https://mail.python.org/mailman/listinfo/numpy-discussion
> > > > >
> > > >
> > > > _______________________________________________
> > > > NumPy-Discussion mailing list
> > > > [hidden email]
> > > > https://mail.python.org/mailman/listinfo/numpy-discussion
> > > _______________________________________________
> > > NumPy-Discussion mailing list
> > > [hidden email]
> > > https://mail.python.org/mailman/listinfo/numpy-discussion
> >
> > _______________________________________________
> > NumPy-Discussion mailing list
> > [hidden email]
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> https://mail.python.org/mailman/listinfo/numpy-discussion
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Syntax Improvement for Array Transpose

Marten van Kerkwijk
I had not looked at any implementation (only remembered the nice idea of "importing from the future"), and looking at the links Eric shared, it seems that the only way this would work is, effectively, pre-compilation doing a `<codetext>.replace('.T', '._T_from_the_future')`, where you'd be hoping that there never is any other meaning for a `.T` attribute, for any class, since it is impossible to be sure a given variable is an ndarray. (Actually, a lot less implausible than for the case of numpy indexing discussed in the link...)

Anyway, what I had in mind was something along the lines of inside the `.T` code there being be a check on whether a particular future item was present in the environment. But thinking more, I can see that it is not trivial to get to know something about the environment in which the code that called you was written....

So, it seems there is no (simple) way to tell numpy that inside a given module you want `.T` to have the new behaviour, but still to warn if outside the module it is used in the old way (when risky)?

-- Marten

p.s. I'm somewhat loath to add new properties to ndarray, but `.T` and `.H` have such obvious and clear meaning to anyone dealing with (complex) matrices that I think it is worth it. See https://mail.python.org/pipermail/numpy-discussion/2019-June/079584.html for a list of options of attributes that we might deprecate "in exchange"...

All the best,

Marten


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Syntax Improvement for Array Transpose

Ilhan Polat
Please don't introduce more errors for 1D arrays. They are already very counter-intuitive for transposition and for other details not relevant to this issue. Emitting errors for such a basic operation is very bad for user experience. This already is the case with wildly changing slicing syntax. It would have made sense if 2D arrays were the default objects and 1D required extra effort to create. But it is the other way around. Hence a transpose operation is "expected" from it. This would kind of force all NumPy users to shift their code one tab further to accomodate for the extra try, catch blocks for "Oh wait, what if a 1D array comes in?" checks for the existence of transposability everytime I write down `.T` in the code.

Code example; I am continuously writing code involving lots of matrix products with inverses and transposes/hermitians (say, the 2nd eq., https://docs.scipy.org/doc/scipy/reference/generated/scipy.linalg.solve_continuous_are.html )
That means I have to check at least 4-6 matrices if any of them are transposable to make that equation go through.

The dot-H solution is actually my ideal choice but I get the point that the base namespace is already crowded. I am even OK with having `x.conj(T=True)` having a keyword for extra transposition so that I can get away with `x.conj(1)`; it doesn't solve the fundamental issue but at least gives some convenience.

Best,
ilhan









On Mon, Jun 24, 2019 at 3:11 AM Marten van Kerkwijk <[hidden email]> wrote:
I had not looked at any implementation (only remembered the nice idea of "importing from the future"), and looking at the links Eric shared, it seems that the only way this would work is, effectively, pre-compilation doing a `<codetext>.replace('.T', '._T_from_the_future')`, where you'd be hoping that there never is any other meaning for a `.T` attribute, for any class, since it is impossible to be sure a given variable is an ndarray. (Actually, a lot less implausible than for the case of numpy indexing discussed in the link...)

Anyway, what I had in mind was something along the lines of inside the `.T` code there being be a check on whether a particular future item was present in the environment. But thinking more, I can see that it is not trivial to get to know something about the environment in which the code that called you was written....

So, it seems there is no (simple) way to tell numpy that inside a given module you want `.T` to have the new behaviour, but still to warn if outside the module it is used in the old way (when risky)?

-- Marten

p.s. I'm somewhat loath to add new properties to ndarray, but `.T` and `.H` have such obvious and clear meaning to anyone dealing with (complex) matrices that I think it is worth it. See https://mail.python.org/pipermail/numpy-discussion/2019-June/079584.html for a list of options of attributes that we might deprecate "in exchange"...

All the best,

Marten

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Syntax Improvement for Array Transpose

Hameer Abbasi

Given that np.dot and np.matmul do the right thing for 1-D arrays, I would be opposed to introducing an error as well.

 

From: NumPy-Discussion <numpy-discussion-bounces+einstein.edison=[hidden email]> on behalf of Ilhan Polat <[hidden email]>
Reply-To: Discussion of Numerical Python <[hidden email]>
Date: Monday, 24. June 2019 at 11:58
To: Discussion of Numerical Python <[hidden email]>
Subject: Re: [Numpy-discussion] Syntax Improvement for Array Transpose

 

Please don't introduce more errors for 1D arrays. They are already very counter-intuitive for transposition and for other details not relevant to this issue. Emitting errors for such a basic operation is very bad for user experience. This already is the case with wildly changing slicing syntax. It would have made sense if 2D arrays were the default objects and 1D required extra effort to create. But it is the other way around. Hence a transpose operation is "expected" from it. This would kind of force all NumPy users to shift their code one tab further to accomodate for the extra try, catch blocks for "Oh wait, what if a 1D array comes in?" checks for the existence of transposability everytime I write down `.T` in the code.

 

Code example; I am continuously writing code involving lots of matrix products with inverses and transposes/hermitians (say, the 2nd eq., https://docs.scipy.org/doc/scipy/reference/generated/scipy.linalg.solve_continuous_are.html )

That means I have to check at least 4-6 matrices if any of them are transposable to make that equation go through.

 

The dot-H solution is actually my ideal choice but I get the point that the base namespace is already crowded. I am even OK with having `x.conj(T=True)` having a keyword for extra transposition so that I can get away with `x.conj(1)`; it doesn't solve the fundamental issue but at least gives some convenience.

 

Best,

ilhan

 

 

 

 

 

 

 

 

 

On Mon, Jun 24, 2019 at 3:11 AM Marten van Kerkwijk <[hidden email]> wrote:

I had not looked at any implementation (only remembered the nice idea of "importing from the future"), and looking at the links Eric shared, it seems that the only way this would work is, effectively, pre-compilation doing a `<codetext>.replace('.T', '._T_from_the_future')`, where you'd be hoping that there never is any other meaning for a `.T` attribute, for any class, since it is impossible to be sure a given variable is an ndarray. (Actually, a lot less implausible than for the case of numpy indexing discussed in the link...)

 

Anyway, what I had in mind was something along the lines of inside the `.T` code there being be a check on whether a particular future item was present in the environment. But thinking more, I can see that it is not trivial to get to know something about the environment in which the code that called you was written....

 

So, it seems there is no (simple) way to tell numpy that inside a given module you want `.T` to have the new behaviour, but still to warn if outside the module it is used in the old way (when risky)?

 

-- Marten

 

p.s. I'm somewhat loath to add new properties to ndarray, but `.T` and `.H` have such obvious and clear meaning to anyone dealing with (complex) matrices that I think it is worth it. See https://mail.python.org/pipermail/numpy-discussion/2019-June/079584.html for a list of options of attributes that we might deprecate "in exchange"...

 

All the best,

 

Marten

 

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________ NumPy-Discussion mailing list [hidden email] https://mail.python.org/mailman/listinfo/numpy-discussion


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Syntax Improvement for Array Transpose

Marten van Kerkwijk
Dear Hameer, Ilhan,

Just to be sure: for a 1-d array, you'd both consider `.T` giving a shape of `(n, 1)` the right behaviour? I.e., it should still change from what it is now - which is to leave the shape at `(n,)`.

Your argument about `dot` and `matmul` having similar behaviour certainly adds weight (but then, as I wrote before, my opinion on this changes by the second, so I'm very happy to defer to others who have a clearer sense of what is the right thing to do here!).

I think my main worry now is how to get to be able to use a new state without having to wait 4..6 releases...

All the best,

Marten

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Syntax Improvement for Array Transpose

Hameer Abbasi
Hello Marten,

I was suggesting not changing the shape at all, since dot/matmul/solve do the right thing already in such a case.

In my proposal, only for ndim >=2 do we switch the last two dimensions.

Ilhan is right that adding a special case for ndim=1 (error) adds programmer overhead, which is against the general philosophy of NumPy I feel.

 

From: NumPy-Discussion <numpy-discussion-bounces+einstein.edison=[hidden email]> on behalf of Marten van Kerkwijk <[hidden email]>
Sent: Monday, June 24, 2019 3:24 PM
To: Discussion of Numerical Python
Subject: Re: [Numpy-discussion] Syntax Improvement for Array Transpose
 
Dear Hameer, Ilhan,

Just to be sure: for a 1-d array, you'd both consider `.T` giving a shape of `(n, 1)` the right behaviour? I.e., it should still change from what it is now - which is to leave the shape at `(n,)`.

Your argument about `dot` and `matmul` having similar behaviour certainly adds weight (but then, as I wrote before, my opinion on this changes by the second, so I'm very happy to defer to others who have a clearer sense of what is the right thing to do here!).

I think my main worry now is how to get to be able to use a new state without having to wait 4..6 releases...

All the best,

Marten

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Syntax Improvement for Array Transpose

Todd
I think we need to do something about the 1D case.  I know from a strict mathematical standpoint it doesn't do anything, and philosophically we should avoid special cases, but I think the current solution leads to enough confusion and silently doing an unexpected thing that I think we need a better approach.

Personally I think it is a nonsensical operation and so should result in an exception, but at the very least I think it needs to raise a warning.

On Mon, Jun 24, 2019, 09:54 Hameer Abbasi <[hidden email]> wrote:
Hello Marten,

I was suggesting not changing the shape at all, since dot/matmul/solve do the right thing already in such a case.

In my proposal, only for ndim >=2 do we switch the last two dimensions.

Ilhan is right that adding a special case for ndim=1 (error) adds programmer overhead, which is against the general philosophy of NumPy I feel.

 

From: NumPy-Discussion <numpy-discussion-bounces+einstein.edison=[hidden email]> on behalf of Marten van Kerkwijk <[hidden email]>
Sent: Monday, June 24, 2019 3:24 PM
To: Discussion of Numerical Python
Subject: Re: [Numpy-discussion] Syntax Improvement for Array Transpose
 
Dear Hameer, Ilhan,

Just to be sure: for a 1-d array, you'd both consider `.T` giving a shape of `(n, 1)` the right behaviour? I.e., it should still change from what it is now - which is to leave the shape at `(n,)`.

Your argument about `dot` and `matmul` having similar behaviour certainly adds weight (but then, as I wrote before, my opinion on this changes by the second, so I'm very happy to defer to others who have a clearer sense of what is the right thing to do here!).

I think my main worry now is how to get to be able to use a new state without having to wait 4..6 releases...

All the best,

Marten
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Syntax Improvement for Array Transpose

Alan Isaac
In reply to this post by Hameer Abbasi
Points of reference:
Mathematica: https://reference.wolfram.com/language/ref/Transpose.html
Matlab: https://www.mathworks.com/help/matlab/ref/permute.html

Personally I would find any divergence between a.T and a.transpose()
to be rather surprising.

Cheers, Alan Isaac
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Syntax Improvement for Array Transpose

Todd
I think the corresponding MATLAB function/operation is this:



On Mon, Jun 24, 2019, 10:33 Alan Isaac <[hidden email]> wrote:
Points of reference:
Mathematica: https://reference.wolfram.com/language/ref/Transpose.html
Matlab: https://www.mathworks.com/help/matlab/ref/permute.html

Personally I would find any divergence between a.T and a.transpose()
to be rather surprising.

Cheers, Alan Isaac
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Syntax Improvement for Array Transpose

Stephan Hoyer-2
In reply to this post by sclel016
On Sun, Jun 23, 2019 at 10:05 PM Stewart Clelland <[hidden email]> 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.

I agree that short-hand for the Hermitian transpose would make sense, though I would try to stick with "A.H". It's one of the last reasons to prefer the venerable np.matrix. NumPy arrays already has loads of methods/properties, and this is a case (like @ for matrix multiplication) where the operator significantly improves readability: consider "(x.H @ M @ x) / (x.H @ x)" vs "(x.conj().T @ M @ x) / (x.conj().T @ x)" [1]. Nearly everyone who does linear algebra with complex numbers would find this useful.

If I recall correctly, the last time this came up, it was suggested that we might implement this with NumPy view as  a "complex conjugate" dtype rather than a memory copy. This would allow the operation to be essentially free. I find this very appealing, both due to symmetry with ".T" and because of the principle that properties should be cheap to compute.

So my tentative vote would be (1) yes, let's do the short-hand attribute, but (2) let's wait until we have a complex conjugate dtype that do this efficiently. My hope is that this should be relatively doable in a year or two after current dtype refactor/usability effect comes to fruition.

Best,
Stephan

[1]  I copied the first non-trivial example off the Wikipedia page for a Hermitian matrix:  https://en.wikipedia.org/wiki/Hermitian_matrix

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Syntax Improvement for Array Transpose

Todd
On Mon, Jun 24, 2019 at 11:00 AM Stephan Hoyer <[hidden email]> wrote:
On Sun, Jun 23, 2019 at 10:05 PM Stewart Clelland <[hidden email]> 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.

I agree that short-hand for the Hermitian transpose would make sense, though I would try to stick with "A.H". It's one of the last reasons to prefer the venerable np.matrix. NumPy arrays already has loads of methods/properties, and this is a case (like @ for matrix multiplication) where the operator significantly improves readability: consider "(x.H @ M @ x) / (x.H @ x)" vs "(x.conj().T @ M @ x) / (x.conj().T @ x)" [1]. Nearly everyone who does linear algebra with complex numbers would find this useful.

If I recall correctly, the last time this came up, it was suggested that we might implement this with NumPy view as  a "complex conjugate" dtype rather than a memory copy. This would allow the operation to be essentially free. I find this very appealing, both due to symmetry with ".T" and because of the principle that properties should be cheap to compute.

So my tentative vote would be (1) yes, let's do the short-hand attribute, but (2) let's wait until we have a complex conjugate dtype that do this efficiently. My hope is that this should be relatively doable in a year or two after current dtype refactor/usability effect comes to fruition.

Best,
Stephan

[1]  I copied the first non-trivial example off the Wikipedia page for a Hermitian matrix:  https://en.wikipedia.org/wiki/Hermitian_matrix


I would call it .CT or something like that, based on the term "Conjugate transpose".  Wikipedia redirects "Hermitian transpose" to "Conjugate transpose", and google has 49,800 results for "Hermitian transpose" vs 201,000 for "Conjugate transpose" (both with quotes).  So "Conjugate transpose" seems to be the more widely-known name.  Further, I think what a "Conjugate transpose" does is immediately obvious to someone who isn't already familiar with the term so long as they know what a "conjugate" and "transpose" are, while no one would be able to tell what a "Hermitian transpose" unless they are already familiar with the name.  So I have no problem calling it a "Hermitian transpose" somewhere in the docs, but I think the naming and documentation should focus on the "Conjugate transpose" term.

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Syntax Improvement for Array Transpose

Alan Isaac
In reply to this post by Todd
Iirc, that works only on (2-d) matrices.
Cheers, Alan Isaac


On 6/24/2019 10:45 AM, Todd wrote:
> I think the corresponding MATLAB function/operation is this:
>
> https://www.mathworks.com/help/matlab/ref/transpose.html

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
1234