Elementary confusion
John Baxter
jwbaxter at spamcop.net
Tue Sep 24 01:36:47 CEST 2002
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
More information about the Python-list
mailing list