On Tue, 01 Jul 2014 14:17:14 -0700, Pedro Izecksohn wrote: > pedro@microboard:~$ /usr/bin/python3 > Python 3.3.2+ (default, Feb 28 2014, 00:52:16) [GCC 4.8.1] on linux > Type "help", "copyright", "credits" or "license" for more information. >>>> 1-0.95 > 0.050000000000000044 >>>> >>>> > How to get 0.05 as result?

## Advertising

Oh, this is a fantastic example of the trouble with floating point! Thank you for finding it! py> 0.05 0.05 py> 1 - 0.95 0.050000000000000044 py> 1 - 0.9 - 0.05 0.049999999999999975 py> 1 - 0.5 - 0.45 0.04999999999999999 *This is not a Python problem* This is a problem with the underlying C double floating point format. Actually, it is not even a problem with the C format, since this problem applies to ANY floating point format, consequently this sort of thing plagues *every* programming language (unless they use arbitrary-precision rationals, but they have their own problems). In this *specific* case, you can get better (but slower) results by using the Decimal format: py> from decimal import Decimal py> 1 - Decimal("0.95") Decimal('0.05') This works because the Decimal type stores numbers in base 10, like you learned about in school, and so numbers that are exact in base 10 are (usually) exact in Decimal. However, the built-in float stores numbers in base 2, for speed and accuracy. Unfortunately many numbers which are exact in base 10 are not exact in base 2. Let's look at a simple number like 0.1 (in decimal), and try to calculate it in base 2: 0.1 in binary (0.1b) equals 1/2, which is too big. 0.01b equals 1/4, which is too big. 0.001b equals 1/8, which is too big. 0.0001b equals 1/16, which is too small, so the answer lies somewhere between 0.0001b and 0.001b. 0.00011b equals 1/16 + 1/32 = 3/32, which is too small. 0.000111b equals 1/16 + 1/32 + 1/64 = 7/64, which is too big, so the answer lies somewhere between 0.000111b and 0.00011b. If you keep going, you will eventually get that the decimal 0.1 written in base 2 is .000110011001100110011001100110011... where the "0011" repeats forever. (Just like in decimal, where 1/3 = 0.33333... repeating forever.) Since floats don't use an infinite amount of memory, this infinite sequence has to be rounded off somewhere. And so it is that 0.1 stored as a float is a *tiny* bit larger than the true decimal value 0.1: py> Decimal.from_float(0.1) Decimal('0.1000000000000000055511151231257827021181583404541015625') All the troubles with floating point numbers start with this harsh reality, numbers have to be rounded off somewhere lest they use infinite memory, and that rounding introduces errors into the calculation. Sometimes those errors cancel, and sometimes they reinforce. To understand what is going on in more detail, you can start with these links: https://docs.python.org/2/faq/design.html#why-am-i-getting-strange-results-with-simple-arithmetic-operations http://docs.oracle.com/cd/E19957-01/806-3568/ncg_goldberg.html http://effbot.org/pyfaq/why-are-floating-point-calculations-so-inaccurate.htm http://blog.codinghorror.com/why-do-computers-suck-at-math/ https://randomascii.wordpress.com/category/floating-point/ https://www.gnu.org/software/gawk/manual/html_node/Floating-Point-Issues.html Good luck! -- Steven -- https://mail.python.org/mailman/listinfo/python-list