[Numpy-discussion] .T Transpose shortcut for arrays again
tim.hochberg at cox.net
Thu Jul 6 10:04:15 CDT 2006
Tim Hochberg wrote:
> 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
>>>> 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
Also, having an attribute access do an expensive operation behind the
scenes seems antisocial.
>> -) * 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.
Actually, thinking about this some more, this isn't a very compelling
reason since multiply suffers from the same effect. Better reasons:
1. Consistency. Unless '/' is overloaded as well, then some of the
operators will be elementwise and some will be matrix (+/- go both ways)
making the interface inconsistent and thus harder to learn.
2. Backwards compatibility.
3. I was going to say narrowness of interface, since I had this fantasy
that dot allowed axis to be specified, and thus we'd still need a
separate dot function in addition to '*'. However, that must be
something I have set up locally. (I realize that there's a separate
multiply ufunc, but the ufuncs are all the same so I don't really count
them against the overall complexity of numpy).
> 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))
> 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.....
> Using Tomcat but need to do more? Need to support web services, security?
> Get stuff done quickly with pre-integrated technology to make your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
> Numpy-discussion mailing list
> Numpy-discussion at lists.sourceforge.net
More information about the Numpy-discussion