control precision for str(obj) output?

[Bo Peng]

Dear list,

I have enjoyed the convenience to output any object with str(obj) for a
while. However, I get long output for things like str([0.0002]) in my
output (which bothers my users more than me though). I also do not
understand why the following is happening:

>>> str([0.0002]) '[0.00020000000000000001]'
>>> str(0.0002)

'0.0002'

Is there any way to fix this, other than checking the type of everything
and output with %.4f?

Many thanks in advance.
Bo

 

[Mike Meyer]

Dear list,

I have enjoyed the convenience to output any object with str(obj) for
a while. However, I get long output for things like str([0.0002]) in
my output (which bothers my users more than me though). I also do not
understand why the following is happening:

str([0.0002]) '[0.00020000000000000001]'
str(0.0002)

'0.0002'

Is there any way to fix this, other than checking the type of
everything and output with %.4f?

Two things are going on here.

1) str is returning a "nicely printable" version of the object. For
floats, that means providing a precision so they behave as naive users
expect. repr, on the other hand, is returning a printable
representation of the object - which in the case of floats means the
true value of the float, not it's "nice" approximation.

2) str on a list uses repr to turn all the elements in the list to
strings for printing. This is pretty much required for strings to be
recognizable as such in the output.

And no, there's no way to control what repr is going to do. You could
subclass list and provide an str method that checks for floats, and
calls str on them instead of repr (probably better than using %.4f on
them all), but you can't really fix list.

Someone want to tell me the procedure for submitting FAQ entries, so I
can do that for this?

Thanks,
<mike

 

[Dan Bishop]

Dear list,

I have enjoyed the convenience to output any object with str(obj) for a
while. However, I get long output for things like str([0.0002]) in my

output (which bothers my users more than me though). I also do not
understand why the following is happening:

str([0.0002]) '[0.00020000000000000001]'
str(0.0002)

'0.0002'

Floats make a distinction betwen repr and str: repr(x) uses 17
significant digits (to ensure that repr(1.0) and repr(1.0+epsilon) are
distinct, while str(x) uses only 12 (to produce more user-friendly
output).

For lists, repr(x) calls repr(x) for each of its elements. Just
what you'd expect.

But lists, unlike floats, do *not* make a distinction between str and
repr; i.e. str(x) == repr(x). The main reason for doing it this way
was to avoid confusion in cases like str(["1, 2", 3]): If list.__str__
were implemented like the list_str function below, the result would
look like a list of 3 ints instead of a string and an int.

The unfortunate side effect of this is to make str(list of floats)
ugly, but...

Is there any way to fix this, other than checking the type of everything
and output with %.4f?

def list_str(x):
return '[%s]' % ', '.join(map(str, x))

 

[Bo Peng]

The unfortunate side effect of this is to make str(list of floats)

ugly, but...

Yeah, Nothing is perfect. I can control the damage as long as I know
what is going on. I guess this would fit in a faq list quite well.

I would have to thank Mike and Dan for your quick and detailed reply. As
a matter of fact, this python list is the most friendly mailinglist I
have ever joined. Thanks!

Bo

 

[Andrew Dalke]

Someone want to tell me the procedure for submitting FAQ entries, so I
can do that for this?

You mean more than what already exists at
http://www.python.org/doc/faq/general.html#why-are-floating-point-calculations-so-inaccurate

which has a link to an even more detailed chapter in the tutorial at
http://docs.python.org/tut/node16.html

?

Andrew
(e-mail address removed)

 

[Dan Bishop]

You mean more than what already exists at
http://www.python.org/doc/faq/general.html#why-are-floating-point-calculations-so-inaccurate

which has a link to an even more detailed chapter in the tutorial at
http://docs.python.org/tut/node16.html

Yes. Those pages explain why repr(0.2) != '0.2', but they don't
explain why str([x]) != '[%s]' % x .

 

[Bo Peng]

so I

You mean more than what already exists at

http://www.python.org/doc/faq/general.html#why-are-floating-point-calculations-so-inaccurate

which has a link to an even more detailed chapter in the tutorial at
http://docs.python.org/tut/node16.html

Yes. Those pages explain why repr(0.2) != '0.2', but they don't
explain why str([x]) != '[%s]' % x .

I am new to Python but has experience with other languages. I am quite
aware of 'why-are-floating-point-calculations-so-inaccurate'. I would
not be surprised if

>>> str[0.0002) 0.000200000000001
>>> str([0.0002])

[0.000200000000001]

It was the difference between str([x]) and '[%s]' % x str(x) that
confused me.

Bo

 

[Mike Meyer]

You mean more than what already exists at
http://www.python.org/doc/faq/general.html#why-are-floating-point-calculations-so-inaccurate

which has a link to an even more detailed chapter in the tutorial at
http://docs.python.org/tut/node16.html

Yes. Those pages explain why repr(0.2) != '0.2', but they don't
explain why str([x]) != '[%s]' % x .

Exactly. The point that needs to go in the FAQ is the behavior of str
on lists, not floating point representation. The latter needs to be
mentioned, but isn't critical.

A quick check of the Python site turns up no discussion on submitting
new FAQ entries. There are patch submission guidelines, and lots of
things related to the mailman FAQ, but nothing on how to submit new
entries for the FAQ. Or has the FAQ been supplanted by the wiki at
www.python.org/moin, even though there doesn't appear to be a FAQ
page?

<mike

 

[Michael Hoffman]

A quick check of the Python site turns up no discussion on submitting
new FAQ entries. There are patch submission guidelines, and lots of
things related to the mailman FAQ, but nothing on how to submit new
entries for the FAQ.

E-mail (e-mail address removed) and (e-mail address removed).

Or has the FAQ been supplanted by the wiki at
www.python.org/moin...

No.