Good Afternoon/Morning NumPy Community, To close the loop on this discussion, I have submitted a pull request implementing the header only approach as discussed in this email chain. See #30380. <https://github.com/numpy/numpy/pull/30380>
Thank you again for your feedback on this topic. ~Amelia On Mon, Dec 8, 2025 at 3:10 AM Ralf Gommers via NumPy-Discussion < [email protected]> wrote: > > > On Tue, Nov 25, 2025 at 10:47 AM Sebastian Berg < > [email protected]> wrote: > >> 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. >> > > To keep us on the same page: `libnpymath`, not `npy_math.h` (the latter > exposes functionality that doesn't need the static library as well). But > indeed - ideally we'd like to move as many users as possible off of the > static library, so we can just delete it. We managed for `statsmodels` > recently; `scipy` still is tricky and it may need to vendor some code. The > other plan is to do what we do sometimes for legacy code and split it off > as a standalone package that remaining users can then vendor. We already > had this in progress quite a while back, that effort just stalled for now. > See https://github.com/numpy/libnpymath > > > >> 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.) >> > > I'm not sure something like Eigen is a reasonable thing to point to, > that's a very heavy dependency. That said, I don't think we need to either, > since the header-only approach seems to work. > > Cheers, > Ralf > > >> >> - 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] >> > _______________________________________________ > 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] > -- Amelia Thurdekoos Staff Software Engineer, Quansight Quansight | Your Data Experts w: www.quansight.org <http://quansight.org/> e: [email protected] <https://www.linkedin.com/company/quansight/> <https://www.instagram.com/quansightai/> <https://bsky.app/profile/quansight.com> <https://twitter.com/quansightai>
_______________________________________________ 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]
