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

Travis E. Oliphant oliphant at enthought.com
Mon Jan 7 13:31:26 EST 2008


Bruce Sherwood wrote:
> Sorry to repeat myself and be insistent, but could someone please at 
> least comment on whether I'm doing anything obviously wrong, even if you 
> don't immediately have a solution to my serious problem? There was no 
> response to my question (see copy below) which I sent to both the numpy 
> and Boost mailing lists.
>
> To the numpy experts: Is there something wrong, or something I 
> could/should change in how I'm trying to overload multiplication of a 
> numpy square root (or other numpy function) times my own "vector" 
> object? I'm seeing a huge performance hit in going from Numeric to numpy 
> because Numeric sqrt returned float whereas numpy sqrt returns 
> numpy.float64, so that the result is not one of my vector objects. I 
> don't have a problem with myvector*sqrt(5.5).
>   
I'm not sure how to help explicitly as I do not know Boost very well and 
so am not clear on what specifically was done that is now not working 
(or where the problem lies).

I can, however, explain the numpy.float64 Python object.

This Python object is binary-compatible with a Python float object (and 
in fact is a C subtype of it).  It is a simple wrapper around a regular 
C-double.

There are lots of possibilities.   The most likely issue in my mind is a 
coercion issue.  Whereas the Python float probably bailed when it saw 
myvector as the other argument, the numpy.float64 is seeing myvector as 
something that can be converted into a NumPy array and therefore going 
ahead and doing the conversion and performing the multiplication (which 
will involve all the overhead for general ufuncs).

Thus, there needs to be a way to signal to numpy.float64 that it should 
let the other object handle it.   I'm not sure what the right solution 
is here, but I think that is the problem.    The good news is that we 
can change it if we figure out what the right thing to do is.

Best regards,

-Travis O.




More information about the NumPy-Discussion mailing list