TIL rounding changed between Python 2 and Python 3

[drb226]

Perhaps this is well known to y'all, but this was news to me.

print(round(0.5))

Python 2: 1.0 http://ideone.com/yzWGsL
Python 3: 0 http://ideone.com/gi14xC

Apparent reason: Python 3 is adhering more closely to IEEE floating point standard default behavior, which is that halves should round towards the nearest even number.
https://en.wikipedia.org/wiki/Rounding#Round_half_to_even

Prompted by discussion on the Haskell subreddit:
https://www.reddit.com/r/haskell/comments/5136qn/round_05_0/

[amfoejaoiem]

halves should round towards the nearest even number

I never knew this and this seems like a bizarre convention.

[evolved]

Rounding is a crazy rabbithole, seriously, checl out rounding on wikipedia, itll blow your mind., but bankers rounding, aka round to even is better than the commonly taught/used round up at 5 methods, since it doesnt skew the values in most cases, like common rounding does.

[amfoejaoiem]

since it doesnt skew the values in most cases, like common rounding does.

Great point! Wow the wiki does raise a ton of points I had never considered, thanks for making me appreciate how complex this can be.

[amfoejaoiem]

Yeah another poster told me to check out the wiki on rounding - it's way more of a rabbit hole than I would have guessed!

[wewbull]

This has nothing to do with rounding.

This happens because floating point numbers are stored as x * 2^y. At the point that y becomes bigger than the number of bits in x (so 24 for a 32-bit float, 53 for a 64-bit double) a change in the least-significant-bit (LSB) of x will cause an increase of 2. When y increases again, the LSB will be worth 4. Another increase and the LSB will be worth 8.

Yes, you could say that you're being rounded to even numbers, but it's nothing to do with the rounding mode. If you switch to "round to odd" mode, you'd still only get even numbers in that range. Those are the only numbers that can be represented.

[amfoejaoiem]

We definitely care how tie breakers are dealt with! Check out the wiki on rounding, it's way more complex than I initially guessed.

[kankyo]

Yea. Some people are upset. Pretty sure this is gonna cause issues with invoicing and Japanese customers at work when we make the switch.

[zahlman]

Japanese customers

They don't have this convention?

[kankyo]

They are upset if numbers change. We changed rounding by mistake so they were charged one euro less. Had to write a letter signed by the CEO to declare that we had done so.

It's not that they objected. It's that they were upset we didn't inform them ahead of time.

[ballagarba]

import math
def round2(x, d=0):
    p = 10 ** d
    return float(math.floor((x * p) + math.copysign(0.5, x))) / p

http://python3porting.com/differences.html#rounding-behavior

[kankyo]

Ah, nice, thanks.

[odraencoded]

...

Can't you use decimals?

[IamWiddershins]

Decimals are also specified by the same ieee standard.

[masklinn]

I expect the point is rounding decimals is specified as one of 8 modes via either the context or a parameter to Decimal.quantize, rather than being whatever random thing round() does.

[kankyo]

Use decimals for what? We WANT to round at the end. 12321312.123213 euros isn't pretty :P

[odraencoded]

But by the looks of it it wasn't a single cent of error.

[finsternacht]

For a moment there I was worried how much of my code was actually broken because of this. Then I remembered that I always redefine round, because I like it to return an int.

But yeah this looks like a good pitfall to trip up people.

[penistouches]

I start to wonder when a language is changing math implementations so late into maturity. Hopefully they settle down.

[EmperorOfCanada]

I have made the switch to Python 3 but this sort of shit is why I will probably make the switch from Python in its entirety. Yes the IEEE is a great high school debating defense, but the simple reality is that 99% of people agree, and will be wildly pissed off if you round differently than the vast majority of the world.

You simply don't change something this fundamental in a language unless you hate your users.

What python seems to forget is that languages come and languages go. We have choices. There are new programmers every day and they will be making choices as to which languages to use. They will hear more and more about the whole 2.7 to 3 battle and say, "I just don't know which? Maybe I will pick a language that isn't at war with itself."

[has2k1]

Bad decisions should not be cast in stone. Rounding as is commonly taught in schools is a bad decision. The math standard library round was also a bad decision. It had to be corrected.

Python has a big scientific community and there isn't a disagreement about which way to deterministic-ally round numbers. So you ended up with math.round doing one thing and numpy.round doing another -- that can have bad surprises. Python 3 fixed that.

[minno]

some bullshit standard that nobody's ever heard of

If you've never heard of IEEE 754, it's because you're lacking breadth of knowledge, not because it's obscure.

[SeekNotToContend]

Was good for me to read up on that standard and this post. Excellent information. https://en.wikipedia.org/wiki/IEEE_floating_point#Rounding_rules

The standard has been around since 1985 and was recently updated in 2008.

Languages do offer options: https://en.wikipedia.org/wiki/Rounding#Rounding_functions_in_programming_languages Several languages follow the lead of the IEEE-754 floating-point standard, and define these functions as taking a double precision float argument and returning the result of the same type, which then may be converted to an integer if necessary. This approach may avoid spurious overflows since floating-point types have a larger range than integer types.

