gh-120010: fix invalid (nan+nanj) results in _Py_c_prod()#120287
gh-120010: fix invalid (nan+nanj) results in _Py_c_prod()#120287serhiy-storchaka merged 9 commits intopython:mainpython/cpython:mainfrom skirpichev:cc-in-py_c_prod-120010skirpichev/cpython:cc-in-py_c_prod-120010Copy head branch name to clipboard
Conversation
In some cases, previously computed as (nan+nanj), we could recover
meaningful component values in the result, see e.g. the C11, Annex
G.5.2, routine _Cmultd():
>>> z = 1e300+1j
>>> z*(nan+infj) # was (nan+nanj)
(-inf+infj)
That also fix some complex powers for small integer exponents, computed
with optimised algorithm (by squaring):
>>> z**5 # was (nan+nanj)
Traceback (most recent call last):
File "<python-input-1>", line 1, in <module>
z**5
~^^~
OverflowError: complex exponentiation
|
cc @mdickinson |
Misc/NEWS.d/next/Core and Builtins/2024-06-04-08-26-25.gh-issue-120010._z-AWz.rst
Outdated
Show resolved
Hide resolved
…e-120010._z-AWz.rst Co-authored-by: Bénédikt Tran <10796600+picnixz@users.noreply.github.com>
Thanks for this change is beyond my IEEE-754 skills :-( Maybe @serhiy-storchaka can have a look? |
|
This should be adjusted after merging #124829. |
|
|
||
| Py_complex | ||
| _Py_c_prod(Py_complex a, Py_complex b) | ||
| _Py_c_prod(Py_complex z, Py_complex w) |
There was a problem hiding this comment.
Should be ok now. This doesn't require a mixed-mode variant.
Yet, maybe I should change variable names back for consistency with the rest? Current naming here follows to the C standard.
There was a problem hiding this comment.
@serhiy-storchaka what do you think about renaming of arguments?
I think mapping local variables "abcd" -> "tuvw" will hot hurt readability and then we can preserve original argument names.
There was a problem hiding this comment.
I am fine with both variants. Preserving names from the old code can make the diff smaller, but in this case the new code is too different from the old code. Using names from the C standard examples helps comparing our code with the original code. The latter looks more important here.
serhiy-storchaka
left a comment
There was a problem hiding this comment.
LGTM. But this is G.5.1, not G.5.2.
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
…onGH-120287) In some cases, previously computed as (nan+nanj), we could recover meaningful component values in the result, see e.g. the C11, Annex G.5.1, routine _Cmultd(): >>> z = 1e300+1j >>> z*(nan+infj) # was (nan+nanj) (-inf+infj) That also fix some complex powers for small integer exponents, computed with optimized algorithm (by squaring): >>> z**5 # was (nan+nanj) Traceback (most recent call last): File "<python-input-1>", line 1, in <module> z**5 ~^^~ OverflowError: complex exponentiation
In some cases, previously computed as (nan+nanj), we could recover meaningful component values in the result, see e.g. the C11, Annex G.5.2, routine _Cmultd():
That also fix some complex powers for small integer exponents, computed with optimised algorithm (by squaring):