Re: [Numpy-discussion] .T Transpose shortcut for arrays again

[Bill B. <wb...@gm...>]

On 7/7/06, Sasha <nd...@ma...> wrote:
>
> I would like to raise a few objections going from mild to strong:
>
> 1. .T : I am mildly against it.  As an inexpensive operation that
> returns a view (so that a.T[...] = makes sense) it is a reasonable
> candidate for an attribute.

Unfortunately reversing the order of axes at least as reasonable as
> swapaxes(-2,-1)


I suppose reversing the order changes you from C ordering to Fortran
ordering?  Other than that I can't think of any good examples of why you'd
want to completely reverse the order of all your axes.  I think it's much
more common to want to swap just two axes, and the last two seem a logical
choice since a) in the default C-ordering they're the closest together in
memory and b) they're the axes that are printed contiguously when you say
"print A".

and swapaxes(-2,-1) is
> invalid for rank < 2.
>

At least in numpy 0.9.8, it's not invalid, it just doesn't do anything.

My main objection is that a.T is fairly cryptic
> - is there any other language that uses attribute for transpose?


Does it matter what other languages do?  It's not _that_ cryptic.  The
standard way to write transpose is with a little T superscript in the upper
right.  We can't do that with ASCII so the T just appears after the dot.
Makes perfect sense to me.  I'd vote for an operator if it were possible in
python.  Something like A^T would be neat, maybe, or matlab's single-quote
operator.

Adding .T to arrays will lead to less readable code because in
> expressions like "a * b.T" it will not be clear whether * is a matrix
> or elemenwise multiplication.


That seems a pretty weak argument, since there are already lots of
expressions you can write that don't make it clear whether some operation is
a matrix operation or array operation.  You could write a * b.transpose(1,0)
right now and still not know whether it was matrix or element-wise
multiplication.  Or doing A[:,1] when you know A is 2-D -- does it give you
a 1D thing back or a 2D thing back?  That just comes down to it being
difficult to determine the class of objects in Python by looking at code.


> 2. .H :  This is an  O(n^2) complexity operation returning a copy so
> it is not appropriate for an attribute.


Not sure how you get O(n^2).   It just requires flipping the sign on the
imaginary part of each element in the array.  So in my book that's O(n).
But that does make it more expensive than O(1) transpose, yes.

It does not make much sense
> for any type other than complex, so it's use is limited.


I personally don't think I have ever used a hermitian transpose in my life.
So I can't really can't say how useful it is.  But the makers of Matlab
decided to make single quote ( e.g. A' ) be the hermitian transpose
operator, and  dot-single quote (e.g. A.') be the regular transpose.  So I'm
assuming it's common enough that the folks behind Matlab thought it wise to
make it the 'default' style of transpose and give it a one-character
operator.  That's about the only evidence I have that it's a useful
operation, though.    In general, though, I do know that when you take
good-ole algorithms for reals and extend them to complex numbers, things
that were transpose for the reals become hermitian transposes for the
complex version.

3. .M : I am strongly against this. It will create a circular
> dependency between ndarray and matrix.  I would expect that asmatrix
> is mostly used to convert function arguments and for this purpose
> @matrix_args decorator would be a better solution to reduce code
> clutter.


I'm kindof ambivalent about this one too.  Assuming matrix is going to stay
around and we actually want to encourage people to use it, I think having a
.M on arrays is an improvement over the current situation.  Arguments to
functions expecting matrices are as you say one place where conversions are
needed, but another place is on funtions like zeros and ones and empty.
With the .M you can just say ones(2,2).M.  But probably a better solution
would be to have matrix versions of these in the library as an optional
module to import so people could, say, import them as M and use M.ones(2,2).

It does seem to me that in some sense matrix is supposed to be 'just another
customized array subclass', like sparse or masked, so to have array aware of
it this one particular subclass makes me a little uneasy.  But if matrix
really should be considered to be on par with array, then it makes sense.
It's just like a mutually recursive data structure.  Or you can think of
matrix's inheritance from array being an implementation detail.


4. .A : I have no clue what this one does, so I won't comment.



It returns the array.  I think the idea was that you would always be able to
say .A with array or anything derived from it.  Currently you have to know
you have a matrix before you can use  the .A attribute.  If you were wrong
and it was actually an array, then you'll get an exception.  It would be
nicer to have X.A just return X if X is already an array.

In short, I'm most enthusiastic about the .T attribute.  Then, given a .T,
it makes sense to have a .H, both to be consistent with matrix, but also
since it seems to be a big deal in other math packages like matlab.  Then
given the current situation, I like the .M but I can imagine other ways to
make .M less necessary.

--bb

On 7/6/06, Travis Oliphant <oli...@ie...> wrote:
> > Bill Baxter wrote:
> > > So in short my proposal is to:
> > > --  make a.T a property of array that returns a.swapaxes(-2,-1),
> > > --  make a.H a property of array that returns
> > > a.conjugate().swapaxes(-2,-1)
> > > and maybe
> > > --  make a.M a property of array that returns numpy.asmatrix(a)
> >
> > I've tentatively implemented all of these suggestions as well as adding
> > the .A attribute to the ndarray as well (so that all sub-classes and
> > array scalars can get back a view as an ndarray).
> >
> > I did this to make it easier to do matrix-like calculations with or
> > with-out matrices.   Matrix-calculation flexibility is still a sore-spot
> > for many and I think these syntatical-sugar attributes will help long
> term.
> >
> > If there are no strong objections, then the recent  MATH attribute
> > checkin will stay.  If there are major objections, then we can back them
> > out without too much trouble as well.
> >
> > -Travis
>
>