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

Tim Hochberg tim.hochberg at cox.net
Thu Jul 6 10:15:40 EDT 2006


Sven Schreiber 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). 
>>
>> 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 this is great, thanks to Bill for suggesting it and to Travis
> for implementing it!
>
> 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"?
>   
Because it encourages people to do the wrong thing numerically speaking? 
My understanding is that one almost never wants to compute the inverse 
directly, at least not if you're subsequently going to multiply it with 
something, instead you want to use linalg.solve or some other similar 
approach.

> -) * 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...)
>   
See my earlier note on why using a method (which '*' is in essence) for 
dot is not really a good idea. We can do better. Oh, and this would 
completely hose all the non matrix heads out there as well.

> -) ** analogously for powers. For me this is less important.
>
> -) Being able to distinguish between row and column vectors; I guess
> this is just not possible with arrays...
>   
Why can't you distinguish between them the same way that the matrix 
class does? Shape [1, N] is a row array, shape [N,1] is column array.
> 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!

     >>> len(dir(numpy.ndarray)) - len(dir(int))
    99

I'm not particularly excited about the matrix class growing ever more 
cruft, but c'est la vie. I really need to finish up arraykit.....

-tim








More information about the NumPy-Discussion mailing list