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 >>>> 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. > 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). Curmudgeonly yours, -tim > 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 > > > > > > 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 > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Numpy-discussion mailing list > Numpy-discussion@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/numpy-discussion > > > 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 http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Numpy-discussion mailing list Numpy-discussion@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/numpy-discussion
