# Math errors in python

Discussion in 'Python' started by Radioactive Man, Sep 18, 2004.

In python 2.3 (IDLE 1.0.3) running under windows 95, I get the
following types of errors whenever I do simple arithmetic:

1st example:
>>> 12.10 + 8.30

20.399999999999999
>>> 1.1 - 0.2

0.90000000000000013

2nd example(no errors here):
>>> bool(130.0 - 129.0 == 1.0)

True

3rd example:
>>> a = 0.013
>>> b = 0.0129
>>> c = 0.0001
>>> [a, b, c]

[0.012999999999999999, 0.0129, 0.0001]
>>> bool((a - b) == c)

False

This sort of error is no big deal in most cases, but I'm sure it could
become a problem under certain conditions, particularly the 3rd
example, where I'm using truth testing. The same results occur in all
cases whether I define variables a, b, and c, or enter the values
directly into the bool statement. Also, it doesn't make a difference
whether "a = 0.013" or "a = 0.0130".

I haven't checked this under windows 2000 or XP, but I expect the same
thing would happen. Any suggestions for a way to fix this sort of
error?

2. ### DogWalkerGuest

Have a look at the FAQ (before the response to your message builds).

----- Original Message -----
Newsgroups: comp.lang.python
To:
Sent: Saturday, September 18, 2004 9:50 AM
Subject: Math errors in python

In python 2.3 (IDLE 1.0.3) running under windows 95, I get the
following types of errors whenever I do simple arithmetic:

1st example:
>>> 12.10 + 8.30

20.399999999999999
>>> 1.1 - 0.2

0.90000000000000013

2nd example(no errors here):
>>> bool(130.0 - 129.0 == 1.0)

True

3rd example:
>>> a = 0.013
>>> b = 0.0129
>>> c = 0.0001
>>> [a, b, c]

[0.012999999999999999, 0.0129, 0.0001]
>>> bool((a - b) == c)

False

This sort of error is no big deal in most cases, but I'm sure it could
become a problem under certain conditions, particularly the 3rd
example, where I'm using truth testing. The same results occur in all
cases whether I define variables a, b, and c, or enter the values
directly into the bool statement. Also, it doesn't make a difference
whether "a = 0.013" or "a = 0.0130".

I haven't checked this under windows 2000 or XP, but I expect the same
thing would happen. Any suggestions for a way to fix this sort of
error?
--
http://mail.python.org/mailman/listinfo/python-list

DogWalker, Sep 18, 2004

3. ### Tim PetersGuest

> In python 2.3 (IDLE 1.0.3) running under windows 95, I get the
> following types of errors whenever I do simple arithmetic:
>
> 1st example:
> >>> 12.10 + 8.30

> 20.399999999999999

....

http://docs.python.org/tut/node15.html

Tim Peters, Sep 18, 2004
4. ### Gary HerronGuest

On Saturday 18 September 2004 09:50 am, Radioactive Man wrote:
> In python 2.3 (IDLE 1.0.3) running under windows 95, I get the
> following types of errors whenever I do simple arithmetic:
>
> 1st example:
> >>> 12.10 + 8.30

>
> 20.399999999999999

It's not a bug, it's a feature of binary arithmetic on ALL coumputers
in ALL languages. (But perhaps Python is the first time it has not
been hidden from you.)

See the Python FAQ entry 1.4.2:

http://www.python.org/doc/faq/general.html#why-are-floating-point-calculations-so-inaccurate

Gary Herron

Gary Herron, Sep 18, 2004
5. ### Jeremy BowersGuest

Jeremy Bowers, Sep 18, 2004
6. ### Peter OttenGuest

> thing would happen. Any suggestions for a way to fix this sort of
> error?

Starting with Python 2.4 there will be the 'decimal' module supporting
"arithmetic the way you know it":

>>> from decimal import *
>>> Decimal("12.10") + Decimal("8.30")

Decimal("20.40")
>>> Decimal("1.1") - Decimal("0.2")

Decimal("0.9")
>>> Decimal("130.0")-Decimal("129.0") == Decimal("1.0")

True
>>> a, b, c = map(Decimal, "0.013 0.0129 0.0001".split())
>>> a, b, c

(Decimal("0.013"), Decimal("0.0129"), Decimal("0.0001"))
>>> (a-b) == c

True

Peter

Peter Otten, Sep 18, 2004
7. ### =?iso-8859-1?Q?Michel_Claveau_-_abstraction_m=E9taGuest

Hi !

Many languages, yes.
All languages, no.

Few languages can use the DCB possibilities of the processors.

@-salutations
--
Michel Claveau

=?iso-8859-1?Q?Michel_Claveau_-_abstraction_m=E9ta, Sep 18, 2004
8. ### Dennis Lee BieberGuest

On Sat, 18 Sep 2004 20:54:42 +0200, Michel Claveau - abstraction
méta-galactique non triviale en fuite perpétuelle.
<> declaimed the
following in comp.lang.python:

