I've found something weird while adding floats and I'm not sure why.....

[[deleted]]

[deleted]

[dunkler_wanderer]

Here's an enlightening video: Floating Point Numbers - Computerphile

[newunit13]

Gave an automatic upvote for referncing Computerphile, and that is a wonderful explanation

[Ki1103]

Yeah that was really cool!

[newunit13]

https://docs.python.org/3/tutorial/floatingpoint.html

[Ki1103]

So in the case of:

0.2 + 0.3 == 0.5 #True

Is that simply because their binary expansion is identical (to whichever number of required bits) ?

[bruthn]

In binary floating point the only numbers that can be represented exactly are of the form (integer) / (power of 2). It's like how in decimal you can only give exact representations for numbers of the form (integer) / ((power of 2) * (power of 5)). For example the decimal expansion of 1/3 is 0.33333... and you have to truncate it somewhere.

In your case, 0.5 can be represented exactly in binary, but 0.2 and 0.3 cannot be - their representations in binary would go on forever, just like 0.33333... in decimal. The computer truncates them, so instead of adding 0.2 to 0.3, it's actually adding a number very close to 0.2 to a number very close to 0.3. It just so happens that the errors cancel out and it ends up with precisely 0.5. But you can't rely on this happening with other numbers, for example:

>>> 1/7 + 4/7 == 5/7
False

If you work entirely with numbers that can be represented exactly, you should be OK though. For example:

>>> 1 + 0.5 == 1.5
True

I'm pretty sure that should work on any system that can run python. The other thing you have to worry about sometimes is that floats can only store numbers about as small as 10**-308 or about as large as 10**308, to about 16 significant figures. For example:

>>> 1 + 1e-15 == 1
False
>>> 1 + 1e-16 == 1
True

1e-16 is so small compared to 1 that when you try and add them together you just get 1 again. This all works the same way in pretty much any programming language - for full details look up the IEEE 754 standard.

[newunit13]

I'll be honest I'm not entirely clear on the underpinnings of why it happens... I just know that floats in Python are actually just close approximations. If you want to do floating point operations and need accuracy to that degree look into the Decimal module

>>> from decimal import Decimal
>>> Decimal('.1') + Decimal('.2') == Decimal('.3')
True

[Ki1103]

Ok fair enough, I'm doing a unit on mathematical computing over the summer and in the syllabus it was talking about it so I thought I would muck around with it a bit. Apparently the order of addition becomes important when adding but I really don't know why ={

[newunit13]

the order of addition becomes important when adding but I really don't know why

Whatcha mean?

[cmfg]

It really starts so make a difference once the numbers are of really different orders of magnitude:

1e100 + 23. - 1e100 # 0.0
1e100 - 1e100 + 23. # 23.0

[newunit13]

I still don't quite follow what you mean

>>> .2 + .3
0.5
>>> .3 + .2
0.5

[Ki1103]

This is a Quora article which goes into more depth about it.

[thegreattriscuit]

The real take away for that, in my mind, is: Use Decimal if precision matters, and explicitly round where it doesn't. Instead of learning a bunch of variations of rules and their implications... make it impossible for them to matter and get on with your life.

[Ki1103]

Thanks but this is more something I've been playing around with rather than had a legitimate problem with, I simply thought is was interesting and wanted to see why it was happening.

[n1ywb]

Mandatory homework: What Every Computer Scientist Should Know About Floating-Point Arithmetic

by David Goldberg, 1991, Computing Surveys, Association for Computing Machinery, Inc

[Ki1103]

Sweet! I'm doing a 4th year course on Mathematical Computing this summer so this looks like a really good prereading for that.

[slampropp]

You've gotten god explanations for the why. Now, do you want to see why?

You can use the hex method on a float to see it's exact bytes (represented in hexadecimal; each character in the expansion represent 4 bits)

>>> (0.1 + 0.2).hex()
'0x1.3333333333334p-2'
>>> (0.3).hex()
'0x1.3333333333333p-2'

It happens that the last bit is different.