242

I was just re-reading What’s New In Python 3.0 and it states:

The round() function rounding strategy and return type have changed. Exact halfway cases are now rounded to the nearest even result instead of away from zero. (For example, round(2.5) now returns 2 rather than 3.)

and the documentation for round:

For the built-in types supporting round(), values are rounded to the closest multiple of 10 to the power minus n; if two multiples are equally close, rounding is done toward the even choice

So, under v2.7.3:

In [85]: round(2.5)
Out[85]: 3.0

In [86]: round(3.5)
Out[86]: 4.0

as I'd have expected. However, now under v3.2.3:

In [32]: round(2.5)
Out[32]: 2

In [33]: round(3.5)
Out[33]: 4

This seems counter-intuitive and contrary to what I understand about rounding (and bound to trip up people). English isn't my native language but until I read this I thought I knew what rounding meant :-/ I am sure at the time v3 was introduced there must have been some discussion of this, but I was unable to find a good reason in my search.

  1. Does anyone have insight into why this was changed to this?
  2. Are there any other mainstream programming languages (e.g., C, C++, Java, Perl, ..) that do this sort of (to me inconsistent) rounding?

What am I missing here?

UPDATE: @Li-aungYip's comment re "Banker's rounding" gave me the right search term/keywords to search for and I found this SO question: Why does .NET use banker's rounding as default?, so I will be reading that carefully.

Community
  • 1
  • 1
Levon
  • 138,105
  • 33
  • 200
  • 191
  • Is isn't inconsistent. It says... if it is halfway between, it rounds to the nearest even number. – sberry May 31 '12 at 00:21
  • 33
    I don't have time to look this up, but I believe this is called "Banker's rounding". I believe it's common in the finance industry. – Li-aung Yip May 31 '12 at 00:21
  • 2
    @sberry well, yes, its behavior is consistent with its own description. So if it would say "rounding" is doubling its value and did it, it would also be consistent :) .. but it seems contrary to what rounding commonly *means*. So I'm looking for a better understanding. – Levon May 31 '12 at 00:23
  • I noticed that the decimal module defaults to rounding=ROUND_HALF_EVEN – jgritty May 31 '12 at 00:38
  • 1
    Related: http://stackoverflow.com/questions/10093783/rounding-error-in-python-with-non-odd-number/10093820#10093820 – Sven Marnach May 31 '12 at 08:50
  • 5
    Just a note: Bankers rounding isn't common just in finance. This is how I was taught to round in elementary school already in the 70's :-) – Lennart Regebro Mar 11 '13 at 07:46
  • What a strange behavior, As per the banker's rounding algorithm, round(340.335, 2) should give 340.34 but it is giving 340.33. Any idea folks? Using Python 3.7.4 – Siraj Alam Jan 09 '22 at 21:49
  • 3
    Boy it would be nice if `round()` could just accept a separate argument to change the rounding behavior. – pspahn Mar 30 '22 at 21:55
  • 2
    @SirajAlam, that's because `340.33` does not exist in floating point arithmetic. When you see `340.33` you're actually getting `340.33499999999997953636921010911464691162109375` which of course does round to `340.33` even under bankers rounding. Python puts in extra effort to display `340.33` even though it knows it isn't because it thinks that's what you want to see: https://docs.python.org/3/tutorial/floatingpoint.html To find out what number you really have when you enter a float you can `from decimal import Decimal` and then `Decimal(340.33)`. – NeilG Mar 17 '23 at 00:03
  • This change in performance of `round` isn't mentioned in the [docs](https://docs.python.org/3/library/functions.html#round). Normally the Python version where a change was made is recorded. – NeilG Mar 17 '23 at 00:06

12 Answers12

232

Python 3's way (called "round half to even" or "banker's rounding") is considered the standard rounding method these days, though some language implementations aren't on the bus yet.

The simple "always round 0.5 up" technique results in a slight bias toward the higher number. With large numbers of calculations, this can be significant. The Python 3.0 approach eliminates this issue.

