Identical floats print inconsistently

[gihon]

BPO	1534769
Nosy	@tim-one, @birkenfeld

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2006-08-05.06:24:03.000>
created_at = <Date 2006-08-04.20:07:00.000>
labels = ['invalid']
title = 'Identical floats print inconsistently'
updated_at = <Date 2006-08-05.06:24:03.000>
user = 'https://bugs.python.org/gihon'

bugs.python.org fields:

activity = <Date 2006-08-05.06:24:03.000>
actor = 'gihon'
assignee = 'none'
closed = True
closed_date = None
closer = None
components = ['None']
creation = <Date 2006-08-04.20:07:00.000>
creator = 'gihon'
dependencies = []
files = []
hgrepos = []
issue_num = 1534769
keywords = []
message_count = 4.0
messages = ['29447', '29448', '29449', '29450']
nosy_count = 3.0
nosy_names = ['tim.peters', 'georg.brandl', 'gihon']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = None
url = 'https://bugs.python.org/issue1534769'
versions = []

[gihon]

Hi, and thank you.

Many bugs relating to this have been submitted by
others over a period of years, and these have generally
been closed with "not a bug" responses. I'll do my
best to explain the problem clearly enough.

The following session prints a single variable three
ways, with two different results:

-----------

[me@localhost current]$ python
Python 2.4.1 (#1, May 16 2005, 15:19:29)
[GCC 4.0.0 20050512 (Red Hat 4.0.0-5)] on linux2
Type "help", "copyright", "credits" or "license" for
more information.
>>> a = round(1./7, 3)
>>> print a
0.143
>>> print (a,)
(0.14299999999999999,)
>>> print (a,)[0]
0.143
>>>

---

I'm fully informed about IEEE floating point
representations in binary, but the limitations of data
type are not causing the difference in output. The
interpreter is using different rules to print this
float, depending on whether it's a straight float or
part of some other structure (in this example, a tuple).

Once the interpreter recurses to a depth where it's
clearly going to print a float, whatever rule is
selected needs to be consistently applied. This means
calling the same string formatting code with the same
inputs.

Marc

[birkenfeld]

Logged In: YES
user_id=849994

Sorry, but this is another "not a bug".

"print tuple" invokes tuple.__repr__() (because there is no
separate __str__) which invokes repr(item) on each tuple
item, while "print item" invokes str(item). For floats, this
distinction results in a different rounding precision.

[tim-one]

Logged In: YES
user_id=31435

gbrandl is correct that the differences here are entirely
due to the difference between float's __repr__ and __str__
methods. The reasons they /are/ different for floats are
explained in the Tutorial's appendix on floating-point issues.

It may be considered unfortunate that tuple.__repr__ is the
same as tuple.__str__, and that both "pass repr down" to
containees, but the reason for that has to do with the
difference between str.__repr__ and str.__str__. If
str(tuple) "passed str down" to containees, then, e.g.,

print ("a, bc", "de f,", "gh), i")

would display the incomprehensibly confused:

(a, bc, de f,, gh), i)

IOW, it's actually the difference in what string types do
that /drives/ the general decision that c.str is the
same as c.repr for all objects c of container types,
and that both "pass repr down" to containees.

Alas, that's not always what people using strings want
either :-)

[gihon]

Logged In: YES
user_id=789149

Hi Tim and Georg,

Thanks for your kind replies. I've followed up with feature
request 1534942, suggesting that print pass down __strep__,
which passes itself down. __strep__ prints floats with
__str__ and everything else with __rep__.

Enjoy the weekend! I'll be writing a ray tracer....

Marc