Thank you, Sergey. At your convenience, can you take a look at the current _Py_c_pow() and complex_pow() and tell me if you like this approach (using an extra int *e parameter)?
I agree abs and quot should be similar to whatever we do for pow, and then we can also look at errno in mathmodule.c and cmathmodule.c.

I have another question: is the C API function intended to give the same results as the Python function? If so, should the code that checks whether the exponent has a small integer value (and if so uses a faster and more accurate algorithm) be put into cpow? In other words, complex_pow should call c_pow, and c_pow will have the optimization to call c_powi if exponent is a small integer.

[I'm busy for next few days but should have time on the weekend.]

can you take a look at the current _Py_c_pow() and complex_pow() and tell me if you like this approach (using an extra int *e parameter)?

I don't understand why you need additional variable, instead of using errno. This only makes patch bigger. Using errno to communicate errors looks reasonable here, like for most cmath's functions.

BTW, probably you can get rid of using errno in float.__round__() (see double_round()) helper. But again, I don't see much sense. We use here bundled David Gay's code (modified a lot) and don't depend on platform libm quirks.

is the C API function intended to give the same results as the Python function?

No, I don't think so. This "API" was available as an accident. It's soft-deprecated, that means we will not enhance it further. See also capi-workgroup/decisions#56.

Sergey, I added some of your code and ideas from 118000. You are welcome to take anything you want from here and add it to your PR if you like.

I modified your gmpy2 testing script to make the following two tests:

from cmath import isclose, isfinite, isinf, isnan
from math import copysign, inf, nan

from gmpy2 import mpc


def issamesign(x, y):
    return copysign(1., x) == copysign(1., y)

def printerr(a, b, gr, pr):
    global nfail
    print(f"{a:<12} {b:<12} {gr:<12.2} {pr:<12.2}")
    nfail += 1

def printexceptionerr(a, b, gr, exception):
    global nfail
    print(f"{a:<12} {b:<12} {gr:<12.2} {exception:<12}")
    nfail += 1

cases = [-inf, -0.5, -0.0, +0.0, +0.5, +inf, nan]
values = [mpc(x, y) for x in cases for y in cases]

print(f"{'base':<12} {'exp':<12} {'gmpy2':<12} {'python':<12}")
print(f"{'':=<12} {'':=<12} {'':=<12} {'':=<12}")

nfail = 0

for ga in values:
    for gb in values:
        a = complex(ga.real, ga.imag)
        b = complex(gb.real, gb.imag)
        gr = ga**gb
        gr = complex(gr.real, gr.imag)
        try:
            pr = a**b
        except ZeroDivisionError:
            # Note: gmpy2 returns 0j for 0j ** (0.5+0.5j) and others.
            # However, Python raises ZeroDivisionError for the following:
            #   a equals zero and b.imag is nonzero
            #   a equals zero and b.real is negative
            if not a == 0.0j or not (b.imag != 0.0 or b.real < 0.0):
                printexceptionerr(a, b, gr, "ZeroDivisionError")
            continue
        except OverflowError:
            # Raised when the result is too large to be represented.
            # This should not occur for the input values in this test.
            printexceptionerr(a, b, gr, "OverflowError")
            continue

        if isfinite(gr):
            if not (issamesign(gr.real, pr.real)
                    and issamesign(gr.imag, pr.imag)
                    and isclose(gr, pr)):
                printerr(a, b, gr, pr)
            continue
        if str(gr) != str(pr):
            printerr(a, b, gr, pr)

print(f"{'':=<52}")
print(f"Failures: {nfail} ({nfail/len(cases)**4:.0%})")

from cmath import isclose, isfinite, isinf, isnan
from math import copysign, inf, nan

from gmpy2 import mpc


def issamesign(x, y):
    return copysign(1., x) == copysign(1., y)

def printerr(a, b, gr, pr):
    global nfail
    print(f"{a:<12} {b:<12} {gr:<12.2} {pr:<12.2}")
    nfail += 1

def printexceptionerr(a, b, gr, exception):
    global nfail
    print(f"{a:<12} {b:<12} {gr:<12.2} {exception:<12}")
    nfail += 1

bases = [-inf, -2.0, -1.0, -0.5, -0.0, +0.0, +0.5, +1.0, +2.0, +inf, nan]
avalues = [mpc(x, y) for x in bases for y in bases]

exps = [-100.0, -20.0, -2.0, -1.0, -0.0, +0.0, +1.0, +2.0, +20.0, +100.0]
bvalues = [mpc(x, 0.0) for x in exps]

print(f"{'base':<12} {'exp':<12} {'gmpy2':<12} {'python':<12}")
print(f"{'':=<12} {'':=<12} {'':=<12} {'':=<12}")

nfail = 0

for ga in avalues:
    for gb in bvalues:
        a = complex(ga.real, ga.imag)
        b = complex(gb.real, gb.imag)
        gr = ga**gb
        gr = complex(gr.real, gr.imag)
        try:
            pr = a**b
        except ZeroDivisionError:
            # Python raises ZeroDivisionError for the following:
            #   a equals zero and b.imag is nonzero
            #   a equals zero and b.real is negative
            if not a == 0.0j or not (b.imag != 0.0 or b.real < 0.0):
                printexceptionerr(a, b, gr, "ZeroDivisionError")
            continue
        except OverflowError:
            # Raised when the result is too large to be represented.
            # This should not occur for the input values in this test.
            printexceptionerr(a, b, gr, "OverflowError")
            continue

        if isfinite(gr):
            if not (issamesign(gr.real, pr.real)
                    and issamesign(gr.imag, pr.imag)
                    and isclose(gr, pr)):
                printerr(a, b, gr, pr)
            continue
        if str(gr) != str(pr):
            printerr(a, b, gr, pr)

print(f"{'':=<52}")
print(f"Failures: {nfail} ({nfail/(len(avalues)*len(bvalues)):.0%})")

I want to look into the results more carefully, but here's a quick summary:

Also, I made a performance test:

#!/usr/bin/env ./python
import time
import pyperf

def bench_cpow(loops, n):
    z = complex(3.140625, 1.0)
    range_it = range(loops)
    t0 = time.perf_counter()
    for _ in range_it:
        result = z**n
        result = z**n
        result = z**n
        result = z**n
        result = z**n
        result = z**n
        result = z**n
        result = z**n
        result = z**n
        result = z**n
        result = z**n
        result = z**n
        result = z**n
        result = z**n
        result = z**n
        result = z**n
        result = z**n
        result = z**n
        result = z**n
        result = z**n
    return time.perf_counter() - t0

runner = pyperf.Runner(values=10, processes=24)
for n in (-5, -4, -3, -2, -1, 1, 2, 3, 4, 5):
    runner.bench_time_func(f"cpow(z, {n})", bench_cpow, n, inner_loops=20)

I'm happy to wait on the complex part of the errno stuff until 118000 is resolved.

Also, I'd like to see 153148 (fix for atan2 for Intel math library and Solaris) merged. I think that will show some amount of acceptance for removing errno. (BTW, I would suggest backporting 153148 to Python 3.14 and 3.15, but I guess there's a robot to do that if wanted.)

