C99 Annex G recoveries for complex multiplication and division

Iason Krommydas via NumPy-Discussion <[email protected]> Wed, 29 Jul 2026 11:49:27 -0500
Newsgroups gmane.comp.python.numeric.general
Message-ID <[email protected]>
--===============7013718917177136226==
Content-Type: multipart/alternative;
	boundary="Apple-Mail=_A0B8D71A-7711-4E18-85CC-AB6A5DE4C90D"


--Apple-Mail=_A0B8D71A-7711-4E18-85CC-AB6A5DE4C90D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Hi all,

I would like to briefly talk about =
https://github.com/numpy/numpy/pull/30806 which adds C99 Annex G =
recoveries for complex multiplication and division that would otherwise =
result in nan + nanj. CPython has already implemented this and I =
attempted bringing this into numpy.

However, after all the investigation that you can see in the PR thread =
(and a short discussion with Nathan Goldbaum), we're leaning towards not =
doing this.
If you look a the latest benchmarks at the bottom of the PR thread, this =
adds a small but noticeable overhead even in the cases where there are =
no recoveries to be done. Another thing is that no other array libraries =
like jax or cupy do this so this would lead to different results among =
them.

I'm bringing this up in the mailing list to see if any other people have =
thoughts and agree or disagree with NOT doing this. I'm looking for =
arguments on why we should do this too if you have any. Keep in mind =
that this closes at least 4 issues listed in the PR description that =
should probably be closed as "won't do" if the decision is to not have =
this feature in.

Please share any thoughts you might have.

Kind regards,
Iason.=

--Apple-Mail=_A0B8D71A-7711-4E18-85CC-AB6A5DE4C90D
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

<html aria-label=3D"message body"><head><meta http-equiv=3D"content-type" =
content=3D"text/html; charset=3Dus-ascii"></head><body =
style=3D"overflow-wrap: break-word; -webkit-nbsp-mode: space; =
line-break: after-white-space;"><div>Hi all,</div><div><br></div><div>I =
would like to briefly talk about&nbsp;<a =
href=3D"https://github.com/numpy/numpy/pull/30806">https://github.com/nump=
y/numpy/pull/30806</a>&nbsp;which adds&nbsp;C99 Annex G recoveries for =
complex multiplication and division that would otherwise result =
in&nbsp;nan + nanj. CPython has already implemented this and I attempted =
bringing this into numpy.</div><div><br></div><div>However, after all =
the investigation that you can see in the PR thread (and a short =
discussion with Nathan Goldbaum), we're leaning towards not doing =
this.</div><div>If you look a the latest benchmarks at the bottom of the =
PR thread, this adds a small but noticeable overhead even in the cases =
where there are no recoveries to be done. Another thing is that no other =
array libraries like jax or cupy do this so this would lead to different =
results among them.</div><div><br></div><div>I'm bringing this up in the =
mailing list to see if any other people have thoughts and agree or =
disagree with NOT doing this. I'm looking for arguments on why we should =
do this too if you have any. Keep in mind that this closes at least 4 =
issues listed in the PR description that should probably be closed as =
"won't do" if the decision is to not have this feature =
in.</div><div><br></div><div>Please share any thoughts you might =
have.</div><div><br></div><div>Kind =
regards,</div><div>Iason.</div></body></html>=

--Apple-Mail=_A0B8D71A-7711-4E18-85CC-AB6A5DE4C90D--

--===============7013718917177136226==
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]

--===============7013718917177136226==--