Path: utzoo!attcan!uunet!lll-winken!lll-tis!helios.ee.lbl.gov!nosc!ucsd!ucbvax!UIAMVS.BITNET!BBUXEIPD
From: BBUXEIPD@UIAMVS.BITNET (Robert Pearson)
Newsgroups: comp.lang.c
Subject: Reason for using BCD arithmetic
Message-ID: <8810211335.AA19348@ucbvax.Berkeley.EDU>
Date: 21 Oct 88 13:37:18 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 26
X-Unparsable-Date: Wednesday 12 Oct 88 9:22 AM CT

> Date: Tue, 4 Oct 88 22:59:18 pdt
> Message-Id: <8810050559.AA05017@BOEING.COM>
> From: carroll%m211b@BOEING.COM (Jeff Carroll - BASC EM Staff)
> Subject: non-binary hardware?

> It's the same reason that Borland released a version of Turbo Pascal with
> BCD arithmetic - the fact (assertion?) that BCD arithmetic is impervious
> to roundoff error.
>
> I implore (and defer) to anyone who can explain why to do so.
>
> Nonetheless I assert that BCD arithmetic notwithstanding, the HP15C and
> the IBM PC are essentially binary machines.

     You are quite correct that BCD arithmetic has 'roundoff error', as all
'floating point' representations will have 'roundoff error' if the 'mantissa'
is exceeded.  However, when dealing with 'binary floating point' you have an
additional source of errors, converting between binary and decimal (BCD avoids
these errors by doing calculations in decimal).  It turns out that sometimes
these conversions can NOT be made exactly (the result is 'irrational' in the
other base) even if you have plenty of room in the 'mantissa'.  In these
cases, doing the calculation with BCD arithmetic will give an exact result,
but converting to 'binary floating point' will only give an approximate result
(because of the small amount of error introduced by the number 'base
conversion').  Some earily 'business' programs in BASIC suffered from this
very problem.  For some 'unknown' reason, the programs would occasionally be a
penny or two off ... needless to say, this can be a serious issue sometimes....