Floating Point Numbers

September 08, 2024 Post a Comment

So I am reading this PDF tutorial called: 'Learning Python Fourth Edition'. Now I got to a part which I dont understand because I am pretty much a beginner in Python. I am talking

Solution 1:

This isn't a Python issue but an issue with the nature of floating point numbers. Turns out that computers are bad at representing numbers. Who knew?

I recommend reading What Every Computer Scientist Should Know About Floating-Point Arithmetic if you have the time.

Now, as to the actual Python side of this, every object has a method called __str__ and one called __repr__. These are supposed to produce strings to be displayed in various circumstances. You will see these if you use the builtin repr or str functions on any object, or if you use the "%r" or "%s" formats in string formatting. When you evaluate something at the interactive prompt, you get the repr by default. When you pass something to print, you get the str by default.

Floating point number objects have their __repr__s defined in such a way to represent them at maximum precision (attainable in decimal, at least), while their __str__ is defined in such a way that they tend to look more like what you would want to show a user. Users don't want to know that floats aren't real numbers, so it doesn't show that extra precision to them.

Solution 2:

The answer to "what is the difference between str and repr" and even "what does full precision mean", depends on the Python version.

The behaviour of repr(f) changed in 3.1 and 2.7.

Before 2.7 (including Python 3.0), repr(f) would give up to 17 significant digits, as if formatted with %17g. An IEEE-754 floating point value has 53 significant binary digits, which is approximately 16 decimal digits. 17 significant digits guarantee that each binary value produce a different decimal value.
In Pythons 2.7 and 3.1, the repr(f) was made human-friendly while still keeping the precision:

The repr() of a floatx is shorter in many cases: it’s now based on the shortest decimal string that’s guaranteed to round back to x. As in previous versions of Python, it’s guaranteed that float(repr(x)) recovers x.

The behaviour of str(f) was changed in Python 3.2:

In 2.x, 3.0 and 3.1: str(f) gives decimal values rounded to only 12 significant digits, as if formatted with %12g; the precision was controlled by the PyFloat_STR_PRECISION macro in Objects/floatobject.h.
In 3.2+, str(f) behaves identically to repr(f) - as repr output since 3.1 was significantly more human-friendly, and since the str(f) was losing precision, it was decided that starting from Python 3.2 str(f) should be identical to repr(f).

The following examples demonstrate changes in repr behaviour. The old behaviour was:

Python 2.6.8 (unknown, Jan 262013, 14:35:25) 
[GCC 4.7.2] on linux2
Type"help", "copyright", "credits"or"license"for more information.
>>> 3.1415 * 26.2830000000000004>>>

whereas the new behaviour is:

Python 2.7.3 (default, Mar 132014, 11:03:55) 
[GCC 4.7.2] on linux2
Type "help", "copyright", "credits"or"license"for more information.
>>> 3.1415 * 26.283

The old behaviour for str (before Python 3.2) was to round values to 12 significant digits, losing information:

Python 2.7.3 (default, Mar 132014, 11:03:55) 
[GCC 4.7.2] on linux2
Type"help", "copyright", "credits"or"license"for more information.
>>> str(0.1000000000000999)
'0.1'>>> 0.1 == 0.1000000000000999False>>> repr(0.1000000000000999)
'0.1000000000000999'

The new behaviour since Python 3.2 is to behave like repr:

Python 3.2.3 (default, Feb 202013, 14:44:27) 
[GCC 4.7.2] on linux2
Type"help", "copyright", "credits"or"license"for more information.
>>> str(0.1000000000000999)
'0.1000000000000999'>>> repr(0.1000000000000999)
'0.1000000000000999'

The reason for why rounding will occur, is because floating point numbers in Python are represented as IEEE-754 double precision; one number takes 64 bits, with 1 bit reserved for sign, 10 for exponent and 53 for the mantissa (the actual numbers).

Many values, such as π or 1/3 cannot be accurately represented as an IEEE-754 binary floating point value. Even such a common number as 0.01 cannot be represented exactly.

The Python 3 floats have the method hex() that will convert the number to hex representation, which can be used to easily see the problem:

>>> (0.01).hex()
'0x1.47ae147ae147bp-7'

So, as hex, the number 0.01 would be approximated in binary as 1.47AE147AE147A4147AE... · 2; rounded to the closest number in 53 significant bits, this is represented as 1.47AE147AE147B · 2

I have written some more gory details on how repr works in 2.7, 3.1 in my answer to question Precision of repr(f), str(f), print(f) when f is float.

Solution 3:

Basically, the computer's floating point calculations have rounding errors. So if you perform 1.*1000./1000., you can end up with 1.0000004 or something like that. It is what the computer stores in the memory. However, you probably don't want to see 1.0000004 as a result of that calculation. So when you print the result, the computer does the rounding, and you will get simply 1. But you have to know that it is not the real value in the computer's memory - it is only a comfortable visualization of your actual floating point number.

Solution 4:

By full precision they mean with all decimals digits the number is stored as. Because of how numbers are stored on the computer (in binary), this will often not be 100% accurate.

Solution 5:

The book you're reading is imprecise. If you truly want to see a float to full precision, use the decimal module:

>>>import decimal>>>decimal.Decimal(3.1415 * 2)
Decimal('6.28300000000000036237679523765109479427337646484375')

Every (finite) binary float can be exactly represented as a (finite) decimal float. The converse is not true - in fact, most decimal floats cannot be exactly represented as (finite) binary floats.

The difference for older versions of CPython is that repr(a_float) produced 17 significant decimal digits. While proving this is difficult, it turns out that 17 significant decimal digits is enough so that eval(repr(a_float)) == a_float is always true for floats implemented as IEEE-754 "double precision" binary floats (which virtually all machines now use) - and 16 significant decimal digits is not enough. 17 is not "full precision", it's "enough precision so that round-tripping always works".

In current versions of CPython, repr(a_float) produces the shortest decimal string such that eval(repr(a_float)) == a_float. That's much harder to get right. For "random" floats it's likely still to produce 17 decimal digits, but for the "simple floats" people tend to enter by hand, it's likely to produce the same string you typed in.

Python Dictionary