Note, that you can configure gmpy2 to raise exceptions like Python:

>>> from gmpy2 import *
>>> mpc(0)**-1
mpc('inf+nanj')
>>> ctx = get_context()
>>> ctx.trap_divzero = True
>>> mpc(0)**-1
Traceback (most recent call last):
  File "<python-input-4>", line 1, in <module>
    mpc(0)**-1
    ~~~~~~^^~~
gmpy2.DivisionByZeroError: division by zero

Also, I made a performance test

That close to my results:

I'm happy to wait on the complex part of the errno stuff until 118000 is resolved.

I would appreciate your review on that pr.

import pyperf

z = complex(3.140625, 1.0)

runner = pyperf.Runner()
for n in (-5, -4, -3, -2, -1, 1, 2, 3, 4, 5):
    runner.bench_func(f"pow(z, {n})", pow, z, n)

I want to make a few quick notes before bedtime.

• I did submit a PR upstream as you suggested for only the floatobject errno changes.
• I rewrote c_powi(). There is no need to copy x into p. I just use x. Also x = _Py_c_prod(x, x); is at the top of the loop instead of at the bottom so it does not always do one unnecessary product before the loop exits. I hope you will consider doing it this way in 118000.
• In general, I don't know how best to organize this PR with 118000. One possibility is to merge them into a single PR. But maybe reviewers prefer smaller pieces?
• I deleted c_powu()
• Now, complex_pow() only calls c_pow() and raises a python error if necessary. The C API function _Py_c_pow() also calls c_pow() and sets errno if necessary. If small integer exponent, c_pow() calls c_powi(). Note that now both Python and the C API function return the same bits.
• I'm not sure I like the test you added self.assertComplexesAreIdentical(c**-n, 1/(c**n)) since it's enforcing an implementation. I guess it's OK if the idea is the test can change if the implementation changes. For example, the results won't be identical if the C math library's cpow() is used instead of the current c_pow(). Maybe this is something worth considering for the future?
• I confirmed using the methodology in https://inria.hal.science/hal-04714173 that cpowi is more accurate than without it when n is positive. (Though, I did a faster run, not as thorough as we did for the paper, so expect some variation. It uses random number generator to make test points.) See graph below. Red is c_pow() without the small integer exponent optimization. Black is this PR. The error is measured against mpc_pow_si().

That's not what I see when n is negative. Then, I'm getting errors over 1.0e+15 for cpowi. Maybe bug in my measurements. Maybe need to think of better alternative than r = _Py_rc_quot(1.0, r); at end of c_powi().....

I did submit a PR upstream as you suggested for only the floatobject errno changes.

Thanks, I approved this with one minor comment.

I rewrote c_powi(). There is no need to copy x into p. I just use x. Also x = _Py_c_prod(x, x); is at the top of the loop instead of at the bottom so it does not always do one unnecessary product before the loop exits. I hope you will consider doing it this way in 118000.
[...]
I deleted c_powu()

I tried to keep the patch small and focused on the issue. Maybe your rewriting optimizes things a bit more, but that should be checked by benchmarks. Speedup might be less obvious for pure-Python code, due to runtime overhead. And as _Py_c_pow() is soft-deprecated, I don't think that it will be easy to sell optimizations on the C-API layer.

I'm not sure I like the test you added self.assertComplexesAreIdentical(c**-n, 1/(c**n)) since it's enforcing an implementation.

I think this belongs to the pr thread. Perhaps, I should split this test and put part of it (or all) under @cpython_only decorator.

The complex arithmetic has very vague specification in the Python language. E.g. should complex multiplication be commutative? This is something I tried to address in python/peps#4681 (now skirpichev/peps#10).

That's not what I see when n is negative. Then, I'm getting errors over 1.0e+15 for cpowi.

Could you share your benchmark script?