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

Charles R Harris charlesr.harris@gmail....
Sun Dec 13 10:11:47 CST 2009


On Sun, Dec 13, 2009 at 7:07 AM, Alan G Isaac <aisaac@american.edu> wrote:

> On 12/13/2009 3:38 AM, Dmitrey wrote:
> >      def __mul__(self, i):
> >          return asarray(multiply(self, i)) if not getattr(i,
> > '_numpyLeftOperatorsOverloaded', False) else i.__rmul__(self)
> > vs
> >      def __mul__(self, i):
> >          return asarray(multiply(self, i)) if not
> > isinstance(i,CNumpyLeftOperatorOverloaded) else i.__rmul__(self)
> >
>
>
> I am not at all speaking against this, but I am wondering
> what exactly your object is getting out of overriding multiplication.
>
> Also, for clarification, the proposal is not just to override
> multiplication, but *all* arithmetic operations. Right?
> (The examples have all been multiplication.)
>
>
Yes, I think we would want to override all of them, but in ndarray itself.
For instance, what happens now is:

In [1]: from numpy.polynomial import Polynomial as poly

In [2]: p = poly([0,1])

In [3]: ones(2) * p
Out[3]: array([poly([ 0.  1.], [-1.  1.]), poly([ 0.  1.], [-1.  1.])],
dtype=object)

In [4]: p * ones(2)
Out[4]: Polynomial([ 0.,  1.,  1.], [-1.,  1.])

This is because the * ufunc treats the Polynomial class as a scalar,
promotes the ones(2) to an object array, and does the multiplication. What a
mixin class would do is exempt the polynomial from being treated as a scalar
and force python to call its __rmul__ method instead.

Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.scipy.org/pipermail/scipy-dev/attachments/20091213/209ca0aa/attachment.html 


More information about the SciPy-Dev mailing list