Re: complex representation

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Terry Reedy

    Re: complex representation

    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
    (24073353769161 352319853254338 7690598400L+236 495565429619338 248192Lj)
    >
    >
    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)**2 00
    (2.407335376916 204e+38+2.36495 56542962612e+23 j)

    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.

Working...