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