Re: Problem in Float Arithmetic

Tech-Archive recommends: Speed Up your PC by fixing your registry




"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







.



Relevant Pages

  • Re: Problem in Float Arithmetic
    ... (going on forever) ... The computer pads with zeroes to whatever precision you specify, but in maths 0.3 and 0.30 mean rather different things. ... The OP's problem is a classic one of error dominance when you subtract two ... by using double precision - and the first lesson I learned in programming (n ...
    (microsoft.public.vc.mfc)
  • Re: Problem in Float Arithmetic
    ... precision of 0.01, but if you say 0.3, you only know it to 0.1. ... A friend of mine who taught physics for over 50 years once required his entire class to ... The OP's problem is a classic one of error dominance when you subtract two ... by using double precision - and the first lesson I learned in programming (n ...
    (microsoft.public.vc.mfc)
  • Re: Perform forever
    ... It is a difficult and tenuous concept to explain why I consider FOREVER ... The fact is that I do, and like you stated, I don't care to argue it ... When I exit it I don't care whether it keeps ... >> computer programming practice. ...
    (comp.lang.cobol)
  • New RL sucker, er, developer
    ... It's been near forever since I did any ... real programming and I want to learn Java, ... So far I have a movable map (the map scrolls behind ...
    (rec.games.roguelike.development)