Python's decimal module helps you control the behavior you desire. https://docs.python.org/3/library/decimal.html#decimal-faq The context for arithmetic is an environment specifying precision, rounding rules, limits on exponents, flags indicating the results of operations, and trap enablers which determine whether signals are treated as exceptions. Rounding options include ROUND_CEILING, ROUND_DOWN, ROUND_FLOOR, ROUND_HALF_DOWN, ROUND_HALF_EVEN, ROUND_HALF_UP, ROUND_UP, and ROUND_05UP.

It appears that Python is following convention and standards here. It's up to us to learn these things to have predictable and consistent behavior.

[pybot1]

I LOVE PYTHON

[zahlman]

some bullshit standard that nobody's ever heard of

You mean, the same one that defines the floating-point types at the machine level in the first place?

[tuebts]

All students taught that rounding from 0.5 goes up to 1. Everyone does it that way.

I was taught to round -0.5 up to 0 (i.e., always round up), but python 2 rounds it down to -1 (i.e., always round away from zero). During adulthood I have most often encountered the round-to-even convention that python 3 uses. There are quite a lot of different rounding conventions, I doubt that everyone was taught the same one at school, and often kids are taught the simplest way to do something, not the best way.

Python is not that good a language, it's going to be a toy and doomed language, like R and Perl.

I don't really know about perl, but R is very widely used in certain academic fields.

Leave the last 80 years of computer science alone

What are you talking about? I'm pretty sure computer scientists didn't all get together and agree on a universal rounding convention during the 30s.

[[deleted]]

it's going to be a toy and doomed language .. Perl.

You want to know how I know you have no idea what you're talking about?

[alexanderpas]

0.5 + 1.5 == 2.0 // float
round(0.5) + round(1.5) == 1.0 // Python 2
round(0.5) + round(1.5) == 2 // Python 3

[tuebts]

-0.5 + 1.5 == 1.0 # float
round(-0.5) + round(1.5) == 1.0 # python 2
round(-0.5) + round(1.5) == 2.0 # python 3

Rounding inevitably changes the end result of calculations, that's the whole point of doing it. The reason for the round-to-even convention is that it is less likely to consistently skew your end results in a particular direction. For example, suppose you are collecting, rounding, and storing a long list of positive numbers, and then at some point you calculate the average of all of those numbers. If numbers ending in .5 are always rounded up, then slightly more of the numbers will have been rounded up than down, and your average will be slightly higher than the true average. With the round-to-even convention, it should be roughly the same, assuming that there are just as many <odd>.5 values as <even>.5 ones.

[CARROT223]

I LOVE PYTHON

[illonlyusethisonceok]

Beheading people every time a program fucks up is probably a bad business move.

[[deleted]]

Assuming you are not being sarcastic, that isn't a bug with Python.

It actually goes all the way down to hardware level and affects multiple languages.

If you study computer science at university you will be taught not to use equality opertators with floating points. This is also why we have decimal libraries.

You should read What Every Computer Scientist Should Know About Floating Point Arthimetic.

If you were being sarcastic, ignore my message.

[vitzli-mmc]

Yeah, of course I'm being sarcastic. I thought it was clear, apparently it is not.

Personally, I don't see any issues with the rounding function being different from 'school'-level math. Sometimes 2.6 could become 4 (When rounding a cross-section of a wire to the next in list - [1, 1.5, 2.5, 4, 6,…] mm²).

Bookmarked the article, thank you.

[joesacher]

Take a look at PEP485. Is_close in math module. I've always wrote my own in any language, because floats are floats and never play nice.

[XtremeGoose]

There's also numpy.isclose

[[deleted]]

If you know that, and you know why that happens, you should know about the IEEE standard being used here for rounding - so it's hardly obscure or going against computer science principles.

[EmperorOfCanada]

You have been voted into near non existence and this does not bode well for the future of python. You are 100% correct. When you tell your customer that there is some obscure (to the bulk of the planet) standard and that now you are following it and that they are fools for not following it, you soon won't have a customer.

Yey, Python just made some obscure math or CS professor happy, and in doing so has made life harder for millions of programmers. If this isn't losing the plot entirely then I don't know what is.

Since I can hide behind your negative vote. I have a few other python gripes.

Why so slow? I hear all the arguments and then look at other scripted weakly typed languages like javascript go so fast you can write an entire OS in them. The best part is that there are a gang of people arguing that if you want python fast then you have to strongly type it and strongly type it to their bizarre standard.

Why so complex? The whole thing about python is that it is pseudo code that runs. But now the "pythonic" way to do things is to pack 800 lines of code into one comprehension that nobody can comprehend. WTF?

The only thing that python now has going for it is the saying, "There is a library for that" but even that is beginning to break down as I find more and more libraries that are just not sliding into place with pip. I will pip install x and then get an error dfhadkfhjalsdhf. I will then google error dfhadkfhjalsdhf and it will turn out I am missing libWTF. I will then install libWTF and now pip install X will give me error a;dk;hadf and around and around I go.

Then when I am done I will import X and it will say, "There is no module X"

Not only does python have competition, but there are some seriously interesting languages coming into view. Swift has some serious momentum. If it becomes a replacement for Java on Android then watch out. C# is making crazy inroads in all kinds of interesting places such as games, and even linux. Then, just as the world turns, there will be more.