[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Mark Dickinson added the comment: Re-closing; we should be good now. -- stage: patch review -> resolved status: open -> closed ___ Python tracker ___ _

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Mark Dickinson added the comment: New changeset beb3a835dae3cd940b93e7caa32450890c4cd539 by Miss Islington (bot) in branch '3.9': bpo-44698: Restore complex pow behaviour for small integral exponents (GH-27772) (GH-27797) https://github.com/python/cpython/commit/beb3a835dae3cd940b93e7caa3245

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Mark Dickinson added the comment: New changeset 3f81e9628f6f104c103d0e38adb84c51e5261626 by Miss Islington (bot) in branch '3.10': bpo-44698: Restore complex pow behaviour for small integral exponents (GH-27772) (GH-27796) https://github.com/python/cpython/commit/3f81e9628f6f104c103d0e38adb8

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Change by miss-islington : -- pull_requests: +26265 pull_request: https://github.com/python/cpython/pull/27796 ___ Python tracker ___ __

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Change by miss-islington : -- pull_requests: +26266 pull_request: https://github.com/python/cpython/pull/27797 ___ Python tracker ___ __

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Mark Dickinson added the comment: New changeset 4b9a2dcf19e5d13c3bc2afea2de1f65cd994c699 by Mark Dickinson in branch 'main': bpo-44698: Restore complex pow behaviour for small integral exponents (GH-27772) https://github.com/python/cpython/commit/4b9a2dcf19e5d13c3bc2afea2de1f65cd994c699 ---

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Mark Dickinson added the comment: Thanks, Pablo! > could you add me as a reviewer for the backport Will do! I'll waiting on review for the PR against the main branch, but hope to get the backport PR up by this coming weekend at the latest. -- ___

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Pablo Galindo Salgado added the comment: I'm keeping track to the 3.10 backports to the second rc so could you add me as a reviewer for the backport? -- ___ Python tracker __

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Pablo Galindo Salgado added the comment: > GH-27772 reverts the behaviour change but keeps the fix for the undefined > behaviour. Can the backport of GH-27772 to the 3.10 branch go in before > 3.10.0 final? Thanks for checking with me! Given that this is fixing a bug that we introduced in

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Mark Dickinson added the comment: @Pablo: I'm adding you to the nosy list to get your opinion on whether (the backport of) GH-27772 can go into 3.10.0.rc2. Summary: GH-27278 (which I reviewed and approved) and its backports fixed some undefined behaviour in complex exponentiation, but also i

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Change by Mark Dickinson : -- pull_requests: +26246 stage: resolved -> patch review pull_request: https://github.com/python/cpython/pull/27772 ___ Python tracker ___ __

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Sebastian Berg added the comment: Thanks for looking into it! `cpow` is indeed complicated. We had some discussion in NumPy about `0**y` branch cuts (I did yet not finish it, because thinking about the branch cuts is tricky). It is almost reassuring that the C standard also hedges out :).

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Mark Dickinson added the comment: > brave or foolhardy enough to try to figure out what all of the special case > results *should* be for complex pow Addendum: even the C standards give up at this point. For everything else the special cases are spelled out in detail, but for cpow, from §G.6.

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Change by Mark Dickinson : -- assignee: twouters -> mark.dickinson status: closed -> open ___ Python tracker ___ ___ Python-bugs-lis

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Mark Dickinson added the comment: > a double-check that the behaviour change is desirable I'm not sure I'm brave or foolhardy enough to try to figure out what all of the special case results *should* be for complex pow. The special cases seem reasonably clear cut for everything else in the c

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Mark Dickinson added the comment: Thanks, @seberg. I'll take a look and see if we can restore the old behaviour, at least for Python 3.9 and 3.10. I'm not convinced that the new behaviour is objectively wrong, but I agree that the *change* in behaviour is problematic. I do find it a little o

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Sebastian Berg added the comment: (Sorry for the spam. I think we can/should just hard-code the expected values in the NumPy test-suite. So this is not actually an issue for NumPy and probably just warrants a double-check that the behaviour change is desirable.) -- ___

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Sebastian Berg added the comment: Hmm, sorry, I overshot/misread :(. The thing that the NumPy test-suite trips over is that: c_powi(inf+0j, 3) seems to not raise, but: _Py_c_pow(inf+0j, 3.+0j) (or nan+0.j rather then inf+0j) does seem to raise (returning `nan+nanj` in both cases).

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Sebastian Berg added the comment: The fix broke NumPy (see also https://github.com/numpy/numpy/pull/19612) It seems incorrect. After all, it doesn't matter much whether the float can be converted to an integer correctly (or even if it returns an undefined value), so long `int_value == float

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Łukasz Langa added the comment: New changeset 85ac81499ec5fb156a57408bcd95b06de4531488 by Miss Islington (bot) in branch '3.9': bpo-44698: Fix undefined behaviour in complex exponentiation. (GH-27278) (GH-27367) https://github.com/python/cpython/commit/85ac81499ec5fb156a57408bcd95b06de4531488

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Łukasz Langa added the comment: New changeset 256d97c8a3151ec7caba6c06bf2a1e682008c304 by Miss Islington (bot) in branch '3.10': bpo-44698: Fix undefined behaviour in complex exponentiation. (GH-27278) (#27366) https://github.com/python/cpython/commit/256d97c8a3151ec7caba6c06bf2a1e682008c304

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Change by Łukasz Langa : -- resolution: -> fixed stage: patch review -> resolved status: open -> closed ___ Python tracker ___ ___ P

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Change by miss-islington : -- pull_requests: +25905 pull_request: https://github.com/python/cpython/pull/27367 ___ Python tracker ___ __

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Change by miss-islington : -- nosy: +miss-islington nosy_count: 5.0 -> 6.0 pull_requests: +25904 pull_request: https://github.com/python/cpython/pull/27366 ___ Python tracker _

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Łukasz Langa added the comment: New changeset 1d582bbc969e05896addf97844ddf17ce9830e5e by T. Wouters in branch 'main': bpo-44698: Fix undefined behaviour in complex exponentiation. (GH-27278) https://github.com/python/cpython/commit/1d582bbc969e05896addf97844ddf17ce9830e5e -- nosy: +

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Change by Raymond Hettinger : -- nosy: +tim.peters ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Change by Raymond Hettinger : -- nosy: +mark.dickinson ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https:

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

Change by Thomas Wouters : -- keywords: +patch pull_requests: +25823 stage: -> patch review pull_request: https://github.com/python/cpython/pull/27278 ___ Python tracker ___ _

[issue44698] Undefined behaviour in Objects/complexobject.c's complex_pow

New submission from Thomas Wouters : Objects/complexobject.c's complex_pow uses undefined behaviour, by casting a float of unknown magnitude to a long: int_exponent = (long)exponent.real; At Google we build with clang and -fsanitize=float-cast-overflow by default, which catches this part