[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