D
DSM
From the nothing-is-so-trivial-it's-not-worth-a-usenet-post file:
Shouldn't the default representation of complex numbers be like that of
floats? That is, have a decimal point?
(1+1j)
In the relevant bit of floatobject.c, there's a comment explaining that
1.0 isn't accidental:
/* Subroutine for float_repr and float_print.
We want float numbers to be recognizable as such,
i.e., they should contain a decimal point or an exponent.
However, %g may print the number as an integer;
in such cases, we append ".0" to the string. */
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'' (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.
Or is there some reason I'm missing that things are the way they are?
Shouldn't the default representation of complex numbers be like that of
floats? That is, have a decimal point?
(1+1j)
In the relevant bit of floatobject.c, there's a comment explaining that
1.0 isn't accidental:
/* Subroutine for float_repr and float_print.
We want float numbers to be recognizable as such,
i.e., they should contain a decimal point or an exponent.
However, %g may print the number as an integer;
in such cases, we append ".0" to the string. */
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'' (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.
Or is there some reason I'm missing that things are the way they are?