On Sun, 2025-11-23 at 19:27 +0100, Ralf Gommers via NumPy-Discussion wrote: > On Sun, Nov 23, 2025 at 2:42 PM Sebastian Berg > <[email protected]> > wrote: > >
<snip> > > 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 agree with the goal/reasoning, but I am still skeptical that exposing them this way would, unfortunately, serve almost no-one at all. (Because it is only useful if you don't care about speed at all and are not using accelerators/toolchains that ship headers anyway?) The important part here seems to be pushing the goal of getting rid of npy_math, what is the plan for the rest of it here? Just getting rid of it completely because it is obsolete? If we introduce this now users will adopt it in 2-3 years (old NumPy versions don't have it). Now there is no guarantee that e.g. `float16_t` will be generally supported (it's optional anyway) but if the situation around half improves just a little, I wonder if by the time this is useful it won't already be completely obsolete, rather than just mostly. That is a poor argument probably, but considering how few users we'll do a favor with it, I am really not sure... > 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. > Sure, but only if that code actually happens to care about full dtype support for the sake of it. - Sebastian > > 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] _______________________________________________ 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]
