From: Robert K. <rob...@gm...> - 2006-07-06 18:55:07
|
Travis Oliphant wrote: > 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. > > If there are no strong objections, then the recent MATH attribute > checkin will stay. If there are major objections, then we can back them > out without too much trouble as well. Like Sasha, I'm mildly opposed to .T (as a synonym for .transpose()) and much more opposed to the rest (including .T being a synonym for .swapaxes(-2, -1)). It's not often that a proposal carries with it its own slippery-slope argument against itself. I don't think that just because arrays are often used for linear algebra that linear algebra assumptions should be built in to the core array type. -- Robert Kern "I have come to believe that the whole world is an enigma, a harmless enigma that is made terrible by our own mad attempt to interpret it as though it had an underlying truth." -- Umberto Eco |