complex representation
Terry Reedy
tjreedy at udel.edu
Mon Jul 7 21:46:48 EDT 2008
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.
More information about the Python-list
mailing list