Re: Should we revert float16 loops (and what are the precision requirements)?

--===============4589537148546204747==
Content-Type: multipart/alternative; boundary="000000000000b9aee9064cbd899b"

--000000000000b9aee9064cbd899b
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Wed, Mar 11, 2026 at 10:58=E2=80=AFAM matti picus via NumPy-Discussion <
[email protected]> wrote:

> On Tue, Mar 10, 2026 at 1:28=E2=80=AFPM Sebastian Berg
> <[email protected]> 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=3D"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

--000000000000b9aee9064cbd899b
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote g=
mail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, Mar 11,=
 2026 at 10:58=E2=80=AFAM matti picus via NumPy-Discussion &lt;<a href=3D"m=
ailto:[email protected]">[email protected]</a>&gt; wrot=
e:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0=
.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Tue, Mar 1=
0, 2026 at 1:28=E2=80=AFPM Sebastian Berg<br>
&lt;<a href=3D"mailto:[email protected]" target=3D"_blank">sebasti=
[email protected]</a>&gt; wrote:<br>
&gt;<br>
&gt; Hi all,<br>
&gt;<br>
&gt; In the NumPy 2.4 cycle, there were some native float16 implementations=
<br>
&gt; merged with rather low precision leading to the following issue:<br>
&gt; <a href=3D"https://github.com/numpy/numpy/issues/30821" rel=3D"norefer=
rer" target=3D"_blank">https://github.com/numpy/numpy/issues/30821</a><br>
&gt;<br>
&gt; That is, previously, it used float loops so ~0.5 ULP error, now is is<=
br>
&gt; 2+ULP for many algorithms, on _some_ hardware:<br>
&gt; <a href=3D"https://github.com/numpy/numpy/pull/23351" rel=3D"noreferre=
r" target=3D"_blank">https://github.com/numpy/numpy/pull/23351</a><br>
&gt;<br>
&gt; There is always an argument around that users of float16 probably don&=
#39;t<br>
&gt; care about many ULP, but I guess they also have very few bits of<br>
&gt; precision to begin with?<br>
&gt; I don&#39;t have a huge opinion on it, but we are more and more in the=
<br>
&gt; position where it is unclear if sacrificing a bit of precision is the<=
br>
&gt; right thing or not...<br>
&gt;<br>
&gt; Similar questions actually arise for float32 math, is it OK to trade-<=
br>
&gt; off precision for performance (or to what degree, everything trades a<=
br>
&gt; bit)?<br>
&gt; We have had discussions around this before but it is still a difficult=
<br>
&gt; trade-off to make and there is no choice that makes everyone happy. [1=
]<br>
&gt;<br>
&gt; - Sebastian<br>
&gt;<br>
&gt; [1] We can work towards something like `np.opts(precision=3D&quot;low&=
quot;)` or<br>
&gt; so, but that doesn&#39;t change the question of defaults much...<br>
<br>
I do like the idea of having a precise/fast toggle. Until we can<br>
develop one, I think we should prefer precise. So we should revert and<br>
document somewhere that float16 (and the soon-to-be-incoming bfloat16)<br>
are, in NumPy, container types, and that all the math for them is done<br>
as float16.<br></blockquote><div><br></div><div>You meant `float32` here. A=
nd yes, I agree. Having a few code paths use platform/CPU-dependent instruc=
tions like AVX512-xxx ones, and as a result having a small subset of the Nu=
mPy 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.</div><div><br></div><div>Cheers,<br></div><div>Ra=
lf</div><div><br></div></div></div>

--000000000000b9aee9064cbd899b--

--===============4589537148546204747==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
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]

--===============4589537148546204747==--