On Tue, Jun 25, 2019 at 11:02 PM Marten van Kerkwijk < m.h.vankerkw...@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. > > >
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
