[Numpy-discussion] Syntax Improvement for Array Transpose

[Marten van Kerkwijk]

Hi Ralf,

On Tue, Jun 25, 2019 at 6:31 PM Ralf Gommers <ralf.gommers at gmail.com> wrote:

>
>
> On Tue, Jun 25, 2019 at 11:02 PM Marten van Kerkwijk <
> m.h.vankerkwijk at gmail.com> wrote:
>
>>
>> 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).
>>
>
> For the record, this is not an implementation detail. It was the consensus
> before that `H` is a bad idea unless it returns a view just like `T`:
> https://github.com/numpy/numpy/issues/8882
>

Is there more than an issue in which Nathaniel rejecting it mentioning some
previous consensus? I was part of the discussion of the complex conjugate
dtype, but do not recall any consensus beyond a "wish to keep properties
simple". Certainly the "property does not do any calculation" rule seems
arbitrary; the only strict rule I would apply myself is that the
computation should not be able to fail (computationally, out-of-memory does
not count; that's like large integer overflow). So,  I'd definitely agree
with you if we were discussion a property `.I` for matrix inverse (and
indeed have said so in related issues). But for .H, not so much. Certainly
whoever wrote np.Matrix didn't seem to feel bound by it.

Note that for *matrix* transpose (as opposed to general axis reordering
with .tranpose()), I see far less use for what is returned being a writable
view. Indeed, for conjugate transpose, I would rather never allow writing
back even if it we had the conjugate dtype since one would surely get it
wrong (likely, `.conj()` would also return a read-only view, at least by
default; perhaps one should even go as far as only allowing
`a.view(conjugate-dtype)` as they way to get a writable view).


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

> I think `H` would be good to revisit *if* it can be made to return a
view. I think a tweak on `T` for >2-D input does not meet the bar for
inclusion.

Well, I guess it is obvious I disagree: I think this more than meets the
bar for inclusion. To me, this certainly is a much bigger deal that
something like oindex or vindex (which I do like).

Indeed, it would seem to me that if a visually more convenient way to do
(stacks of) matrix multiplication for numpy is good enough to warrant
changing the python syntax, then surely having a visually more convenient
standard way to do matrix transpose should not be considered off-limits for
ndarray; how often do you see a series matrix manipulations that does not
involve both multiplication and transpose?

It certainly doesn't seem to me much of an argument that someone previously
decided to use .T for a shortcut for the computer scientist idea of
transpose to not allow the mathematical/physical-scientist one - one I
would argue is guaranteed to be used much more.

The latter of course just repeats what many others have written above, but
since given that you call it a "tweak", perhaps it is worth backing up. For
astropy, a quick grep gives:

- 28 uses of the matrix_transpose function I wrote because numpy doesn't
have even a simple function for that and the people who wrote the original
code used the Matrix class which had the proper .T (but doesn't extend to
multiple dimensions; we might still be using it otherwise).

- 11 uses of .T,  all of which seem to be on 2-D arrays and are certainly
used as if they were matrix transpose (most are for fitting). Certainly,
all of these are bugs lying in waiting if the arrays ever get to be >2-D.

All the best,

Marten
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190625/d4b60088/attachment.html>