>
> Few languages can use the DCB possibilities of the processors.
>

Uhmm... Data Control Block?

Did you mean BCD -- binary coded decimal. Which is a form of
decimal arithmetic, and not native binary floating point.

Considering how often the question about strange floating point
output comes up, I come to the conclusion that CS courses no longer
Manual regarding the differences between float and fixed, neither of
which imply decimal.)

Or find a copy of "Real Computing Made Real"
http://www.amazon.com/exec/obidos/tg/detail/-/0691036632/104-1507668-6795157?v=glance

--
> ============================================================== <
> | Wulfraed Dennis Lee Bieber KD6MOG <
> | Bestiaria Support Staff <
> ============================================================== <
> Overflow Page: <http://wlfraed.home.netcom.com/> <

Dennis Lee Bieber, Sep 18, 2004
9. ### =?iso-8859-1?Q?Michel_Claveau_-_abstraction_m=E9taGuest

Hi !

BCD (english) ==> DCB (french)

And Alcyane-basic run, in 1976, with floating-based-DCB-arithmétique, on the
8080, before than IEEE normalize the floating-arithmétique-pow(256)-based

And DCB is native in all Intel processors.

And before, when i use Fortran on mini-computer, there was no this problem.
But, then it's very much easy to work with pow(256), And the anscendant
compatibility become... Hélas.

Michel Claveau

=?iso-8859-1?Q?Michel_Claveau_-_abstraction_m=E9ta, Sep 18, 2004
10. ### Dennis Lee BieberGuest

On Sat, 18 Sep 2004 22:58:13 +0200, Michel Claveau - abstraction
méta-galactique non triviale en fuite perpétuelle.
<> declaimed the
following in comp.lang.python:

>
> And before, when i use Fortran on mini-computer, there was no this problem.

It may have been there, but you never saw it in print <G>

When I took classes in the 70s, we were taught never to rely
upon comparing two floating point numbers for equality. Instead, we were
told to compare for the difference between the two numbers being less
than some epsilon, with the epsilon defined as the smallest difference
that could be considered equal for the numbers being compared (if the
input is only good for 5 significant figures, the epsilon should not be
down into 7 significant)

a = 5.234
b = 5.235
epsilon = 0.0005
if abs(a - b) < epsilon then
equal

--
> ============================================================== <
> | Wulfraed Dennis Lee Bieber KD6MOG <
> | Bestiaria Support Staff <
> ============================================================== <
> Overflow Page: <http://wlfraed.home.netcom.com/> <

Dennis Lee Bieber, Sep 18, 2004
11. ### Dan BishopGuest

Gary Herron <> wrote in message news:<>...
> On Saturday 18 September 2004 09:50 am, Radioactive Man wrote:
> > In python 2.3 (IDLE 1.0.3) running under windows 95, I get the
> > following types of errors whenever I do simple arithmetic:
> >
> > 1st example:
> > >>> 12.10 + 8.30

> >
> > 20.399999999999999

>
>
> It's not a bug, it's a feature of binary arithmetic on ALL coumputers
> in ALL languages.

Actually, it's a feature of limited-precision floating-point in ANY
base, not just binary. This includes base-10. (I'm sure you've seen
BCD calculators that give 1/3*3=0.99999999.)

Dan Bishop, Sep 19, 2004
12. ### Chris S.Guest

Gary Herron wrote:

> On Saturday 18 September 2004 09:50 am, Radioactive Man wrote:
>
>>In python 2.3 (IDLE 1.0.3) running under windows 95, I get the
>>following types of errors whenever I do simple arithmetic:
>>
>>1st example:
>>
>>>>>12.10 + 8.30

>>
>>20.399999999999999

>
>
>
> It's not a bug, it's a feature of binary arithmetic on ALL coumputers
> in ALL languages. (But perhaps Python is the first time it has not
> been hidden from you.)
>
> See the Python FAQ entry 1.4.2:
>
> http://www.python.org/doc/faq/general.html#why-are-floating-point-calculations-so-inaccurate

That's nonsense. My 7-year old TI-83 performs that calculation just
fine, and you're telling me, in this day and age, that Python running on
a modern 32-bit processor can't even compute simple decimals accurately?

Chris S., Sep 19, 2004
13. ### Chris S.Guest

Peter Otten wrote:

>
>
>>thing would happen. Any suggestions for a way to fix this sort of
>>error?

>
>
> Starting with Python 2.4 there will be the 'decimal' module supporting
> "arithmetic the way you know it":
>
>

Great, why fix what's broken when we can introduce a new module with an
inconvenient API.

Chris S., Sep 19, 2004
14. ### Chris S.Guest

Jeremy Bowers wrote:

> On Sat, 18 Sep 2004 16:50:16 +0000, Radioactive Man wrote:
>
>
>>In python 2.3 (IDLE 1.0.3) running under windows 95, I get the
>>following types of errors whenever I do simple arithmetic:

