gh-120010: fix invalid (nan+nanj) results in _Py_c_prod()

[skirpichev]

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

• Issue: Invalid corner cases (resulting in nan+nanj) in _Py_c_prod() #120010

[vstinner]

cc @mdickinson

[picnixz]

Looks good!

[vstinner]

cc @serhiy-storchaka

[vstinner]

@skirpichev skirpichev requested a review from vstinner

Thanks for this change is beyond my IEEE-754 skills :-( Maybe @serhiy-storchaka can have a look?

[skirpichev]

This should be adjusted after merging #124829.

[skirpichev]

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.

[skirpichev]

@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.

[serhiy-storchaka]

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]

LGTM. But this is G.5.1, not G.5.2.