On Wed, Mar 11, 2026 at 10:58 AM matti picus via NumPy-Discussion < numpy-discussion@python.org> wrote:
On Tue, Mar 10, 2026 at 1:28 PM Sebastian Berg <sebastian@sipsolutions.net> wrote:
Hi all,
In the NumPy 2.4 cycle, there were some native float16 implementations merged with rather low precision leading to the following issue: https://github.com/numpy/numpy/issues/30821
That is, previously, it used float loops so ~0.5 ULP error, now is is 2+ULP for many algorithms, on _some_ hardware: https://github.com/numpy/numpy/pull/23351
There is always an argument around that users of float16 probably don't care about many ULP, but I guess they also have very few bits of precision to begin with? I don't have a huge opinion on it, but we are more and more in the position where it is unclear if sacrificing a bit of precision is the right thing or not...
Similar questions actually arise for float32 math, is it OK to trade- off precision for performance (or to what degree, everything trades a bit)? We have had discussions around this before but it is still a difficult trade-off to make and there is no choice that makes everyone happy. [1]
- Sebastian
[1] We can work towards something like `np.opts(precision="low")` or so, but that doesn't change the question of defaults much...
I do like the idea of having a precise/fast toggle. Until we can develop one, I think we should prefer precise. So we should revert and document somewhere that float16 (and the soon-to-be-incoming bfloat16) are, in NumPy, container types, and that all the math for them is done as float16.
You meant `float32` here. And yes, I agree. Having a few code paths use platform/CPU-dependent instructions like AVX512-xxx ones, and as a result having a small subset of the NumPy API have different accuracy/speed trade-offs seems not all that useful to almost all users. And makes it harder to build up a mental model of what NumPy is actually doing. Cheers, Ralf