Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!rutgers!nike!ucbcad!ucbvax!decvax!tektronix!uw-beaver!ubc-vision!ubc-cs!ludemann
From: ludemann@ubc-cs.UUCP
Newsgroups: net.arch
Subject: Re: Floating point performance
Message-ID: <450@ubc-cs.UUCP>
Date: Fri, 24-Oct-86 02:50:09 EST
Article-I.D.: ubc-cs.450
Posted: Fri Oct 24 02:50:09 1986
Date-Received: Sun, 26-Oct-86 01:26:35 EST
References: <340@euroies.UUCP> <1989@videovax.UUCP> <722@mips.UUCP> <6028@ut-sally.UUCP> <253@BMS-AT.UUCP>
Reply-To: ludemann@ubc-cs.UUCP (Peter Ludemann)
Organization: UBC Department of Computer Science, Vancouver, B.C., Canada
Lines: 16
Summary: BCD is unnecssary

In article <253@BMS-AT.UUCP> stuart@BMS-AT.UUCP writes:
>For problems unsuited to floating point, e.g. accounting, yes the
>floating point hardware gets in the way.  For accounting one should
>use large integers: 48 bits is plenty in practice and no special hardware
>is needed.  

As someone who has done accounting using floating point for 
accounting, I wish to point out that 8-byte floating point has more 
precision than 15 digits of BCD.  Remembering that the exponent only 
takes a "few" bits, I'll happily use floating point any day instead 
of integers (even 48 bit integers).  Integers work fine for 
accounting as long as one is adding and subtracting but if one has to 
multiply (admittedly, not often), there's big trouble.  After quite a 
number of attempts to make things balance to the penny, I changed to 
floating point and all my problems vanished (the code ran faster, 
too).