Math errors in python

R

Radioactive Man

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:0.90000000000000013


2nd example(no errors here):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?
 
D

DogWalker

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

----- Original Message -----
From: Radioactive Man
Newsgroups: comp.lang.python
To: (e-mail address removed)
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:0.90000000000000013


2nd example(no errors here):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?
 
G

Gary Herron

P

Peter Otten

Radioactive said:
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":
True


Peter
 
?

=?iso-8859-1?Q?Michel_Claveau_-_abstraction_m=E9ta

Hi !

Many languages, yes.
All languages, no.

Few languages can use the DCB possibilities of the processors.

@-salutations
 
D

Dennis Lee Bieber

On Sat, 18 Sep 2004 20:54:42 +0200, Michel Claveau - abstraction
méta-galactique non triviale en fuite perpétuelle.
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
teach the basics of representation... (Try reading the Ada Reference
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

--
 
?

=?iso-8859-1?Q?Michel_Claveau_-_abstraction_m=E9ta

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 longer before Ada).

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.


*sorry for my bad english*


Michel Claveau
 
D

Dennis Lee Bieber

On Sat, 18 Sep 2004 22:58:13 +0200, Michel Claveau - abstraction
méta-galactique non triviale en fuite perpétuelle.
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

--
 
D

Dan Bishop

Gary Herron said:
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.)
 
C

Chris S.

Gary said:
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?
Don't defend bad code.
 
C

Chris S.

Peter said:
Radioactive Man 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.
 
C

Chris S.

P

Peter Otten

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
 
G

Gary Herron

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
 
C

Chris S.

Gary said:
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.
 
C

Chris S.

Peter said:
Chris S. wrote:




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?
 
P

Paul Rubin

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

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?
 
R

Richard Townsend

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 ?
3.14285714286

What do you get on your $20 calculator ?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,756
Messages
2,569,535
Members
45,008
Latest member
obedient dusk

Latest Threads

Top