Re: Problem in Float Arithmetic
- From: "David Webber" <dave@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Tue, 24 Jun 2008 12:47:15 +0100
"Doug Harrison [MVP]" <dsh@xxxxxxxx> wrote in message news:6i9v54h6dvjvmsai7gkuo19q0tketmg0o2@xxxxxxxxxx
That will give him a more accurate result, but it still won't be exact.
Floating point arithmetic is never "exact" you'd need to store an infinite number of decimal places for it to be so. And even if you could people would start complaining that they were getting
0.999999 (going on forever)
instead of
1.00000 (going on forever)
which is of course the same number.
Of course many people identify say 0.3 as meaning the same as 0.30000 with zeroes going on forever, but that soon becomes untenable with floating point arithmetic.
So my advice is never to use the words "floating point" and "exact" in the same breath. :-)
The OP's problem is a classic one of error dominance when you subtract two similar numbers. It was understood by numerical mathematicians long before digital computers were invented. In this case one can alleviate the problem by using double precision - and the first lesson I learned in programming (n FORTRAN IV) was "never write REAL; always write REAL*8 (or DOUBLE PRECISION)".
But sooner or later you'll get two numbers which are so close together that double precision isn't good enough.
The secret is to rearrange the order of your computation so that if two numbers are likely to end up being similar, you don't subtract them.
For example if x can be close to 1, and you inadvertently have some long computation which includes
a = 1-x;
....
b = a + 2x;
....
c = 1 - a*b;
Then you'll get some number for c. If the computation were exact you'd get the same result as
c = x*x;
but if x is very close to 1 you won't! The answer is to use c=x*x. This is a fairly trivial example, and in general it can take more thought to avoid subtraction errors, but that is essentially the skill of scientific programming. Rule no 1 is always to know how your errors are being carried through the program.
Double precision is a useful insurance, which will cover you in a lot of cases, but the policy doesn't cover everything :-)
Dave
--
David Webber
Author of 'Mozart the Music Processor'
http://www.mozart.co.uk
For discussion/support see
http://www.mozart.co.uk/mozartists/mailinglist.htm
.
- Follow-Ups:
- Re: Problem in Float Arithmetic
- From: Joseph M . Newcomer
- Re: Problem in Float Arithmetic
- From: Doug Harrison [MVP]
- Re: Problem in Float Arithmetic
- References:
- Problem in Float Arithmetic
- From: Selvam
- Re: Problem in Float Arithmetic
- From: Christoph Conrad
- Re: Problem in Float Arithmetic
- From: Doug Harrison [MVP]
- Problem in Float Arithmetic
- Prev by Date: ip
- Next by Date: Re: Problem in Float Arithmetic
- Previous by thread: Re: Problem in Float Arithmetic
- Next by thread: Re: Problem in Float Arithmetic
- Index(es):
Relevant Pages
|