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? 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... 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. - Sebastian > > 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] _______________________________________________ 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]
