[Numpy-discussion] Syntax Improvement for Array Transpose

[Kirill Balunov]

 Only concerns #4 from Ilhan's list.

ср, 26 июн. 2019 г. в 00:01, Ralf Gommers <ralf.gommers at 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?


> 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 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`.

Regarding `.T` with` ndim> 2` - I don’t have preferences between error or
transpose of the last two dimensions.

with kind regards,
-gdg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20190626/4f79c674/attachment.html>