On Mon, 2025-11-24 at 10:33 -0800, Amelia Thurdekoos wrote: > > ...could we at least try to use the bit width in the name such as > > float16 > > as much as possible? > > > This is all excellent feedback, thank you! I agree, more explicit is > better. Planning as best as we can with an eye to future clarity, > seems > reasonable. > > > > 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. > > > Thanks for the feedback Sebastian! I agree, the overarching goal is > removing npy_math. This proposal's scope is intentionally limited to > the > float16/halffloat part as one self-contained step in that direction, > rather > than trying to solve the whole npy_math feature at once. I am not > going to > be removing any part of the library as part of this effort. > > If float16 improves enough that this API becomes obsolete, or even > less > attractive, this effort still yields a net positive. It will assist > with > reducing the need to link against npy_math. >
Yeah, nice and I agree with Nathan that it is tedious for e.g. DType casts. ml_dtypes uses the Eigen for this purpose CuPy vendors [1]. If `npy_math` wouldn't be deleted it would be nice to have a thought on what happens with it (since we could probably use the same thing for half). But I think the hope is to just delete and I don't want to block this if this seems like the main blocker. However, it still seems to me like only the conversions are (for now?) truly useful. And I also still wonder if header-only may not be just as well and simpler for all sides? I would also be happy to consider to only keep the conversion functions and ask users who need serious math to look elsewhere, because for now I still suspect it's not hard to find things elsewhere (e.g. Eigen). (Yes, I am assuming that would throw at least close to zero persons/projects under the bus if this starts missing.) - Sebastian [1] For now CuPy never compiled against NumPy, if it does there are better replacements, i.e. CuPy wouldn't need this functionality. > - Amelia > _______________________________________________ > 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]
