[Numpy-discussion] Syntax Improvement for Array Transpose

[Ralf Gommers]

On Wed, Jun 26, 2019 at 3:56 AM Marten van Kerkwijk <
m.h.vankerkwijk at gmail.com> wrote:

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

Yes, this has been discussed in lots of detail before, also on this list
(as Nathaniel mentioned in the issue). I spent 10 minutes to try and find
it but that wasn't enough. I do think it's not necessarily my
responsibility though to dig up all the history here - that should be on
the proposers of a new feature ....

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

Honestly, I don't really want to be arguing against this (or even be forced
to spend time following along here). My main problem with this proposal
right now is that we've had this discussion multiple times, and it was
rejected with solid arguments after taking up a lot of time. Restarting
that discussion from scratch without considering the history feels wrong.
It's like a democracy voting on becoming a dictatorship repeatedly: you can
have a "no" vote several times, but if you rerun the vote often enough at
some point you'll get a "yes", and then it's a done deal.

I think this requires a serious write-up, as either a NEP or a GitHub issue
with a good set of cross-links and addressing all previous arguments.


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

A utility function in scipy.linalg would be a more low-API-impact approach
to addressing this.


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

Most linalg is 2-D, that's why numpy.matrix and scipy.sparse matrices are
2-D only. If it's a real worry for those 11 cases, you could just add some
comments or tests that prevent introducing bugs.

More importantly, your assumption that >2-D arrays are "stacks of matrices"
and that other usage is for "computer scientists" is arguably incorrect.
There are many use cases for 3-D and higher-dimensional arrays that are not
just "vectorized matrix math". As a physicist, I've done lots of work with
3-D and 4-D grids for everything from quantum physics to engineering
problems in semiconductor equipment. NumPy is great for that, and I've
never needed >=3-D linalg for any of it (and transposing is useful). So
please don't claim the physicial-scientist view for this:)

Cheers,
Ralf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190626/77cc5188/attachment-0001.html>