Whatever the decision would be, could we at least try to use the bit width in the name such as float16 as much as possible? Half means nothing and gives different platforms different ideas which would be very annoying after a decade, every platform went their own way. Also syntactically double -> float -> half (not to mention the "long" situation) is not consistent either. There is still no guarantee obviously (say complex256 support on windows) but at least we eliminate the obvious ones.
On Mon, Nov 24, 2025 at 10:52 AM Sebastian Berg <[email protected]> wrote: > 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] >
_______________________________________________ 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]
