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

[Dmitrey]

От кого: Sebastian Walter <sebastian.walter at gmail.com>  
  
  I have also implemented/wrapped various automatic differentiation  
tools in python  
(http://github.com/b45ch1/algopy , http://github.com/b45ch1/pyadolc,  
http://github.com/b45ch1/pycppad if someone is interested)  
and I have also come across some numpy glitches and inconsistencies.  
  
However, this particular problem I have not encountered. I'm not sure  
I understand the rationale why an expression like numpy.array([1,2] *  
oofun(1) should call the oofun.__rmul__ operator.  
Hence, I'm a little sceptical about this enhancement.  
  
What is wrong with the following implementation? It works perfectly fine...  
  
--------------- start code snippet -----------------  
  
class oofun:  
def __init__(self,x):  
self.x = x  
  
def __mul__(self, rhs):  
print 'called __mul__'  
if isinstance(rhs, oofun):  
return oofun(self.x * rhs.x)  
else:  
return rhs * self  
  
def __rmul__(self, lhs):  
print 'called __rmul__'  
return oofun(self.x * lhs)  
  
def __str__(self):  
return str(self.x)+'a'  
  
def __repr__(self):  
return str(self)  
  
------------- end code snippet ----------------  
  
--------- output ----------  
basti at shlp:~/Desktop$ python live_demo.py  
called __mul__  
called __rmul__  
called __rmul__  
called __rmul__  
[2.0a 2.0a 2.0a]  
called __rmul__  
called __rmul__  
called __rmul__  
[2.0a 2.0a 2.0a]    
But I don't want to get ndarray of N oofuncs, I just want to get single oofunc. At first, evaluating of each oofunc is rather costly, so for N >> 1 I get serious slow down; at second, sometimes my code doesn't work at all - for example, when I create a constraint c = oof1 < oof2 (or lots of other samples). I expect result of a*oof, a/oof etc to be of type oofun while it doesn't (it yields ndarray of oofuns).  
  
  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/scipy-dev/attachments/20091217/5980a7f2/attachment.html>