I've finally gone through the old discussion and finally got the counter-argument in one of the Dag Sverre's replies http://numpy-discussion.10968.n7.nabble.com/add-H-attribute-tp34474p34668.html
TL; DR I disagree with [...adding the .H attribute...] being forward looking, as > it explicitly creates a situation where code will break if .H becomes a > view > This actually makes perfect sense and a valid concern that I have not considered before. The remaining question is why we treat as if returning a view is a requirement. We have been using .conj().T and receiving the copies of the arrays since that day with equally inefficient code after many years. Then the discussion diverges to other things hence I am not sure where does this requirement come from. But I guess this part should be rehashed clearer until next time :) On Thu, Jun 27, 2019 at 12:03 AM Charles R Harris <charlesr.har...@gmail.com> wrote: > > > On Wed, Jun 26, 2019 at 2:18 PM Ralf Gommers <ralf.gomm...@gmail.com> > wrote: > >> >> >> On Wed, Jun 26, 2019 at 10:04 PM Kirill Balunov <kirillbalu...@gmail.com> >> wrote: >> >>> Only concerns #4 from Ilhan's list. >>> >>> ср, 26 июн. 2019 г. в 00:01, Ralf Gommers <ralf.gomm...@gmail.com>: >>> >>>> >>>> [....] >>>> >>>> Perhaps not full consensus between the many people with different >>>> opinions and interests. But for the first one, arr.T change: it's clear >>>> that this won't happen. >>>> >>> >>> To begin with, I must admit that I am not familiar with the accepted >>> policy of introducing changes to NumPy. But I find it quite >>> nonconstructive just to say - it will not happen. What then is the >>> point in the discussion? >>> >> >> There has been a *very* long discussion already, and several others on >> the same topic before. There are also long-standing ways of dealing with >> backwards compatibility - e.g. what Matthew said is not new, it's an agreed >> upon way of working. >> http://www.numpy.org/neps/nep-0023-backwards-compatibility.html lists >> some principles. That NEP is not yet accepted (it needs rework), but it >> gives a good idea of what does and does not go. >> >> >>> >>> >>>> Between Juan's examples of valid use, and what Stephan and Matthew >>>> said, there's not much more to add. We're not going to change correct code >>>> for minor benefits. >>>> >>> >>> I fully agree that any feature can find its use, valid or not is another >>> question. Juan did not present these examples, but I will allow myself >>> to assume that it is more correct to describe what is being done there as a >>> permutation, and not a transpose. In addition, in the very next >>> sentence, Juan adds that "These could be easily changed to .transpose() >>> (honestly they probably should!)" >>> >>> We're not going to change correct code for minor benefits. >>>> >>> >>> It's fair, I personally have no preferences in both cases, the most >>> important thing for me is that in the 2d case it works correctly. To be >>> honest, until today, I thought that `.T` will raise for` ndim > 2`. At >>> least that's what my experience told me. For example in >>> >>> Matlab - Error using .' Transpose on ND array is not defined. Use >>> PERMUTE instead. >>> >>> Julia - transpose not defined for Array(Float64, 3). Consider using >>> permutedims for higher-dimensional arrays. >>> >>> Sympy - raise ValueError("array rank not 2") >>> >>> Here, I agree with the authors that, to begin with, `transpose` is not >>> the best name, since in general it doesn’t fit as an any mathematical >>> definition (of course it will depend on what we take as an element) or a >>> definition from linear algebra. Thus the name `transpose` only leads to >>> confusion. >>> >>> For a note about another suggestion - `.T` to mean a transpose of the >>> last two dimensions, in Mathematica authors for some reason did the >>> opposite (personally, I could not understand why they made such a >>> choice :) ): >>> >>> Transpose[list] >>> transposes the first two levels in list. >>> >>> I feel strongly that we should have the following policy: >>>> >>>> * Under no circumstances should we make changes that mean that >>>> correct >>>> old code will give different results with new Numpy. >>>> >>> >>> I find this overly strict rules that do not allow to evolve. I >>> completely agree that a silent change in behavior is a disaster, that >>> changing behavior (if it is not an error) in the same minor version (1.X.Y) >>> is not acceptable, but I see no reason to extend this rule for a major >>> version bump (2.A.B.), especially if it allows something to improve. >>> >> >> I'm sorry, you'll have to live with this rule. We've had lots of >> discussion about this rule in many concrete cases. When existing code is >> buggy or is consistently confusing many users, we can discuss. But in >> general changing old code to do something else is a terrible idea. >> >> >>> I would see such a rough version of a roadmap of change (I foresee my >>> loneliness in this :)) Also considering this comment >>> >>> Personally I would find any divergence between a.T and a.transpose() >>>> to be rather surprising. >>>> >>> >>> it will be as follows: >>> >>> 1. in 1.18 add the `.permute` method to the array, with the same >>> semantics as `.transpose`. >>> 2. Starting from 1.18, emit `FutureWarning`, ` DeprectationWarning` for >>> `.transpose` and advise replacing it with `.permute`. >>> 3. Starting from 1.18 for `.T` with` ndim> 2`, emit a `FutureWarning`, >>> with a note that in future versions the behavior will change. >>> 4. In version 2, remove the `.transpose` and change the behavior for >>> `.T`. >>> >> >> This is simply not enough. Many users will skip versions when upgrading. >> There must be an exceptionally good reason to change numerical results, and >> this simply is not one. >> >> > I agree with Ralf that `*.T` should be left alone, it is widely used and > changing its behavior is bound to lead to broken code. I could see `*.mT` > or `*.mH`, but I'm beginning to wonder if we would not be better served > with a better matrix class that could also deal intelligently with stacks > of row and column vectors. In the past I have preferred `einsum` over `@` > precisely because it made handling those variations easy. The `@` operator > is very convenient at a low level, but it simply cannot deal with stacks of > mixed types in generality. With a class we could do something about that. > > Chuck > _______________________________________________ > 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