One other approach here that perhaps treads a little too close to np.matrix:
class MatrixOpWrapper:
def __init__(self, arr): # todo: accept axis arguments here?
self._array = arr # todo: assert that arr.ndim >= 2 / call atleast1d
@property
def T(self):
return linalg.transpose(self._array)
@property
def H(self):
return M(self._array.conj()).T
# add .I too?
M = MatrixOpWrapper
So M(arr).T instead of arr.mT, which has the benefit of not expanding the
number of ndarray members (and those needed by duck-types) further.
On Tue, 25 Jun 2019 at 14:50, Sebastian Berg <sebast...@sipsolutions.net>
wrote:
> On Tue, 2019-06-25 at 17:00 -0400, Marten van Kerkwijk wrote:
> > 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.
> >
>
> True, eventually switching is much more problematic than only
> deprecation, and yes, I guess the last step is likely forbidding.
>
> I do not care too much, but the at least the deprecation/warning does
> not seem too bad to me unless it is really widely used for high
> dimensions. Sure, it requires to touch code and may make it uglier, but
> a change requiring to touch a fair amount of scripts is not all that
> uncommon, especially if it can find some bugs (e.g. for me
> scipy.misc.factorial moving for example meant I had to change a lot of
> scripts, annoying but I could live with it).
>
> Although, I might prefer to spend our "force users to do annoying code
> changes" chips on better things. And I guess there may not be much of a
> point in a mere deprecation.
>
>
> > 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`.
> >
>
> I tend to agree, the only way that could work seems if T was deprecated
> for high dimensions.
>
>
> > 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).
>
> It would be a nice assumption, but as I said, I do see an issue with
> object array support. Which makes it likely that `.H` could only be
> supported on some dtypes (similar to `.real/.imag`).
> (Strictly speaking it would be possible to make a ConugateObject dtype
> and define casting for it, I have some doubt that the added complexity
> is worth it though). The no-copy conjugate is a cool idea but
> ultimately may be a bit too cool?
>
> > 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]
> >
>
> It is likely the only reasonable option, unless you make `H` object
> which does `arr_like**H` but I doubt that is a good idea.
>
> > 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).
> <snip>
> > Marten
> >
> > [1] Some sadness about mᵀ and mᴴ - but, then, there is
> > http://www.modernemacs.com/post/prettify-mode/
> >
>
> Hehe, you are using a block for Phonetic Extensions, and that block has
> a second H which looks the same on my font but is Cyrillic. Lucky us,
> we could make one of them for row vectors and the other for column
> vectors ;).
>
> - Sebastian
>
>
> > On Tue, Jun 25, 2019 at 4:17 PM Kirill Balunov <
> > kirillbalu...@gmail.com> wrote:
> > > вт, 25 июн. 2019 г. в 21:20, Cameron Blocker <
> > > cameronjbloc...@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@python.org
> > > https://mail.python.org/mailman/listinfo/numpy-discussion
> >
> > _______________________________________________
> > NumPy-Discussion mailing list
> > NumPy-Discussion@python.org
> > https://mail.python.org/mailman/listinfo/numpy-discussion
> _______________________________________________
> NumPy-Discussion mailing list
> NumPy-Discussion@python.org
> https://mail.python.org/mailman/listinfo/numpy-discussion
>
_______________________________________________
NumPy-Discussion mailing list
NumPy-Discussion@python.org
https://mail.python.org/mailman/listinfo/numpy-discussion
