On Feb 6, 2009, at 4:25 PM, Darren Dale wrote: > > I've been looking at how ma implements things like multiply() and > MaskedArray.__mul__. I'm surprised that MaskedArray.__mul__ actually > calls ma.multiply() rather than calling > super(MaskedArray,self).__mul__().
There's some under-the-hood machinery to deal with the data, and we need to be able to manipulate it *before* the operation takes place. The super() approach calls __array_wrap__ on the result, so *after* the operation took place, and that's not what we wanted... > Maybe that is the way ndarray does it, but I don't think this is the > right approach for my quantity subclasses. If I want to make a > MaskedQuantity (someday), MaskedQuantity.__mul__ should be calling > super(MaskedQuantity,self).__mul__(), not reimplementations of > numpy.multiply or ma.multiply, right? You'll end up calling ma.multiply anyway (super(MaskedQuantity,self).__mul__ will call MaskedArray.__mul__ which calls ma.multiply... So yes, I think you can stick to the super() approach in your case > > There are some cases where the default numpy function expects > certain units on the way in, like the trig functions, which I think > would have to be reimplemented. And you can probably define a generic class to deal with that instead of reimplementing the functions individually (and we're back to the initial advice). > But aside from that, is there anything wrong with taking this > approach? It seems to allow quantities to integrate pretty well with > the numpy builtins. Go and try, the problems (if any) will show up... _______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://projects.scipy.org/mailman/listinfo/numpy-discussion