[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