[Numpy-discussion] [C++-sig] Overloading sqrt(5.5)*myvector

Travis E. Oliphant oliphant@enthought....
Mon Jan 7 12:57:37 CST 2008


Bruce Sherwood wrote:
> Okay, I've implemented the scheme below that was proposed by Scott 
> Daniels on the VPython mailing list, and it solves my problem. It's also 
> much faster than using numpy directly: even with the "def "and "if" 
> overhead: sqrt(scalar) is over 3 times faster than the numpy sqrt, and 
> sqrt(array) is very nearly as fast as the numpy sqrt.
>   
Using math.sqrt short-circuits the ufunc approach of returning numpy 
scalars (with all the methods and attributes of 0-d arrays --- which is 
really their primary reason for being).

It is also faster because it avoids the numpy ufunc machinery (which is 
some overhead --- the error setting control and broadcasting facility 
doesn't happen for free).
> Thanks to those who made suggestions. There remains the question of why 
> operator overloading of the kind I've described worked with Numeric and 
> Boost but not with numpy and Boost. 
Basically, it boils down to the fact that I took a shortcut with 
implementing generic multiplication (which all the scalars use for now) 
on numpy scalars so that the multiplication ufunc is called when they 
are encountered.  

Thus, when the numpy.float64 is first (its multiply implementation gets 
called first) and it uses the equivalent of

ufunc.multiply(scalar, vector)

I suspect that because your vector can be converted to an array, this 
procedure works (albeit more slowly than you would like), and so the 
vector object never gets a chance to try. 

A quick fix is to make it so that ufunc.multiply(scalar, vector) raises 
NotImplemented which may not be desireable, either.

Alternatively, the generic scalar operations should probably not be so 
"inclusive" and should allow the other object a chance to perform the 
operation more often (by returning NotImplemented).


-Travis O.



More information about the Numpy-discussion mailing list