[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>
except OverflowError:
pass
+ # gh-113841: possible undefined division by 0 in _Py_c_pow()
+ x, y = 9j, 33j**3
+ with self.assertRaises(OverflowError):
+ x**y
+
def test_pow_with_small_integer_exponents(self):
# Check that small integer exponents are handled identically
# regardless of their type.
--- /dev/null
+Fix possible undefined behavior division by zero in :class:`complex`'s
+:c:func:`_Py_c_pow`.
at = atan2(a.imag, a.real);
phase = at*b.real;
if (b.imag != 0.0) {
- len /= exp(at*b.imag);
+ len *= exp(-at*b.imag);
phase += b.imag*log(vabs);
}
r.real = len*cos(phase);