Elementary confusion

[John Baxter]

In article <878z1s1kqf.fsf at smtp.blueyonder.co.uk>,
 Keith <kroc at blueyonder.co.uk> wrote:

> Hi,
> 
> I am working through O'Reilly's "Learning Python". I am up to page 33,
> and already I have a problem. The text outlines a cli entry about math
> operators, all really straight forward;
> 
> .>>>a=3
> .>>>b=4
> .>>>b/2+a
>  5
> .>>>b/(2.0+a)
>  0.8
> 
> This is so straight forward that I wasn't going to type it in, but I
> did anyway, and got instead of '0.8' something I cannot account for. I
> got '0.80000000000000004'.
> 
> So after 32 pages, I am already flumoxed. What is going on

In fact, the example is far from straight forward...it (now) exemplifies 
the fact that your computer can't represent 0.8 exactly in binary 
floating point, which Python uses for values like 0.8.  It comes close 
(supposedly as close as possible).  It's not a question of 
precision...double (or far more than double) the number of bits 
involved, and 0.8 still can't be represented exactly.

The 0.80000000000000004 is as close as your hardware can come (or it 
isn't as close as your hardware can come, and there are issues with the 
libraries or the chip).

Learning Python describes an older Python in which the interpreter lied 
about the value by rounding it to 0.8; the interpreter no longer does 
that, so you learn sooner about that problem.

You will encounter this issue over and over...for example on my machine:

$python
Python 2.2 (#1, 07/14/02, 23:25:09)
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> a=0.1
>>> b=0.2
>>> c=a+b
>>> c==0.3
0
>>> c
0.30000000000000004
>>> d=0.3
>>> d
0.29999999999999999
>>>

We "know" that c is 0.3.  The computer has added two inexact values 
which are "too big" and produced a result which is therefore both "too 
big" and not the nearest representation of 0.3, which is "too small".

  --John