On Tue, Jun 25, 2019 at 11:02 PM Marten van Kerkwijk < m.h.vankerkwijk@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
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. Cheers, Ralf
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.