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

[Bill Baxter]

On 7/6/06, Sven Schreiber <svetosch at gmx.net> wrote:
>
> Travis Oliphant schrieb:
> > 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).


That's great.

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


I think it will help too.  The .M will make it easer to go from array to
matrix types, and with the .A it was already easy to go from matrix to
array.  And the .T and .H will make it easier to do linear algebra numerics
without switching over to matrix.

One thing just occurred to me though, will the .M be available on matrices
too?  If not then one will have to be careful when using a mix of matrix and
array to make sure you only use the .M on the latter and not the former.

I think this is great, thanks to Bill for suggesting it and to Travis
> for implementing it!


Yes indeed, thanks!

So the only convenience of matrices over pure arrays that remains (afaics):
>
> -) .I for inverse; actually, why not add that to arrays as well as
> "syntactic sugar"?


I don't even think it .I belongs in matrix.  Hideously expensive
calculations should not be masquerading as simple attribute accesses!
Furthermore, maybe I'm just not doing the right kind of math, but inverses
just don't come up that often for me. And if they do, it's usually in the
context of solving a linear system Ax = b, where taking the inverse of A is
generally a bad approach.  So I'm negative on the inverse attribute in
general, and double negative on it for arrays.  Transpose is an operation
that makes sense for a lot of kinds of data even non-matrix, but inverse is
really only the multiplicative matrix inverse.  Besides, given the new .M
attribute, all you need to do to get the matrix inverse is .M.I. or .M.I.A
if you want to get back to array.  But sheesh, inv() is just 3 letters +
parens.  Going to .I only saves you 3 keystrokes.  Going from .transpose()
to .T saves 10.

-) * being the matrix product instead of element-wise; Now, I could live
> with using dot and I don't want to push anything, but maybe this is the
> right time to consider another operator symbol as a shortcut for the dot
> function to be used with arrays? (Unfortunately right now I can't think
> of any sensible character(s) for that...)


I don't think Python offers much flexibility in choosing characters to use
as operators.  That's one place where I think Haskell and ML are pretty
neat.  You can define your own in-fix operator symbols like (*) or -*- or
<*> or .* like matlab.  Whatever you want as long as it's a string of
operator characters.  Python can't do that, though.

-) ** analogously for powers. For me this is less important.


 I don't have much need for that one.

-) Being able to distinguish between row and column vectors; I guess
> this is just not possible with arrays...


Yeh that doesn't seem to be in the cards with array.   But with the .M
attribute you'll be able to get a column from a 1d array with a.M.T.  Maybe
a little improvement over a[None].transpose()?   I guess I'd probably use
a[None].T, though.

If --apart from the previous changes-- numpy had the .I for arrays I
> guess this would get me to say goodbye to matrices. The rest of the list
> would be a welcome luxury. I believe this whole thing has the potential
> to unify the use of numpy by eventually making the matrix subclass
> redundant. IMO that would be more transparent for new users and would
> increase the popularity of numpy!


That was pretty much my conclusion.   Ideally if you start off with matrices
you would never encounter an array anywhere, and it would be just like using
Matlab.  :-)  If it were like that I might still be using it.  But it just
doesn't seem to work out that way.   One thing that would really help would
be one of these mini-decorator modules Travis was talking about.  In this
case it would change all functions to return matrices.   So if you do
something like "import numpy.matrix" then after that ones() and zeros() and
rand() etc will all be functions that return matrices.   The .M attrib will
make it easier.  Instead of asmatrix(ones(3,3)) everywhere you'll have
ones(3,3).M everywhere.   But it's still not as nice as it would be if you
could just import a package and have ones() etc return a matrix by default.
I personally think matrix should be allowed to have more than 2 dimensions.
Less than 2, no, but more than 2 should be ok.

--bill
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/numpy-discussion/attachments/20060706/306f27bf/attachment-0001.html>