Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp
Path: utzoo!watmath!clyde!burl!ulysses!allegra!mit-eddie!genrad!decvax!decwrl!sun!jfarrell
From: jfarrell@sun.uucp (Jerry Farrell)
Newsgroups: net.lang.c
Subject: Re: C needs BCD -- why BCD?  Accountants!
Message-ID: <1794@sun.uucp>
Date: Wed, 14-Nov-84 16:48:54 EST
Article-I.D.: sun.1794
Posted: Wed Nov 14 16:48:54 1984
Date-Received: Fri, 16-Nov-84 06:49:33 EST
References: <105@ISM780B.UUCP> <869@ihuxn.UUCP>, <904@umcp-cs.UUCP> <4611@utzoo.UUCP>
Organization: Sun Microsystems, Inc.
Lines: 26

> Of course the business people use decimal arithmetic; it never occurred
> to them to do anything else.

Uhh, can we have a slight intrusion of reality?  Back when I was
writing COBOL programs to compute the faculty contact hours per square
foot of classroom floor space and other inania like that, the various
encodings of numeric were very familiar to us; we chose among them on
several criteria:
    frequency of presentation vs. calculation 
	many numbers could be used in a calculation, but were much more
	likely to simply be printed or displayed.  For these, it was
	generally most efficient to take COBOL's default numeric type,
	DISPLAY -- i.e. digit characters.
    space
	There are a few cases where BCD actually uses less space than
	simple binary: on most machines, +/-99,999 requires you to go
	from 16 to 32 bits, but it fits in 6 bytes of BCD.
    debugging ease
	when you're looking at a disk buffer for the record that seems
	to have the wrong number in it, it saves a lot of time if the
	number is intelligible to carbon-based, as well as silicon-based
	forms.
I can attest we used COMP-1 (binary) as well as COMP-3 (packed / bcd);
what we avoided like the plague was COMP-2 (32-bit float).  COMP-3 was
generally chosen as a reasonable compromise between presentation &
calculation, with an occasional bow toward debugging.