'%.2f' % 2.545 doesn't round correctly

[Ultrasick]

BPO	5118
Nosy	@mdickinson

^{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 = 'https://github.com/mdickinson'
closed_at = <Date 2009-01-31.14:13:07.818>
created_at = <Date 2009-01-31.12:57:50.378>
labels = ['type-bug', 'invalid']
title = "'%.2f' % 2.545 doesn't round correctly"
updated_at = <Date 2012-05-03.17:34:18.543>
user = 'https://bugs.python.org/Ultrasick'

bugs.python.org fields:

activity = <Date 2012-05-03.17:34:18.543>
actor = 'mark.dickinson'
assignee = 'mark.dickinson'
closed = True
closed_date = <Date 2009-01-31.14:13:07.818>
closer = 'mark.dickinson'
components = []
creation = <Date 2009-01-31.12:57:50.378>
creator = 'Ultrasick'
dependencies = []
files = []
hgrepos = []
issue_num = 5118
keywords = []
message_count = 12.0
messages = ['80868', '80869', '80870', '80871', '80873', '80874', '80875', '80876', '158716', '158717', '159853', '159868']
nosy_count = 3.0
nosy_names = ['mark.dickinson', 'Ultrasick', 'Zeev.Rotshtein']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = None
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue5118'
versions = ['Python 2.7']

[Ultrasick]

print '%.2f' % 2.544 // returns 2.54
print '%.2f' % 2.545 // returns 2.54 but should return 2.55
print '%.2f' % 2.546 // returns 2.55

[mdickinson]

This is not a bug; it's a consequence of the finite accuracy of floating-
point arithmetic. If you look at the actual value that's stored for
'2.545', you'll see that it's actually slightly less than 2.545, so
rounding it down is the correct thing to do.

>>> 2.545
2.5449999999999999

[Ultrasick]

print round(2.545, 2) // returns 2.55

[mdickinson]

print round(2.545, 2) // returns 2.55

Aha! Yes, that one *is* a bug (see issue bpo-1869), though it's not one that
I regard as terribly serious, and not one that can be easily solved in all
cases.

Here's why I don't see it as particularly serious: you're rounding a value
that's just on the boundary: 2.545+tiny_error should round up, while
2.545-tiny_error should round down. But tiny (or not-so-tiny) errors are
an almost unavoidable part of working with binary floating-point
arithmetic. Additionally, whether the binary approximation stored for
2.545 is less than or greater than the true value depends on many things
(format of a C double, system C library function used for string-to-double
conversion, etc.), so in a sense either 2.55 *or* 2.54 can be defended as
a valid result, and a good numeric programmer won't write code that
depends on getting one or the other.

Having said that, if you're interested in providing a patch for issue
bpo-1869 I'd certainly take a look.

If you care about *exact* representations of numbers with a finite number
of places after the decimal point, you may be interested in Python's
'decimal' module.

[Ultrasick]

I am sorry but I am not a C programmer. I cannot provide any patches.

As far as I understood this issue and issue bpo-1869 have a common problem
but this issue wouldn't be solved if issue bpo-1869 is solved. "print
'%.2f' % 2.545" doesn't seam to use the built in round() function.
Otherwise the result would be 2.55 already as the result of round(2.545,
2) is.

So you might want to reopen the bug. But either way I don't consider
this bug as really serious either.

[mdickinson]

So you might want to reopen the bug. But either way I don't consider
this bug as really serious either.

I don't understand. As far as I can see '%.2f' % 2.545 is returning
the correct result: there is no bug here, so no need to reopen. '%.2f'
should *not* return 2.55; it should return 2.54, which is exactly what it
does. round(2.545, 2) should also return 2.54, but returns 2.55 instead;
bpo-1869 is already open for this.

You're correct that the float formatting doesn't use round: it does
whatever the platform C library's sprintf does.

[Ultrasick]

Well that's not what I have learned how rounding works. I think that's
the more common way:

0.4 -> 0
0.5 -> 1
0.6 -> 1

I hope you don't try to spread the misbehavoir of pythons way of rounding

print '%.2f' % 2.545 // returns 2.54

to the built in round() function. So that round() would also return 2.54.

The result of rounding 2.545 is 2.55 no matter how python temporarly
stores "2.545" and independent of how python does the rounding. The
result is 2.55 and not 2.54. If python doesn't deliver "2.55" as the
result of it's rounding algorithm then it's doing it wrong. And if
python does stuff wrong then it has a bug.

in my opinion

[mdickinson]

result is 2.55 and not 2.54. If python doesn't deliver "2.55" as the
result of it's rounding algorithm then it's doing it wrong. And if

Sorry, but that's just not true. I suggest that you (a) read the
section on floating-point[1] in the Python tutorial, and/or (b) ask
about this on comp.lang.python if you feel inclined---there are plenty
of people there who would be glad to explain what's going on here.

[1] http://docs.python.org/tutorial/floatingpoint.html

[ZeevRotshtein]

Well this IS a bug. There is a certain globally accepted manner in which rounding work and python does something else.

P.S.: A bug is when something doesn't do what it's supposed to do the way it's supposed to do it. This definition does not depend on "internal representation" or any such things.

[mdickinson]

Well this IS a bug.

I assume that you're referring to behaviour like this:

Python 2.7.2 (default, Jan 13 2012, 17:11:09) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> x = 2.545
>>> round(x, 2)
2.54

To explain again, what happens here is:

(1) After the assignment 'x = 2.545', what's stored for x is not the precise decimal value 2.545, but a binary approximation to it. That binary approximation just happens to be very slightly less than 2.545.

(2) Now when rounding, the usual rules are applies (values less than half get rounded down), to give 2.54.

Which part(s) of the above do you think should be changed? Should the 'round' function incorrectly round some numbers up even though they fall below the halfway case?

[Ultrasick]

Ok, let's sum that up:

There is a rounding problem. That's because Python uses floating point registers of the x86-CPU-architecture to store point values. This method is inaccurate and causes such problems. So Python inherits this bug from this value storing method.

Even thou the origin of this bug is in the method which is beeing used, Python has inherited this bug and can't round correctly.

If we would say that Python does not support point values but only floating point values of the x86-CPU-architecture (so not even floating point values in general) then we could admit that round(2.545, 2) has a bug because it "incorrectly" shows 2.55 as the result. But that wouldn't help us any further.

One possible solution would be to use a different method to store point values. For exaple 2 integers could be used to store a point value lossless. The one integer stores whatever is left of the point and the other integer stores whatever is right of the point. Meaning:

25.0:
-> integer #1: 0,000,000,025
-> integer #2: 0,000,000,000

25.99997:
-> integer #1: 0,000,000,025
-> integer #2: 0,999,970,000

25.00001
-> integer #1: 0,000,000,025
-> integer #2: 0,000,010,000

As you can see, this method is lossless. As long as you don't try to store more than 32 significant bits in a register which is 32 bits in size. To be more accurate: you can't even use all 32 bits because the most significant digit can only be between 0 and 4 (4,294,967,295 barrier).

Using this value storing method would mean quite some efforts for the developers. But then Python would be able to round correctly. So that's why I call it a "possible solution".

I am not the one who is going to make the decision, whether a different value-storing-method is going to be implemented, indepentend how this value storing method may look like. But I am one of thouse who suffered from the method which is currently implemented.

@mark: And I am also one of thouse who lost a lot of interrest in helping out in the futher development of Python. It was because your haughtiness. You tried to show how perfect Python is and that there would be no bugs. But your last comment was a little more productive. Even thou you still haven't showed much interest in finding a solution to the problem.

@Zeev: I already gave up. But you had more endurance. Thanks :-)

Gary