results of division

[Paul McGuire]

"Paul Rubin" <http://phr.cx@NOSPAM.invalid> wrote in message
news:7xacsnjzj5.fsf at ruckus.brouhaha.com...
> Brad Tilley <bradtilley at gmail.com> writes:
> > What is the proper way to limit the results of division to only a few
> > spaces after the decimal? I don't need rocket-science like
> > precision. Here's an example:
> >
> > 1.775 is as exact as I need to be and normally, 1.70 will do.
>
> "%.2f"% 1.775

At the risk of kicking off *another* floating-point representation thread,
here is some odd string interp behavior (Python 2.3.4).

I seemed to recall in the past finding that the above syntax would not
round, but would instead truncate (old C runtime perhaps), so that even
printing 1.779 to 2 decimal places would print only "1.77".  So I tried a
few things at the Python prompt, and got some odd behavior.

>>> print "%.2f" % 1.776
1.78
>>> print "%.2f" % 1.774
1.77

Good so far, now let's try the borderline case:

>>> print "%.2f" % 1.775
1.77

Hmmm, if we rounded, I would have expected 1.775 to round up to 1.78.
Perhaps this is a floating point rep issue, that we are really rounding
1.7749999999999999999 or something.  Sure enough, repr shows us:

>>> repr(1.775)
'1.7749999999999999'

So I added a wee bit to 1.775:

>>> print "%.2f" % 1.775000000001
1.78

Ok, that looks better.  What if I round explicitly?

>>> print "%.2f" % round(1.775,2)
1.78

Errr?  How come round() is able to understand 1.775 correctly, whereas
string interp is not?  I'm guessing that round() adds some small epsilon to
the value to be rounded, or perhaps even does the brute force rounding I
learned in FORTRAN back in the 70's:  add 0.5 and truncate.  But this would
still truncate 1.779999999 to two places, so this theory fails also.  What
magic is round() doing, and should this same be done in the string interp
code?

-- Paul