8000 ENH: C++ namespace and function overrides for npy_math · Issue #26729 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

ENH: C++ namespace and function overrides for npy_math #26729

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account relat 8000 ed emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
WarrenWeckesser opened this issue Jun 17, 2024 · 5 comments
Open

ENH: C++ namespace and function overrides for npy_math #26729

WarrenWeckesser opened this issue Jun 17, 2024 · 5 comments
Labels
01 - Enhancement 63 - C API Changes or additions to the C API. Mailing list should usually be notified. C++ Related to introduction and use of C++ in the NumPy code base component: npy_math

Comments

@WarrenWeckesser
Copy link
Member

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.
@WarrenWeckesser WarrenWeckesser added 01 - Enhancement component: npy_math 63 - C API Changes or additions to the C API. Mailing list should usually be notified. C++ Related to introduction and use of C++ in the NumPy code base labels Jun 17, 2024
@ngoldbaum
Copy link
Member

Sayed has some ideas along these lines in his C++ refactor: #19753.

I'm not sure how much appetite there is to add more things to libnpymath. That said, I see Sayed's API doesn't comprehend a public C++ API. I'm not sure how much appetite there is for that either since maintaining a C++ API is more complicated than maintaining a C API.

@mattip
Copy link
Member
mattip commented Jun 18, 2024

Ping @lysnikolaou and the work toward #20880. There is also https://github.com/numpy/libnpymath

@rgommers
Copy link
Member

Note that using npy_math.h and linking libnpymath are not the same thing. You can do the former without the latter. E.g, the 2.0 release notes explain that PyArray_MIN|MAX and complex type utilities are provided by npy_math.h.

That said, the examples given by @WarrenWeckesser are for things in libnpymath. I don't see any reason why we'd want more people using numpy's version of functions that are provided by C99/C++11 and up. Use std::fabs, not npy::fabs.

@WarrenWeckesser
Copy link
Member Author

Let me reduce the scope of this suggestion to the use of npy_math.h within numpy.

My immediate need is for use within numpy--I'm working on improving the log1p ufunc. Templating with C++ is nicer than templating with .src. For now, I'll put the minimal set of C++ wrappers that I need in the file that implements the complex log1p function, and not touch npy_math.h. We can always expand the (private, internal) C++ API later if it turns out to be more generally useful.

I don't see any reason why we'd want more people using numpy's version of functions that are provided by C99/C++11 and up. Use std::fabs, not npy::fabs.

Short answer: so they can leverage the work that numpy has already done to replace the buggy versions of some of those standard functions on some platforms. But further discussion along these lines probably belongs in gh-20880.

@rgommers
Copy link
Member

👍🏼 a private header seems perfectly fine to me.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
01 - Enhancement 63 - C API Changes or additions to the C API. Mailing list should usually be notified. C++ Related to introduction and use of C++ in the NumPy code base component: npy_math
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@rgommers @WarrenWeckesser @mattip @ngoldbaum
0