complex representation

[Terry Reedy]

DSM wrote:

> ISTM the same reasoning applies equally to complex numbers.  My interest
> arose because of what I think is a bug in pypy's complex printing:
> 
> 
>  Python 2.4.1 (pypy 1.0.0 build 56124) on linux2
>  Type "help", "copyright", "credits" or "license" for more information.
>  ``RPython: we use it so you don't have to''
>  >>>> (1.1+1.1j)**200
>  (240733537691613523198532543387690598400L+236495565429619338248192Lj)
> 
> 
> This strangeness comes about because a hack used to recover cpython's
> behaviour fails at large values.  (x.real == floor(x.real), so it
> decides the value's an integer, and returns the repr of int(x.real).)
> It's trivial to fix but I think cpython's behaviour is slightly odd
> here, and the real and imaginary parts of the complex repr should be
> identical to those of the underlying floats.

CPython 2.4, 2.5, and 3.0 on WinXP (and hence I presume 2.6) produce 
(with a trivial variation)
 >>> (1.1+1.1j)**200
(2.407335376916204e+38+2.3649556542962612e+23j)

That Pypy disagrees in the 14th digit is a bit odd, but I suspect a C 
math library difference.  Unless they are actually calculating 40 digits 
exactly, the extra digits should be filled with 0s if they want 
integers.  Take that, and whatever you think is strange, up with them.