On Sun, Apr 21, 2013 at 4:59 AM, Sebastian Berg <sebastian@sipsolutions.net>wrote:

Hi,

just something that has been spooking around in my mind. Considering that matrix indexing does not really support fancy indexing, I was wondering about introducing a KeepDims flag. Maybe it is not worth it, at least not unless other subclasses could make use of it, too. And a big reason for it being not worth the trouble is probably that you could not use it inside the current matrix class because it would i.e. break workarounds for ufunc reductions (like np.multiply.reduce(a, axis=1).T, as the .T would be unnecessary).

Such a flag could only be set (not unset) and never be set on base class arrays (basically it should be set by array_finalize). If set it would toggle ufunc reductions to always use keepdims (unless the reduction is to a scalar, maybe). And the same thing for indexing (meaning that some fancy indices and np.newaxis would just error out), though axes added by broadcasting should be caught by the subclass itself.

That way, a matrix-like class would normally have a 1:1 mapping of old to new axes (even if they might be transposed or elements arbitrarily shuffled), and does not have to do magic to guess where to add the missing one (instead the magic is done in the core, where it is actually easier to implement).

Anyway, as I never use matrix I personally have no real use for it, but I thought I would throw the thought out there. For starters one might rather think about something specific to indexing.

I'd be hesitant to add another flag. Perhaps a better direction to go would be to add row/column vectors, something that has been much discussed. There is also a keepdims flag for reduce operations that is a fairly new addition that I don't think has been exploited in the matrix class. ISTR discussion of adding a facility for subclasses to intercept ufunc calls, or something along those lines which would help with that, both for matrix and for masked arrays. Chuck