Description
Yesterday there was a bit of a discussion around adding an env variable to allow runtime selection (mainly opt out of lower precision SVML). I need to think it a bit over, but overall, I would be fine with doing that.
There was also a discussion that a proper solution may be to allow selecting this maybe as a context (or similar). I don't think that is a small project, but I am not sure it is huge either.
I am not planning on attacking it, but if e.g. @mattip is interested in it together with @seiko2plus it may be a well scoped project, so I thought I open an issue to see if things drop out.
What would it take? Some internal reorganization for sure:
We probably need to fixnp.errstateto be a context variable (that is needed anyway). I think we could then expand it to tag on a "float precision" context?np.errstateis now a contextvar with ENH,API: Make the errstate/extobj a contextvar #23936. This makes it now easier to extend and absolutely no worry to fetch the internalnpy_extobjonce and pass it around to anywhere needed. (It should be very fast to fetch now, so even multiple fetches are fine in practice.)- We need to include that information in the
contextpassed into ufuncs andget_loop. - We need to actually use it to dispatch :).
The first thing is well scoped, but a mid-sized project (not too hard really). The second thing should be very easy afterwards, but may need refactoring of the errstate handling as a follow-up to the first.
The second point is easy enough.
For the third point, we end up here currently: https://github.com/numpy/numpy/blob/main/numpy/core/src/umath/legacy_array_method.c#L195
that function can be customized freely for each ufunc. And the float context is even passed through to the inner-loop (but you need to customize that function to use the new-style inner-loop signature).
Now, we need to customize the get_loop(), which is a bit annoying in the current machinery. But I am not sure it is that bad: Matti effectively did the same for the ufunc.at loop specialization already.
Note that I am happy to leave ufunc->functions[i] function pointer that we currently use/fill at NULL. Nobody should be using that! (This part might need very managable followups if you want to keep supporting pnumpy style things, but I suspect that is a bridge that can be crossed when someone asks for it.)
(I am happy to close this, if there is no explicit interest.)