[Numpy-discussion] Syntax Improvement for Array Transpose

[Marten van Kerkwijk]

Hi Kirill, others,

Indeed, it is becoming long! That said, while initially I was quite charmed
by Eric's suggestion of deprecating and then changing `.T`, I think the
well-argued opposition to it has changed my opinion. Perhaps most
persuasive to me was Matthew's point just now that code (or a code snippet)
that worked on an old numpy should not silently do something different on a
new numpy (unless the old behaviour was a true bug, of course; but here
`.T` has always had a very well-defined meaning - even though you are right
that the documentation does not exactly lead the novice user away from
using it for matrix transpose! If someone has the time to open a PR that
clarifies it.........).

Note that I do agree with the sentiment that the deprecation/change would
likely expose some hidden bugs - and, as noted, it is hard to know where
those bugs are if they are hidden! (FWIW, I did find some in astropy's
coordinate implementation, which was initially written for scalar
coordinates where `.T` worked was just fine; as a result, astropy gained a
`matrix_transpose` utility function.) Still, it does not quite outweigh to
me the disadvantages enumerated.

One thing seems clear: if `.T` is out, that means `.H` is out as well (at
least as a matrix transpose, the only sensible meaning I think it has).
Having `.H` as a conjugate matrix transpose would just cause more confusion
about the meaning of `.T`.

For the names, my suggestion of lower-casing the M in the initial one,
i.e., `.mT` and `.mH`, so far seemed most supported (and I think we should
discuss *assuming* those would eventually involve not copying data; let's
not worry about implementation details).

So, specific items to confirm:

1) Is this a worthy addition? (certainly, their existence would reduce
confusion about `.T`... so far, my sense is tentative yes)

2) Are `.mT` and `.mH` indeed the consensus? [1]

3) What, if anything, should these new properties do for 0-d and 1-d
arrays: pass through, change shape, or error? (logically, I think *new*
properties should never emit warnings: either do something or error).
- In favour of pass-through: 1-d is a vector `dot` and `matmul` work fine
with this;
- In favour of shape change: "m" stands for matrix; can be generous on
input, but should be strict on output. After all, other code may not make
the same assumption that 1-d arrays are fine as row and column vectors.
- In favour of error: "m" stands for matrix and the input is not a matrix!
Let the user add np.newaxis in the right place, which will make the intent
clear.

All the best,

Marten

[1] Some sadness about mᵀ and mᴴ - but, then, there is
http://www.modernemacs.com/post/prettify-mode/

On Tue, Jun 25, 2019 at 4:17 PM Kirill Balunov <kirillbalunov at gmail.com>
wrote:

>
> вт, 25 июн. 2019 г. в 21:20, Cameron Blocker <cameronjblocker at gmail.com>:
>
>> It seems to me that the general consensus is that we shouldn't be
>> changing .T to do what we've termed matrix transpose or conjugate
>> transpose.
>>
>
> Reading through this thread, I can not say that I have the same opinion -
> at first, many looked positively at the possibility of change - `arr.T` to
> mean a transpose of the last two dimensions by default, and then people
> start discussing several different (albeit related) topics at once. So, I
> want to point out that it is rather difficult to follow what is currently
> discussed in this thread, probably because several different (albeit
> related) topics are being discussed at once. I would suggest at first
> discuss `arr.T` change, because other topics somewhat depend on that
> (`arr.MT`/`arr.CT`/`arr.H` and others).
>
> p.s:  Documentation about  `.T` shows only two examples, for 1d - to show
> that it works and for 2d case. Maybe it means something? (especially for
> new `numpy` users. )
>
> with kind regards,
> -gdg
> _______________________________________________
> 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/20190625/81e9e916/attachment-0001.html>