[SciPy-dev] Suppressing of numpy __mul__, __div__ etc

Charles R Harris charlesr.harris@gmail....
Sat Dec 12 14:56:21 CST 2009


2009/12/12 Dmitrey <tmp50@ukr.net>

>  hello all,
> I have class oofun (in a package FuncDesigner, that is already used by lots
> of people) where some operations on numpy arrays (along with Python lists
> and numbers) are overloaded, such as __mul__, __add__, __pow__, __div__ etc.
>
> There is a problem with numpy arrays: if I use a*f where a is array and f
> is oofun, it returns array with elements a[i]*f. Would it omit calling
> array.__mul__ and call only oofun.__rmul__, like it is done in numpy.matrix
> and Python lists/numbers, all would work ok as expected; but now it makes
> FuncDesigner code to work much slower or unexpectedly or doesn't work at all
> instead.
> So, does anyone mind if I'll commit some changes to numpy __mul__, __div__
> etc?
> I intend to implement the following walkaround:
> Now the code looks like this for array:
>
>     def __mul__(self, i):
>         return asarray(multiply(self, i))
>
> and like this for numpy/matrixlib/defmatrix.py:
>
>     def __mul__(self, other):
>         if isinstance(other,(N.ndarray, list, tuple)) :
>             return N.dot(self, asmatrix(other))
>         if isscalar(other) or not hasattr(other, '__rmul__') :
>             return N.dot(self, other)
>         return NotImplemented
>
> and I want to add an empty class named "CNumpyLeftOperatorOverloaded" to
> numpy, and if someone defines his class as a child of the one, __mul__ and
> others will not invoke __div__ etc, calling otherClass.__rdiv__ etc:
>
>     def __mul__(self, i):
>         return asarray(multiply(self, i)) if not
> isinstance(i,CNumpyLeftOperatorOverloaded) else i.__rmul__(self)
> and declare my class as a child of the one.
>
> As far as I understood, the changes should be added to
> numpy/core/defcherarray.py
> So, does anyone mind me to implement it?
> D.
>
>
Sounds like you are exporting an array interface or subclassing ndarray. If
the latter, you might be able to manipulate the value of __array_priority__.
I haven't experimented with these things myself.

As to the proposed solutions, they are the start of a slippery slope of
trying to identify all objects to which they should apply. I don't think we
want to go there.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20091212/4134f166/attachment.html 


More information about the SciPy-Dev mailing list