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 < kirillbalunov@gmail.com> wrote:
вт, 25 июн. 2019 г. в 21:20, Cameron Blocker < cameronjblocker@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