There is more than one method of rounding in common use. IEEE 754, the international standard for floating-point math, defines five different rounding methods (the one used by Python 3.0 is the default). And there are others.

This behavior is not as widely known as it ought to be. AppleScript was, if I remember correctly, an early adopter of this rounding method. The round command in AppleScript offers several options, but round-toward-even is the default as it is in IEEE 754. Apparently the engineer who implemented the round command got so fed up with all the requests to "make it work like I learned in school" that he implemented just that: round 2.5 rounding as taught in school is a valid AppleScript command. :-)

Boris Verkhovskiy
  • 14,854
  • 11
  • 100
  • 103
kindall
  • 178,883
  • 35
  • 278
  • 309
  • 5
    I wasn't aware of this "default standard rounding method pretty much universally these days", would you (or anyone else) know if C/C++/Java/Perl or any other "main-stream" languages implement rounding the same way? – Levon May 31 '12 at 00:26
  • 3
    Ruby does it. Microsoft's .NET languages do it. Java doesn't appear to, though. I can't track it down for every possible language, but I guess it's most common in fairly recently-designed languages. I imagine C and C++ are old enough that they don't. – kindall May 31 '12 at 00:35
  • 7
    ruby returns `3` for `2.5.round` – jfs May 31 '12 at 00:50
  • 1
    Ah, I think the page I found must have been for IronRuby, then, which would inherit the Microsoft CLR rounding behavior. – kindall May 31 '12 at 01:31
  • 1
    round() function from Math::Round in Perl also produces `3`, though `printf "%.f", 2.5` produces expected `2`. – jfs May 31 '12 at 01:36
  • 19
    I added a bit about AppleScript's handling of this because I love the sarcastic way the "old" behavior is implemented. – kindall May 31 '12 at 01:37
  • 3
    @kindall This method has been the IEEE default rounding mode since 1985 (when IEEE 754-1985 was published). It has also been the default rounding mode in C since at least C89 (and thus also in C++), *however*, since C99 (and C++11 with sporadic support before that) a "round()" function has been available that uses ties round away from zero instead. Internal floating point rounding and the rint() family of functions still obey the rounding mode setting, which defaults to round ties to even. – Wlerin Nov 22 '15 at 21:41
  • As I learned, " in Python 3, decimals are rounded to the nearest even number." I am using Python 3.6.6. When I enter round(17.2), I expected to see 18 but I saw 17. For Python 3.6.6 is there another rule? – limonik Feb 04 '19 at 15:17
  • 1
    The rule applies only to fractional parts of 0.5, sorry if that wasn't clear. 17.2 is going to round to 17.0. – kindall Feb 04 '19 at 16:18
  • 1
    The scariest about this behavior is that there are now cases where `round(x + 1) - round(x)` might be 0 or 2. – Ivaylo Strandjev Apr 09 '19 at 13:10
  • "_I_ learned in school" (not a US school) that 0.50 rounds to 0, which is a classical mathematical way... There should not be any debate about THAT, at least (https://www.mathsisfun.com/numbers/rounding-methods.html)... Rounding 0.50 down is an engineering/banking convention... In Python 3.x wherever it's important I add a tiny fraction (e.g. 1e-9) before rounding. – Gene M May 21 '20 at 18:22
  • 1
    It appears this applies only to the first digit: I tested in 3.8.5: list(map(lambda n: round(n,1), [0.05,0.15,0.25,0.35,0.45,0.55,0.65,0.75,0.85 ,0.95])) and it returns [0.1, 0.1, 0.2, 0.3, 0.5, 0.6, 0.7, 0.8, 0.8, 0.9] – user1708042 Dec 08 '20 at 17:17
  • "banker's rounding" is not standard rounding in any field I have worked or schools I have attended. And it appears inconsistent within python as @user1708042 points out. The most common method considers an exact half to round up to a whole. I can see why bankers' rounding is used with high volume calculations, but it is not expected behavior nor does it seem consistent within python3 [v3.9.2]; round(2.35, 1) ...2.45, 2.55, 2.65, 2.75 results in 2.4, 2.5, 2.5, 2.6, 2.8. Though some of this inconsistency may be artifact of binary representation. So if very critical define your own round(). – Max Power Oct 20 '21 at 19:15
  • 2
    I think it's pretty obvious it's such a culturally diverse topic, that no language should even implement a "default" round(), unless they clearly use flags or multiple versions of it to change its behavior to whatever each school of thought does (e.g. for me it's unheard of in academic and scientific fields for 2.5 to not become 3). – j riv Apr 10 '22 at 05:32
  • @MaxPower this has been the standard default rounding method since anyone bothered to set a standard for floating point operations in 1985, which has been ever since **the** standard. Your claim probably only tells more about you than about anything else! – Mariano Suárez-Álvarez May 04 '22 at 01:41
52

You can control the rounding you get in Py3000 using the Decimal module:

>>> decimal.Decimal('3.5').quantize(decimal.Decimal('1'), 
    rounding=decimal.ROUND_HALF_UP)
>>> Decimal('4')

>>> decimal.Decimal('2.5').quantize(decimal.Decimal('1'),    
    rounding=decimal.ROUND_HALF_EVEN)
>>> Decimal('2')

>>> decimal.Decimal('3.5').quantize(decimal.Decimal('1'), 
    rounding=decimal.ROUND_HALF_DOWN)
>>> Decimal('3')
Barthelemy
  • 8,277
  • 6
  • 33
  • 36
dawg
  • 98,345
  • 23
  • 131
  • 206
  • Thanks .. I was not familiar with this module. Any idea how I would get the behavior of Python v 2.x? The examples you show don't seem to do that. Just curious if that would be possible. – Levon May 31 '12 at 02:05
  • 1
    @Levon: The constant `ROUND_HALF_UP` is the same as Python 2.X's old behavior. – dawg May 31 '12 at 02:10
  • 3
    You can also set a context for the Decimal module that does this for you implicitly. See the `setcontext()` function. – kindall May 31 '12 at 21:04
  • 2
    This is exactly what I was looking for today. Working as expected in Python 3.4.3. Also worth noting, you can control how much it rounds by changing `quantize(decimal.Decimal('1')` to `quantize(decimal.Decimal('0.00')` if you want to round to nearest 100s such as for money. – Igor Feb 01 '17 at 18:14
  • 2
    This solution works as a replacement for `round(number, ndigits)` as long as `ndigits` is positive, but annoyingly you cannot use it to replace something like `round(5, -1)`. – Pekka Klärck Jun 15 '18 at 11:39
21

Just to add here an important note from documentation:

https://docs.python.org/dev/library/functions.html#round

Note

The behavior of round() for floats can be surprising: for example, round(2.675, 2) gives 2.67 instead of the expected 2.68. This is not a bug: it’s a result of the fact that most decimal fractions can’t be represented exactly as a float. See Floating Point Arithmetic: Issues and Limitations for more information.

So don't be surprised to get following results in Python 3.2:

>>> round(0.25,1), round(0.35,1), round(0.45,1), round(0.55,1)
(0.2, 0.3, 0.5, 0.6)

>>> round(0.025,2), round(0.035,2), round(0.045,2), round(0.055,2)
(0.03, 0.04, 0.04, 0.06)
skif1979
  • 319
  • 2
  • 3
  • I saw that. And my first reaction: Who is using a 16-bit CPU that is incapable of representing all permutations of "2.67x" ? Saying that fractions can't be expressed in float seems like a scapegoat here: no modern CPU is that inaccurate, in ANY langauge (except Python?) – Adam Nov 30 '15 at 17:24
  • 20
    @Adam: I think you're misunderstanding. The binary format (IEEE 754 binary64) used to store floats can't represent `2.675` exactly: the closest the computer can get is `2.67499999999999982236431605997495353221893310546875`. That's pretty close, but it's not *exactly* equal to `2.675`: it's *very slightly* closer to `2.67` than to `2.68`. So the `round` function does the right thing, and rounds it to the closer 2-digit-after-the-point value, namely `2.67`. This has nothing to do with Python, and everything to do with binary floating-point. – Mark Dickinson Aug 05 '16 at 13:46
  • 3
    It's not "the right thing" because it was given a source-code constant :), but I see your point. – Adam Aug 07 '16 at 19:52
  • @Adam: I ran into this same quirkiness in JS before so it is not language specific. – Igor Feb 23 '17 at 23:38
13

Python 3.x rounds .5 values to a neighbour which is even

assert round(0.5) == 0
assert round(1.5) == 2
assert round(2.5) == 2

import decimal

assert decimal.Decimal('0.5').to_integral_value() == 0
assert decimal.Decimal('1.5').to_integral_value() == 2
assert decimal.Decimal('2.5').to_integral_value() == 2

however, one can change decimal rounding "back" to always round .5 up, if needed :

decimal.getcontext().rounding = decimal.ROUND_HALF_UP

assert decimal.Decimal('0.5').to_integral_value() == 1
assert decimal.Decimal('1.5').to_integral_value() == 2
assert decimal.Decimal('2.5').to_integral_value() == 3

i = int(decimal.Decimal('2.5').to_integral_value()) # to get an int
assert i == 3
assert type(i) is int
kares
  • 7,076
  • 1
  • 28
  • 38
8

I recently had problems with this, too. Hence, I have developed a python 3 module that has 2 functions trueround() and trueround_precision() that address this and give the same rounding behaviour were are used to from primary school (not banker's rounding). Here is the module. Just save the code and copy it in or import it. Note: the trueround_precision module can change the rounding behaviour depending on needs according to the ROUND_CEILING, ROUND_DOWN, ROUND_FLOOR, ROUND_HALF_DOWN, ROUND_HALF_EVEN, ROUND_HALF_UP, ROUND_UP, and ROUND_05UP flags in the decimal module (see that modules documentation for more info). For the functions below, see the docstrings or use help(trueround) and help(trueround_precision) if copied into an interpreter for further documentation.

#! /usr/bin/env python3
# -*- coding: utf-8 -*-

def trueround(number, places=0):
    '''
    trueround(number, places)
    
    example:
        
        >>> trueround(2.55, 1) == 2.6
        True

    uses standard functions with no import to give "normal" behavior to 
    rounding so that trueround(2.5) == 3, trueround(3.5) == 4, 
    trueround(4.5) == 5, etc. Use with caution, however. This still has 
    the same problem with floating point math. The return object will 
    be type int if places=0 or a float if places=>1.
    
    number is the floating point number needed rounding
    
    places is the number of decimal places to round to with '0' as the
        default which will actually return our interger. Otherwise, a
        floating point will be returned to the given decimal place.
    
    Note:   Use trueround_precision() if true precision with
            floats is needed

    GPL 2.0
    copywrite by Narnie Harshoe <signupnarnie@gmail.com>
    '''
    place = 10**(places)
    rounded = (int(number*place + 0.5if number>=0 else -0.5))/place
    if rounded == int(rounded):
        rounded = int(rounded)
    return rounded

def trueround_precision(number, places=0, rounding=None):
    '''
    trueround_precision(number, places, rounding=ROUND_HALF_UP)
    
    Uses true precision for floating numbers using the 'decimal' module in
    python and assumes the module has already been imported before calling
    this function. The return object is of type Decimal.

    All rounding options are available from the decimal module including 
    ROUND_CEILING, ROUND_DOWN, ROUND_FLOOR, ROUND_HALF_DOWN, ROUND_HALF_EVEN, 
    ROUND_HALF_UP, ROUND_UP, and ROUND_05UP.

    examples:
        
        >>> trueround(2.5, 0) == Decimal('3')
        True
        >>> trueround(2.5, 0, ROUND_DOWN) == Decimal('2')
        True

    number is a floating point number or a string type containing a number on 
        on which to be acted.

    places is the number of decimal places to round to with '0' as the default.

    Note:   if type float is passed as the first argument to the function, it
            will first be converted to a str type for correct rounding.

    GPL 2.0
    copywrite by Narnie Harshoe <signupnarnie@gmail.com>
    '''
    from decimal import Decimal as dec
    from decimal import ROUND_HALF_UP
    from decimal import ROUND_CEILING
    from decimal import ROUND_DOWN
    from decimal import ROUND_FLOOR
    from decimal import ROUND_HALF_DOWN
    from decimal import ROUND_HALF_EVEN
    from decimal import ROUND_UP
    from decimal import ROUND_05UP

    if type(number) == type(float()):
        number = str(number)
    if rounding == None:
        rounding = ROUND_HALF_UP
    place = '1.'
    for i in range(places):
        place = ''.join([place, '0'])
    return dec(number).quantize(dec(place), rounding=rounding)
Mehdi Charife
  • 722
  • 1
  • 7
  • 22
narnie
  • 1,742
  • 1
  • 18
  • 34
4

Python 2 rounding behaviour in python 3.

Adding 1 at the 15th decimal places. Accuracy upto 15 digits.

round2=lambda x,y=None: round(x+1e-15,y)

Not right for 175.57. For that it should be added in the 13th decimal place as the number is grown. Switching to Decimal is better than reinventing the same wheel.

from decimal import Decimal, ROUND_HALF_UP
def round2(x, y=2):
    prec = Decimal(10) ** -y
    return float(Decimal(str(round(x,3))).quantize(prec, rounding=ROUND_HALF_UP))

Not used y

Smart Manoj
  • 5,230
  • 4
  • 34
  • 59
  • 4
    Could you explain the intuition behind this formula? – Hadi Aug 18 '17 at 14:32
  • 2
    From what I understand, fractions that can't be accurately represented will have up to 15 9's, then the imprecision. For example, `2.675` is `2.67499999999999982236431605997495353221893310546875`. Adding 1e-15 will tip it over 2.675 and get it rounded correctly. if the fraction is already over the code constant, adding 1e-15 will change nothing to the rounding. – Benoit Dufresne Aug 08 '18 at 17:17
  • nice trick also works for `3.46//0.01==345` but `(3.46+1E-15)//0.01==346` as wanted – Felix Liu May 15 '21 at 14:37
  • Are there cases where this would prevent correct rounding down? I mean other than the occasion where the true number is exactly x.xxx9999999999999, in which case you couldn't know for sure if the 9s stop or continue because this is max precision for a common float64, actually slightly beyond float64 depending on which direction you are converting bi-dec-bi or dec-bi-dec and in which numeral system you need to retain the accuracy. (All assuming no outside confirmation calulations with true fractions or arbitrary precision.) – Max Power Oct 20 '21 at 19:36
2

Some cases:

in: Decimal(75.29 / 2).quantize(Decimal('0.01'), rounding=ROUND_HALF_UP)
in: round(75.29 / 2, 2)
out: 37.65 GOOD

in: Decimal(85.55 / 2).quantize(Decimal('0.01'), rounding=ROUND_HALF_UP)
in: round(85.55 / 2, 2)
out: 42.77 BAD

For fix:

in: round(75.29 / 2 + 0.00001, 2)
out: 37.65 GOOD
in: round(85.55 / 2 + 0.00001, 2)
out: 42.78 GOOD

If you want more decimals, for example 4, you should add (+ 0.0000001).

Work for me.

Virako
  • 650
  • 10
  • 18
  • This was the only solution that worked for me, thanks for posting. Everyone seems to be intent on 0.5 rounding up/down, so I couldn't manage multi decimal rounding issues. – Gayathri Aug 05 '19 at 21:36
0

Sample Reproduction:

['{} => {}'.format(x+0.5, round(x+0.5)) for x in range(10)]

['0.5 => 0', '1.5 => 2', '2.5 => 2', '3.5 => 4', '4.5 => 4', '5.5 => 6', '6.5 => 6', '7.5 => 8', '8.5 => 8', '9.5 => 10']

API: https://docs.python.org/3/library/functions.html#round

States:

Return number rounded to ndigits precision after the decimal point. If ndigits is omitted or is None, it returns the nearest integer to its input.

For the built-in types supporting round(), values are rounded to the closest multiple of 10 to the power minus ndigits; if two multiples are equally close, rounding is done toward the even choice (so, for example, both round(0.5) and round(-0.5) are 0, and round(1.5) is 2). Any integer value is valid for ndigits (positive, zero, or negative). The return value is an integer if ndigits is omitted or None. Otherwise the return value has the same type as number.

For a general Python object number, round delegates to number.round.

Note The behavior of round() for floats can be surprising: for example, round(2.675, 2) gives 2.67 instead of the expected 2.68. This is not a bug: it’s a result of the fact that most decimal fractions can’t be represented exactly as a float. See Floating Point Arithmetic: Issues and Limitations for more information.

Given this insight you can use some math to resolve it

import math
def my_round(i):
  f = math.floor(i)
  return f if i - f < 0.5 else f+1

now you can run the same test with my_round instead of round.

['{} => {}'.format(x + 0.5, my_round(x+0.5)) for x in range(10)]
['0.5 => 1', '1.5 => 2', '2.5 => 3', '3.5 => 4', '4.5 => 5', '5.5 => 6', '6.5 => 7', '7.5 => 8', '8.5 => 9', '9.5 => 10']
Fallenreaper
  • 10,222
  • 12
  • 66
  • 129
0

I propose custom function which would work for a DataFrame:

def dfCustomRound(df, dec):
    d = 1 / 10 ** dec
    df = round(df, dec + 2)
    return (((df % (1 * d)) == 0.5 * d).astype(int) * 0.1 * d * np.sign(df) + df).round(dec)
-2
# round module within numpy when decimal is X.5 will give desired (X+1)

import numpy as np
example_of_some_variable = 3.5
rounded_result_of_variable = np.round(example_of_some_variable,0)
print (rounded_result_of_variable)
Eric Aya
  • 69,473
  • 35
  • 181
  • 253
  • 2
    No, it doesn't! – Yahya Jan 12 '23 at 00:17
  • `print(np.round(2.5,0))` prints `2.0`, as expected for the IEEE-754 default FP rounding mode, which is nearest with even as a tie-break, not away-from-zero or the towards +Inf you'r claiming. – Peter Cordes Aug 30 '23 at 00:11
-3

Try this code:

def roundup(input):   
   demo = input  if str(input)[-1] != "5" else str(input).replace("5","6")
   place = len(demo.split(".")[1])-1
   return(round(float(demo),place))

The result will be:

>>> x = roundup(2.5)
>>> x
3.0  
>>> x = roundup(2.05)
>>> x
2.1 
>>> x = roundup(2.005)
>>> x
2.01 

Ooutput you can check here: https://i.stack.imgur.com/QQUkS.png

-7

You can control the rounding you using the math.ceil module:

import math
print(math.ceil(2.5))
> 3
Eds_k
  • 944
  • 10
  • 12
  • That will always return the number without its decimal part, this is not rounding. ceil(2.5) = 2, ceil(2.99) = 2 – krafter Feb 17 '20 at 04:43
  • 1
    in python3+, If the number argument is a positive or negative number, the ceil function returns the ceiling value. – Eds_k Feb 17 '20 at 14:46
  • In [14]: math.ceil(2.99) Out[14]: 3 – Eds_k Feb 17 '20 at 14:46
  • 1
    Yes, I'm sorry I was wrong. Ceil() returns the ceiling value whereas floor() returns the one I was talking, about. But still, in my opinion this is not quite the rounding behaviour (both these functions) – krafter Feb 19 '20 at 03:41
  • @krafter: Just for the record, stripping away the fractional part is called "truncation", rounding towards 0.0. e.g. `math.trunc(3.9)` is `3`, `math.trunc(-3.9)` is `-3`. `floor` rounds towards -Inf, `ceil` rounds towards +Infinity. – Peter Cordes Aug 30 '23 at 00:13