]> git.ipfire.org Git - thirdparty/Python/cpython.git/commit
[3.12] gh-113841: fix possible undefined division by 0 in _Py_c_pow() (GH-127211...
authorMiss Islington (bot) <31488909+miss-islington@users.noreply.github.com>
Mon, 2 Dec 2024 19:47:42 +0000 (20:47 +0100)
committerGitHub <noreply@github.com>
Mon, 2 Dec 2024 19:47:42 +0000 (19:47 +0000)
commit8fffbb098259ed413d75dbc2e6d3e540425bd9b9
treeebc6f0380203fee15667e74fcad3694538c80a91
parent34fe4af8a21366de329a3a69d7e87363060bccba
[3.12] gh-113841: fix possible undefined division by 0 in _Py_c_pow() (GH-127211) (GH-127216) (GH-127530)

[3.13] gh-113841: fix possible undefined division by 0 in _Py_c_pow() (GH-127211) (GH-127216)

Note, that transformed expression is not an equivalent for original one (1/exp(-x) != exp(x) in general for floating-point numbers). Though, the difference seems to be ~1ULP for good libm implementations.

It's more interesting why division was used from beginning. Closest algorithm I've found (no error checks, of course;)) - it's Algorithm 190 from ACM: https://dl.acm.org/doi/10.1145/366663.366679. It uses subtraction in the exponent.

(cherry picked from commit f7bb658124aba74be4c13f498bf46cfded710ef9)

(cherry picked from commit f41d8d89e79d634895868656f50a0e16e339f9d6)

Co-authored-by: Sergey B Kirpichev <skirpichev@gmail.com>
Lib/test/test_complex.py
Misc/NEWS.d/next/Core_and_Builtins/2024-11-24-07-01-28.gh-issue-113841.WFg-Bu.rst [new file with mode: 0644]
Objects/complexobject.c