[Numpy-discussion] Numpy or Boost problem

Bruce Sherwood Bruce_Sherwood@ncsu....
Thu Dec 20 11:19:20 CST 2007


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<double, double, 
double> >())
       .def( self * double())
       .def( double() * self)

As far as I can understand from the Boost Python documentation, this is 
the proper way to specify the left-hand and right-hand overloadings. But 
do I have to add something like .def( npy_float64() * self)? Help would 
be much appreciated.

Bruce Sherwood
 



More information about the Numpy-discussion mailing list