On Sun, Nov 23, 2025 at 2:42 PM Sebastian Berg <[email protected]> wrote:
> On Sun, 2025-11-23 at 11:51 +0100, Ralf Gommers via NumPy-Discussion > wrote: > > On Sun, Nov 23, 2025 at 8:47 AM Matti Picus via NumPy-Discussion < > > [email protected]> wrote: > > > > > > > > On 22/11/2025 1:59, Amelia Thurdekoos wrote: > > > > > > > > Expose |halffloat.h| functionality through the regular NumPy C- > > > > API as > > > > > NpyHalf*|, without requiring the linking of |npymath| > > > > > explicitly as a > > > > step toward removing the |npymath| static library altogether. > > > > > > > Thanks for sharing the proposal Amelia! > > > > Let me also link to the most relevant comment in #20880, because it's > > a > > very long and complex discussion about all of libnpymath rather than > > just > > the half-precision functionality: > > https://github.com/numpy/numpy/issues/20880#issuecomment-1612011687 > > > > > > > I would be concerned about the performance impact of having to go > > > through function calls for functions that are really macros, > > > especially > > > on platforms with built-in float16. Perhaps we could still use > > > macros on > > > those platforms. > > > > > > > > > We would have to check the benchmarks of consumers of the npymath > > > library for impact. Do we know of consumers other than SciPy? > > > > > > > SciPy doesn't use these functions, I can only find a single instance > > of a > > use of NPY_HALF. A GitHub code search only turns up smaller packages, > > e.g.: > > https://github.com/WarrenWeckesser/numtypes, uses `npy_half_isnan` > > https://github.com/WarrenWeckesser/ufunclab, uses > > `npy_half_to_float` > > https://github.com/wormtable/wormtable, uses `npy_half_to_double` > > > > This is really a dtype that is only useful for educational purposes > > and > > possibly some very niche low-memory use cases, so I am not too > > worried > > about performance (we should still do sane things design/performance- > > wise > > of course). If we actually cared about 16-bit floats usefulness and > > performance, we should integrate bfloat16. > > > > > > The question I have is whether we should expose all the functionality > > that's currently exposed in `halffloat.h` or leave out some of the > > odd > > ones. The conversion and comparison functions seem most useful, but > > for > > example the `*_nonan` variants look weird (we don't normally expose > > "skip-nan" flavors just for some performance), as does `_iszero` > > (unlike > > `_isnan` et al. it doesn't have a C99 equivalent). > > > > I tend to agree with Matti that it seems a bit odd to expose them via a > runtime vtable like the rest of the NumPy rather than actual linking . > > Maybe it's fine if it is just about having them around for completeness > for very light usage. I would think anyone serious about it will find a > better toolchain that defines `__half` or `_Float16` or C++ 23 > `float16_t` these days? > Those are not things anyone can do in portable/library code I think. The option of using C++23 is a number of years away (even C++20 isn't close), and the other options won't work with MSVC and probably not with some other toolchains either. > I guess a question is who even uses this. Wormtable uses it, but it > actually just vendors NumPy's `halffloat.c`, which doesn't seem all > that bad to me... > That's an option, but it's not something we do for anything else, and probably a bit too odd for a dtype we do expose in the regular C API (npy_half, NPY_HALF are in the listed dtypes in https://numpy.org/doc/2.3/reference/c-api/dtype.html)? Whether we like it or not, npy_half/float16 are built-in dtypes so making them usable through the C API like all other dtypes seems like a fair goal. I don't think there are many (any?) widely used libraries that use this, but note that until two weeks ago (when we got rid of it in https://github.com/numpy/numpy/pull/30008), it was used by the main example for multiple dtypes support in the "writing your own ufunc" tutorial: https://numpy.org/doc/2.3/user/c-info.ufunc-tutorial.html#example-numpy-ufunc-with-multiple-dtypes. So probably there's a fair amount of code that just copied that. > Or how about shipping it header only so that we don't have to worry > about linking at all? It's not like there'll be dozens of copies around > or so. That would be nice, if that works - would it? It'd need changing to static inline functions, and it's not quite clear to me from a quick read of halffloat.c whether that works (it's not fully self-contained, uses `npy_set_floatstatus_*`). Also, it looks like that would need at least undoing the conversion to C++ from https://github.com/numpy/numpy/pull/23298 for it to be usable in third-party C code. That didn't receive any discussion by the way nor did there seem to be a need for that change. It seems like that while that didn't yield any bug reports - possibly because these functions are so rarely used - it violates the "no C++ in npymath" rule so reverting that change seems necessary anyway if we want to split off npymath as a separate library. And after I wrote this, I remembered https://github.com/numpy/libnpymath - and yes that's already back to the plain C implementation. Cheers, Ralf
_______________________________________________ NumPy-Discussion mailing list -- [email protected] To unsubscribe send an email to [email protected] https://mail.python.org/mailman3//lists/numpy-discussion.python.org Member address: [email protected]
