# Pre-PEP: Imaginary type and IEC 60559-compatible complex arithmetic

**URL:** <https://discuss.python.org/t/pre-pep-imaginary-type-and-iec-60559-compatible-complex-arithmetic/77073>\
**Category:** Ideas\
**Created:** [January 14, 2025, 6:56am UTC](https://discuss.python.org/t/pre-pep-imaginary-type-and-iec-60559-compatible-complex-arithmetic/77073 "2025-01-14T06:56:24Z")\
**Posts on this page:** 1\
**Showing post:** 3

<div class="post-metadata">

**Author:** ![skirpichev](https://sea2.discourse-cdn.com/flex002/user_avatar/discuss.python.org/skirpichev/32/10996_2.png) [@skirpichev](https://discuss.python.org/u/skirpichev)\
**Post date:** [January 14, 2025, 11:28am UTC](https://discuss.python.org/t/pre-pep-imaginary-type-and-iec-60559-compatible-complex-arithmetic/77073/3 "2025-01-14T11:28:43Z")

</div>

> [@mdickinson](#):
>
> It might be good to understand _why_ adoption was so poor

I suspect we all know the _obvious_ answer, but I think it’s rather hard to verify that it’s the _right_ answer. For example, not all major compilers (e.g. msvc) even support Annex G. Does it mean there is something wrong with the standard?

Another answer might be, that Annex G still has small user base. For example, the GNU GSL supports (incorrectly) native complex numbers since 2021, while it’s API has all primitives for mixed-mode arithmetic.

Also, it seems most (all?) current compilers, supporting Annex G, implement mixed-mode arithmetic for real operands. Should we interpret this, that only _that_ part of the approach, advocated by Kahan, is important? For me, it seems that [removal message](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3240.pdf) from the WG 14 just ignores all mathematical arguments for this feature (e.g. WG’s documents, quoted in my post).

BTW, in principle, I think we _can_ avoid new type at cost of adding some special forms for the complex constructor (mostly invisible for users). Say, `complex(real=x, pure=True)` (a copy of real line) and `complex(imag=y, pure=True)` (for pure-imaginary numbers). Imaginary literals will be translated to the second form. Also, doing complex arithmetic, floats will be automatically coerced to the first form. The rest (i.e. arithmetic rules) is same as in the proposed version. But I suspect that this implementation will be more complicated internally.

> [@mdickinson](#):
>
> My main concern would be the knock-on effect on 3rd party packages (NumPy, SymPy, many more).

Maybe positive? What’s bad in replacing incorrect or meaningless answers like `(cmath.inf+1j)*2` currently?

For the mpmath it eventually allows to drop some boilerplate code and write instead:

```py
@defun_wrapped
def acot(ctx, z):
    return ctx.atan(ctx.one / z)

@defun_wrapped
def asec(ctx, z):
    return ctx.acos(ctx.one / z)

@defun_wrapped
def acsc(ctx, z):
    return ctx.asin(ctx.one / z)

```

(And silently fix all functions, that now miss required checks for special complex numbers :-))

For the gmpy2, mixed-mode rules could be implemented as for CPython. As it was noted before, the MPC library has all primitives to support this.

---

_[View the full topic](https://discuss.python.org/t/pre-pep-imaginary-type-and-iec-60559-compatible-complex-arithmetic/77073)._