ENH: C++ namespace and function overrides for npy_math #26729
Description
Proposed new feature or change:
I'm working on improving an existing ufunc (complex log1p) in numpy, and I'm implementing the updated version in C++. The function will use several functions from npy_math (npy_log, npy_log1p, npy_fabs, npy_atan2, npy_hypot), and these all follow the C convention of having three versions, one for each of the types npy_float, npy_double and npy_longdouble, e.g. npy_fabsf, npy_fabs and npy_fabsl.
It would really nice if we had a C++ namespace (e.g. npy to match the "poor man's namespace" implemented with the prefix npy_ in C) that provides a single name with overloaded implementations for each type, e.g. npy::fabs. This would make writing templated code in C++ much easier.
As an experiment, I added this code to the end of npy_math.h:
#ifdef __cplusplus
//
// Trivial C++ wrappers for several npy_* functions.
//
#define CPP_WRAP1(name) \
inline npy_float name(const npy_float x) \
{ \
return ::npy_ ## name ## f(x); \
} \
inline npy_double name(const npy_double x) \
{ \
return ::npy_ ## name(x); \
} \
inline npy_longdouble name(const npy_longdouble x) \
{ \
return ::npy_ ## name ## l(x); \
} \
#define CPP_WRAP2(name) \
inline npy_float name(const npy_float x, \
const npy_float y) \
{ \
return ::npy_ ## name ## f(x, y); \
} \
inline npy_double name(const npy_double x, \
const npy_double y) \
{ \
return ::npy_ ## name(x, y); \
} \
inline npy_longdouble name(const npy_longdouble x, \
const npy_longdouble y) \
{ \
return ::npy_ ## name ## l(x, y); \
} \
namespace npy {
CPP_WRAP1(fabs)
CPP_WRAP1(log)
CPP_WRAP1(log1p)
CPP_WRAP2(atan2)
CPP_WRAP2(hypot)
}
#endif // __cplusplus
Then in a templated C++ function that includes npy_math.h, I use npy::fabs, npy::log, etc. This works fine.
Is there interest in such an update to npy_math.h (or some other header) to facilitate writing code in C++? Of course, giving all the functions in npy_math.h similar wrappers will be more work, and there might be some gotchas that show up in the process, but with more and more code being implemented in C++ in NumPy, I think this is something we need.