I'm not sure whether this is a Numpy problem or a Boost problem, so I'm
posting to both communities.
In old Numeric, type(sqrt(5.5)) was float, but in numpy, type(sqrt(5.5))
is numpy.float64. This leads to a big performance hit in calculations in
a beta version of VPython, using the VPython 3D "vector" class, compared
with the old version that used Numeric (VPython is a 3D graphics module
for Python; see vpython.org).
Operator overloading of the VPython vector class works fine for
vector*sqrt(5.5) but not for sqrt(5.5)*vector. The following free
function catches 5.5*vector but fails to catch sqrt(5.5)*vector, whose
type ends up as numpy.ndarray instead of the desired vector, with
concomitant slow conversions in later vector calculations:
inline vector
operator*( const double& s, const vector& v)
{ return vector( s*v.x, s*v.y, s*v.z); }
I've thrashed around on this, including trying to add this:
inline vector
operator*( const npy_float64& s, const vector& v)
{ return vector( s*v.x, s*v.y, s*v.z); }
But the compiler correctly complains that this is in conflict with the
version of double*vector, since in fact npy_float64 is actually double.
It's interesting and presumably meaningful to the knowledgeable (not me)
that vector*sqrt(5.5) yields a vector, even though the overloading
speaks of double, not a specifically numpy name:
inline vector
operator*( const double s) const throw()
{ return vector( s*x, s*y, s*z); }
VPython uses Boost, and the glue concerning vectors includes the following:
py::class_<vector>("vector", py::init< py::optional