[NTLUG:Discuss] The wrong computation example from the newsgroup
Steve Baker
sjbaker1 at airmail.net
Sun Mar 18 12:57:19 CST 2001
Peter Koren wrote:
> As Steve Baker said, if you depend on exact floating point results, you
> are apt to get screwed. Some base ten numbers like 0.3 and 0.7 can not
> be exactly represented in binary. Then there is the semantics issue of
> what should the result be. BTW, The Python community is debating
> changing the semantics of integer arithmetic and there is no consensus
> yet.
You *can* fix this so it works as expected - you have to use an ancient
technique called 'BCD' (Binary-coded-decimal) math. In this scheme,
you do all your arithmetic in base 10 using a system that packs two
decimal digits into a single byte.
There used to be instructions in CPU hardware for doing BCD math...
maybe even modern Intel CPU's have them - I'm not sure if they
were retained from the 8080 and 8085 through into the 8086 and
then inherited into the Pentium.
BCD is probably still used in banking and accountancy software where
losing the odd cent due to roundoff error is unacceptable.
BCD isn't immune to the problem that started this thread, you'll
still find that:
(int)( ( 10.0 / 3.0 ) * 3.0 )
...may turn out to be either 9 or 10...but at least this meets human
expectations that 1/3 is a recurring number but 0.3 is somehow something
'exact'.
In the end, everyone needs to realise that whilst floating point
math is pretty accurate, it isn't *infinitely* accurate and if you
go to some pains to amplify that small amount of imprecision, you
can force it to make an impact in the 'real' world of things that
your users see and care about.
--
Steve Baker HomeEmail: <sjbaker1 at airmail.net>
WorkEmail: <sjbaker at link.com>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
http://freeglut.sourceforge.net
More information about the Discuss
mailing list