round function error???

M

Mark Dickinson

Isn't this a mistake???

Which 'this'? That is, what were you expecting?

If you're objecting to the fact that the second result
produces 3499.3499999999999 instead of 3499.35, then
no, that's not a mistake; see

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

for more information. But I'm guessing that you're
questioning the fact that a value that's apparently
*less* than 3499.35 is rounded up to 3499.4, rather
than down to 3499.3. ?

Then yes, I'd agree that's less than ideal, though I
don't consider it a particularly serious bug.
It's been on my list of things to fix for a while.
(See http://bugs.python.org/issue1869 ).
Contributions welcome!

Mark
 
T

Terry Reedy

Anthony said:
Isn't this a mistake???

3499.4000000000001

My Python 2.5.1 spat that out..

No, round() return binary floats that, in general, cannot represent
decimal floats exactly. Formatted printing gives what you expect.' 3499.35'
 
M

Mark Dickinson

No, round() return binary floats that, in general, cannot represent
decimal floats exactly.  Formatted printing gives what you expect.
 >>> '%8.2f' % x
' 3499.35'

Sure. But it's still true that the second printed value
(printed as 3499.3499999999999) is strictly less than 3499.35,
so when rounding to 1 decimal place an ideal rounding routine
would round it *down* to 3499.3 instead of up to 3499.4. This
is what '%.1f' does, for example, on a platform where printf
does correct rounding:

Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17)
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.3499.4

Mark
 
J

John Machin

Which 'this'? That is, what were you expecting?

If you're objecting to the fact that the second result
produces 3499.3499999999999 instead of 3499.35, then
no, that's not a mistake; see

http://www.python.org/doc/faq/general/#why-are-floating-point-calcula...

for more information. But I'm guessing that you're
questioning the fact that a value that's apparently
*less* than 3499.35 is rounded up to 3499.4, rather
than down to 3499.3. ?

"apparently" being the operative word.
False


Then yes, I'd agree that's less than ideal, though I
don't consider it a particularly serious bug.
It's been on my list of things to fix for a while.

I'd suggest adding this to the list of floating point strangenesses in
the FAQ and/or the appendix to the tutorial, rather than "fixing" it.

The example you give there seems to be somewhat more deserving of a
fix.

Cheers,
John
 
M

Mark Dickinson

"apparently" being the operative word.

Well, it's not just an apparent problem: the closest
floating-point number to 3499.35 really *is* less than
3499.35. A nice way to check this is using the new
fractions module in 2.6, which allows exact conversions
of floats and Decimals into rational numbers:

Python 2.6b2+ (trunk:65155, Jul 20 2008, 15:39:46)
[GCC 4.0.1 (Apple Inc. build 5484)] on darwin
Type "help", "copyright", "credits" or "license" for more information.Fraction(69987, 20)
[54933 refs]True

Mark
 
J

John Machin

Well, it's not just an apparent problem: the closest
floating-point number to 3499.35 really *is* less than
3499.35.

I'm well aware of that. My point is that I hope that you weren't
planning on changing that behaviour in an unannounced unstaged
manner.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top