Skip to content

Imaginary type and IEC 60559-compatible complex arithmetic #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 5 commits into
base: main
Choose a base branch
from

Conversation

skirpichev
Copy link
Owner

@skirpichev skirpichev commented May 25, 2024

"Generally, mixed-mode arithmetic combining real and complex variables should be performed directly, not by first coercing the real to complex, lest the sign of zero be rendered uninformative; the same goes for combinations of pure imaginary quantities with complex variables." (c) Kahan, W: Branch cuts for complex elementary functions.

That's why C standards since C99 introduce imaginary types. This patch implements similar extension to the Python language.

Lets consider (actually interrelated) problems, which will be solved on this way.

  1. Now complex arithmetic could be used for implementation of mathematical functions without special "corner cases", with textbooks formulae. Take the inverse tangent as an example:

    >>> z = complex(-0.0, 2)
    >>> cmath.atan(z)
    (-1.5707963267948966+0.5493061443340549j)
    >>> atan = lambda z: 1j*(cmath.log(1 - 1j*z) - cmath.log(1 + 1j*z))/2
    >>> atan(z)  # real part had wrong sign before
    (-1.5707963267948966+0.5493061443340549j)
    
  2. Previously, we have unsigned imaginary literals with the following semantics:

    a±bj = complex(a ± 0.0, ±b)
    complex(a, ±b)*cj = complex(a*0.0 ∓ b*c, a*c ± b*0.0)
    

    While this behaviour was well documented, most users would expect instead here:

    a±bj = complex(a, ±b)
    complex(a, ±b)*cj = complex(∓b*c, a*c)
    

    i.e. that it follows to the rectangular notation for complex numbers.

    For example:

    >>> -0.0+1j  # was 1j
    (-0.0+1j)
    >>> float('inf')*1j  # was (nan+infj)
    infj
    >>> -0.0+1j  # was 1j
    (-0.0+1j)
    >>> complex(-0.0, 1)  # was (-0+1j), note funny signed integer zero
    (-0.0+1j)
    
  3. The eval(repr(x)) == x invariant now holds for the complex type.

What's changed:

  • Added a new subtype (imaginary) of the complex type with few overloaded methods (conjugate() and __getnewargs__()).
  • Complex and imaginary types implement IEC 60559-compatible complex arithmetic (as specified by C11 Annex G).
  • Imaginary literals now produce instances of imaginary type.
  • cmath.infj/nanj were changed to be of imaginary type.
  • Modules ast, code, copy, marshal got support for imaginary type.
  • Few tests adapted to use complex, instead of imaginary literals
  • Print dot for signed zeros in the real part of repr(complex)
  • repr(complex) now prints real part even if it's zero.

@skirpichev skirpichev force-pushed the imaginary-class-109218 branch 2 times, most recently from 7323971 to 99d1b8c Compare May 25, 2024 13:45
@skirpichev skirpichev marked this pull request as ready for review June 4, 2024 05:57
@skirpichev skirpichev changed the title gh-109218: Imaginary type and IEC 60559-compatible complex arithmetic Imaginary type and IEC 60559-compatible complex arithmetic Jun 9, 2024
@skirpichev skirpichev force-pushed the imaginary-class-109218 branch 2 times, most recently from 4db428d to 6f13b24 Compare June 14, 2024 12:19
@skirpichev skirpichev force-pushed the imaginary-class-109218 branch 3 times, most recently from 4ca3e9a to c114f16 Compare June 29, 2024 09:16
skirpichev pushed a commit that referenced this pull request Jul 21, 2024
…ython#119498) (#1… (python#119905)

Revert "[3.12] pythongh-69214: Fix fcntl.ioctl() request type (python#119498) (python#119505)"

This reverts commit 078da88.

The change modified how negative values, like termios.TIOCSWINSZ, was
treated and is actually backward incompatible.
@skirpichev skirpichev force-pushed the imaginary-class-109218 branch from 36c6bf5 to 7e68e91 Compare July 25, 2024 07:51
@skirpichev skirpichev force-pushed the imaginary-class-109218 branch from 6a44153 to d605b8e Compare August 3, 2024 07:19
@skirpichev skirpichev force-pushed the imaginary-class-109218 branch from 2c3d2b4 to db12274 Compare October 1, 2024 04:15
@skirpichev skirpichev force-pushed the imaginary-class-109218 branch 2 times, most recently from 45dfe36 to f9edb38 Compare November 27, 2024 01:14
@skirpichev skirpichev marked this pull request as draft November 27, 2024 01:14
@skirpichev skirpichev force-pushed the imaginary-class-109218 branch 3 times, most recently from d56a55c to d062169 Compare November 28, 2024 02:24
@skirpichev skirpichev marked this pull request as ready for review February 11, 2025 06:37
@skirpichev skirpichev force-pushed the imaginary-class-109218 branch from b9c4ad2 to 1f62ac6 Compare April 15, 2025 10:03
@skirpichev skirpichev force-pushed the imaginary-class-109218 branch from 70419ab to 413dc1d Compare August 7, 2025 05:29
"Generally, mixed-mode arithmetic combining real and complex variables
should be performed directly, not by first coercing the real to complex,
lest the sign of zero be rendered uninformative; the same goes for
combinations of pure imaginary quantities with complex variables." (c)
Kahan, W: Branch cuts for complex elementary functions.

That's why C standards since C99 introduce imaginary types.  This patch
implements similar extension to the Python language.

Lets consider (actually interrelated) problems, which will be solved on
this way.

1) Now complex arithmetic could be used for implementation of
   mathematical functions without special "corner cases", with textbooks
   formulae.  Take the inverse tangent as an example:

       >>> z = complex(-0.0, 2)
       >>> cmath.atan(z)
       (-1.5707963267948966+0.5493061443340549j)
       >>> atan = lambda z: 1j*(cmath.log(1 - 1j*z) - cmath.log(1 + 1j*z))/2
       >>> atan(z)  # real part had wrong sign before
       (-1.5707963267948966+0.5493061443340549j)

2) Previously, we have unsigned imaginary literals with the following
   semantics:

       a±bj = complex(a ± 0.0, ±b)
       complex(a, ±b)*cj = complex(a*0.0 ∓ b*c, a*c ± b*0.0)

   While this behaviour was well documented, most users would expect
   instead here:

       a±bj = complex(a, ±b)
       complex(a, ±b)*cj = complex(∓b*c, a*c)

   i.e. that it follows to the rectangular notation for complex numbers.

   For example:

       >>> -0.0+1j  # was 1j
       (-0.0+1j)
       >>> float('inf')*1j  # was (nan+infj)
       infj
       >>> -0.0+1j  # was 1j
       (-0.0+1j)
       >>> complex(-0.0, 1)  # was (-0+1j), not funny signed integer zero
       (-0.0+1j)

3) The ``eval(repr(x)) == x`` invariant now holds for the complex type.

What's changed:

    * Added a new subtype (imaginary) of the complex type with
      few overloaded methods (conjugate() and __getnewargs__()).
    * Complex and imaginary types implement IEC 60559-compatible complex
      arithmetic (as specified by C11 Annex G).
    * Imaginary literals now produce instances of imaginary type.
    * cmath.infj/nanj were changed to be of imaginary type.
    * Modules ast, code, copy, marshal got support for imaginary type.
    * Few tests adapted to use complex, instead of imaginary literals
    * Print dot for signed zeros in the real part of repr(complex)
    * repr(complex) now prints real part even if it's zero.
@skirpichev skirpichev force-pushed the imaginary-class-109218 branch from 413dc1d to c1e8c55 Compare August 7, 2025 05:39
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant