results of division

[Brad Tilley]

Hello,

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.

Thank you,
Brad

 

[Simon Brunning]

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.

Use the new decimal type - <http://www.python.org/doc/2.4/whatsnew/node9.html>.

 

[Paul Rubin]

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

 

[Aahz]

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.

You have two options: use floating point and round manually or use the
new Decimal class and specify your precision. However, if you restrict
your calculations, you will have errors after chaining more than one or
two operations. Your best bet is to perform rounding only at the end of
your calculations, at which point you can either round the result
directly or round for display only (by using appropriate % formatting).

 

[Peter Hansen]

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.

The answer is "what are you trying to do?". The others have
given options and good advice, but the "right" approach
depends on what exactly you are doing. Is this just for
display purposes, or is there more significant (though
perhaps not "precision-critical") calculation going on?

-Peter

 

[Paul McGuire]

"%.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.
1.77

Good so far, now let's try the borderline case:
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:
'1.7749999999999999'

So I added a wee bit to 1.775:
1.78

Ok, that looks better. What if I round explicitly?
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

 

[Brad Tilley]

Use the new decimal type - <http://www.python.org/doc/2.4/whatsnew/node9.html>.

Ah, quantize() works great. Thank you for the tip.

 

[Brad Tilley]

The answer is "what are you trying to do?". The others have
given options and good advice, but the "right" approach
depends on what exactly you are doing. Is this just for
display purposes, or is there more significant (though
perhaps not "precision-critical") calculation going on?

-Peter

I'm summing up the bytes in use on a hard disk drive and generating a
report that's emailed based on the percentage of the drive in use. I
know there are other ways to do this, but I like Python and I like to
write my own code. I always find comp.lang.python a very helpful place.

Thank you,

Brad

 

[Tim Peters]

[Paul McGuire]
....

1.77

Hmmm, if we rounded, I would have expected 1.775 to round up
to 1.78.

Platform-dependent. 1.775 isn't exactly representable regardless, but
whether exactly-half-way numbers that are exactly representable round
up or truncate varies across platform C libraries. For example, 1.25
is exactly representable in binary fp, but '%.1f' % 1.25 produces 1.3
on Windows but 1.2 on most other platforms (most non-Microsoft C
runtimes use the IEEE "round to nearest or even" rule).

Perhaps this is a floating point rep issue, that we are really
rounding 1.7749999999999999999 or something. Sure enough,
repr shows us:

'1.7749999999999999'

So I added a wee bit to 1.775:

1.78

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

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,

No way -- that would be insane.

or perhaps even does the brute force rounding I learned in
FORTRAN back in the 70's: add 0.5 and truncate.

Yes, that's what Python's round() does.

But this would still truncate 1.779999999 to two places, so this
theory fails also.
No:

That is, before adding 0.5, it multiplies by 100.0. The vagaries of
binary fp are such that machine_value_for(1.755) * 100 is exactly
175.5, and adding 0.5 to that gives 178 exactly.

What magic is round() doing, and should this same be done in the
string interp code?

Python implements round() itself. Float string formatting is done by
the platform C sprintf(). If you care about decimal representations
so much that you can't tolerate vagaries due to differences in the
53rd significant bit, use the new decimal module instead.

 

[Peter Hansen]

I'm summing up the bytes in use on a hard disk drive and generating a
report that's emailed based on the percentage of the drive in use. I
know there are other ways to do this, but I like Python and I like to
write my own code. I always find comp.lang.python a very helpful place.

So, from the sounds of it, you really care about this
rounding operation in the displayed values, in which
case the "'%.2f' % value" approach ought to be fine.

-Peter

 

[Christopher A. Craig]

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?

Consulting bltinmodule.c would tell you. round(x,n) in (Python 2.4):

multiplies x by 10**n
adds .5
truncates
divides by 10**n.

Don't confuse this trick with giving us the correct result though,
it's still floating point:
1.78

 

[Donn Cave]

....
I'm summing up the bytes in use on a hard disk drive and generating a
report that's emailed based on the percentage of the drive in use.

Stilling guessing a little about what you're trying to do -
probably implicitly or explicitly invoking the "repr" function
on this values (implicitly for example via repr() or str() on
a sequence of them.) So,

a = [1.775, 1.949]
print a
yields
[1.7749999999999999, 1.9490000000000001]

You will get something more like what you want with
the str() function instead. str(1.775) == '1.775'



from types import FloatType
class ClassicFloat(FloatType):
def __repr__(self):
return self.__str__()

print map(ClassicFloat, [1.775, 1.949])

yields
[1.775, 1.949]


(Seems to me the standard float type behaved like
this in Python 1.5.4, hence "classic".)

Donn Cave, (e-mail address removed)

 

[Dan Bishop]

Hello,

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:

If your only complaint is that it's ugly to display 17 digits, then use
the % operator to display however many digits you want.

print "%.3f" % x # prints 3 digits after the decimal point

If you're referring to internal calculations, then you seem to have a
misunderstanding of the way floating-point math works. Intel hardware
does all arithmetic with 64 significant bits (which get rounded to 53
when stored as "double precision"), and there's no way to tell it
"Don't bother calculating all 64 bits; I only need 11." It would take
extra code to get rid of the extra bits, and why bother slowing down
your program to make the math *less* accurate?

 

[Aahz]

So, from the sounds of it, you really care about this

^don't

rounding operation in the displayed values, in which
case the "'%.2f' % value" approach ought to be fine.

Right?

 

[Peter Hansen]

Right?

I think what I meant to say was "you really care about
this *only* in the displayed values", but with that
"don't" in there it comes out the same in the wash.

-Peter