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