>
>
> Specifically (building on DogWalker's reply),
> http://www.python.org/doc/faq/general.html#why-are-floating-point-calculations-so-inaccurate
>

Perhaps there's a simple explanation for this, but why do we go to the
trouble of computing fractions when our hardware can't handle the
result? If the decimal value of 1/3 is can't be represented in binary,
then don't. We should use an internal representation that stores the
numerator and denominator as separate integers.

Chris S., Sep 19, 2004
15. ### Peter OttenGuest

Chris S. wrote:

>> Starting with Python 2.4 there will be the 'decimal' module supporting
>> "arithmetic the way you know it":

> Great, why fix what's broken when we can introduce a new module with an
> inconvenient API.

1. It ain't broken.
2. What fraction of the numbers in your programs are constants?

Peter

Peter Otten, Sep 19, 2004
16. ### Gary HerronGuest

On Sunday 19 September 2004 12:18 am, Chris S. wrote:
> Jeremy Bowers wrote:
> > On Sat, 18 Sep 2004 16:50:16 +0000, Radioactive Man wrote:
> >>In python 2.3 (IDLE 1.0.3) running under windows 95, I get the
> >>following types of errors whenever I do simple arithmetic:

> >
> > Specifically (building on DogWalker's reply),
> > http://www.python.org/doc/faq/general.html#why-are-floating-point-calcula
> >tions-so-inaccurate

>
> Perhaps there's a simple explanation for this, but why do we go to the
> trouble of computing fractions when our hardware can't handle the
> result? If the decimal value of 1/3 is can't be represented in binary,
> then don't. We should use an internal representation that stores the
> numerator and denominator as separate integers.

That's called rational arithmetic, and I'm sure you can find a package
that implements it for you. However what would you propose for
irrational numbers like sqrt(2) and transcendental numbers like PI?

While I'd love to compute with all those numbers in infinite
precision, we're all stuck with FINITE sized computers, and hence with
the inaccuracies of finite representations of numbers.

Dr. Gary Herron

Gary Herron, Sep 19, 2004
17. ### Chris S.Guest

Gary Herron wrote:
> That's called rational arithmetic, and I'm sure you can find a package
> that implements it for you. However what would you propose for
> irrational numbers like sqrt(2) and transcendental numbers like PI?

Sqrt is a fair criticism, but Pi equals 22/7, exactly the form this
arithmetic is meant for. Any decimal can be represented by a fraction,
yet not all fractions can be represented by decimals. My point is that
such simple accuracy should be supported out of the box.

> While I'd love to compute with all those numbers in infinite
> precision, we're all stuck with FINITE sized computers, and hence with
> the inaccuracies of finite representations of numbers.

So are our brains, yet we somehow manage to compute 12.10 + 8.30
correctly using nothing more than simple skills developed in
grade-school. You could theoretically compute an infinitely long
equation by simply operating on single digits, yet Python, with all of
its resources, can't overcome this hurtle?

However, I understand Python's limitation in this regard. This
inaccuracy stems from the traditional C mindset, which typically
dismisses any approach not directly supported in hardware. As the FAQ
states, this problem is due to the "underlying C platform". I just find
it funny how a \$20 calculator can be more accurate than Python running
on a \$1000 Intel machine.

Chris S., Sep 19, 2004
18. ### Chris S.Guest

Peter Otten wrote:

> Chris S. wrote:
>
>
>>>Starting with Python 2.4 there will be the 'decimal' module supporting
>>>"arithmetic the way you know it":

>
>
>>Great, why fix what's broken when we can introduce a new module with an
>>inconvenient API.

>
>
> 1. It ain't broken.

Call it what you will, it doesn't produce the correct result. From where
I come from, that's either bad or broken.

> 2. What fraction of the numbers in your programs are constants?

What?

Chris S., Sep 19, 2004
19. ### Paul RubinGuest

Peter Otten <> writes:
> Starting with Python 2.4 there will be the 'decimal' module supporting
> "arithmetic the way you know it":
>
> >>> from decimal import *
> >>> Decimal("12.10") + Decimal("8.30")

I haven't tried 2.4 yet. After

a = Decimal("1") / Decimal("3")
b = a * Decimal("3")
print b

What happens? Is that arithmetic as the way I know it?

Paul Rubin, Sep 19, 2004
20. ### Richard TownsendGuest

On Sun, 19 Sep 2004 08:00:03 GMT, Chris S. wrote:

>
> Sqrt is a fair criticism, but Pi equals 22/7, exactly the form this
> arithmetic is meant for. Any decimal can be represented by a fraction,
> yet not all fractions can be represented by decimals. My point is that
> such simple accuracy should be supported out of the box.
>

Do you really think Pi equals 22/7 ?

>>> import math
>>> print math.pi

3.14159265359
>>> print 22.0/7.0

3.14285714286

What do you get on your \$20 calculator ?

--
Richard

Richard Townsend, Sep 19, 2004