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.