On Sun, Feb 22, 2009 at 7:01 PM, Darren Dale <dsdal...@gmail.com> wrote:
> On Sun, Feb 22, 2009 at 6:35 PM, Darren Dale <dsdal...@gmail.com> wrote: > >> On Sun, Feb 22, 2009 at 6:28 PM, Pierre GM <pgmdevl...@gmail.com> wrote: >> >>> >>> On Feb 22, 2009, at 6:21 PM, Eric Firing wrote: >>> >>> > Darren Dale wrote: >>> >> Does anyone know why __array_wrap__ is not called for subclasses >>> >> during >>> >> arithmetic operations where an iterable like a list or tuple >>> >> appears to >>> >> the right of the subclass? When I do "mine*[1,2,3]", array_wrap is >>> >> not >>> >> called and I get an ndarray instead of a MyArray. "[1,2,3]*mine" is >>> >> fine, as is "mine*array([1,2,3])". I see the same issue with >>> >> division, >>> > >>> > The masked array subclass does not show this behavior: >>> >>> Because MaskedArray.__mul__ and others are redefined. >>> >>> Darren, you can fix your problem by redefining MyArray.__mul__ as: >>> >>> def __mul__(self, other): >>> return np.ndarray.__mul__(self, np.asanyarray(other)) >>> >>> forcing the second term to be a ndarray (or a subclass of). You can do >>> the same thing for the other functions (__add__, __radd__, ...) >> >> >> Thanks for the suggestion. I know this can be done, but ufuncs like >> np.multiply(mine,[1,2,3]) will still not work. Plus, if I reimplement these >> methods, I take some small performance hit. I've been putting a lot of work >> in lately to get quantities to work with numpy's stock ufuncs. >> > > I should point out: > > import numpy as np > > a=np.array([1,2,3,4]) > b=np.ma.masked_where(a>2,a) > np.multiply([1,2,3,4],b) # yields a masked array > np.multiply(b,[1,2,3,4]) # yields an ndarray > > I'm not familiar with the numpy codebase, could anyone help me figure out where I should look to try to fix this bug? I've got a nice set of generators that work with nosetools to test all combinations of numerical dtypes, including combinations of scalars, arrays, and iterables of each type. In my quantities package, just testing multiplication yields 1031 failures, all of which appear to be caused by this bug (#1026 on trak) or bug #826. Thanks, Darren
_______________________________________________ Numpy-discussion mailing list Numpy-discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
