On Sun, Apr 21, 2013 at 4:59 AM, Sebastian Berg <[email protected]>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
_______________________________________________ NumPy-Discussion mailing list [email protected] http://mail.scipy.org/mailman/listinfo/numpy-discussion
