🚀 go-pugleaf

In article <832@cbnewsc.ATT.COM>, nevin1@cbnewsc.ATT.COM (nevin.j.liber) writes:
| In article <960018@hpclskh.HP.COM| skh@hpclskh.HP.COM (The Polar Bear) writes:
| |Integer arithmetic is often of insufficient range for financial applications.
| |When you start doing programs for multi-national companies and governments,
| |you start needing exponents.
| But how do you get the needed PRECISION from floating point?  Unless
| these mulit-national comanies and governments don't mind losing a few
| dollars when the numbers get too big. :-)  Please elaborate.

It is clear to anyone who thinks about it that both answers alluded to above
are wrong.  Use of integers (even considering only the case of US money
amounts) to scale money to cents (eg: $100 = 10000 cents) limits you to values
less than about $43 million.  If you have to keep track of more decimal places
and scale accordingly (the value of stock shares to five decimal places, for
example), the limit on the magnitude is correspondingly less.

Floating point, of course, avoids the above problem, but suffers from loss of
precision as the poster above points out.  Loss of precision can be disastrous
when dealing with other people's money!!!

The way commercial data processing machines and languages solved this problem
was through the use of (to use IBM terminology) packed decimal representations
and arithmetic units.  Unfortunately, C and other languages with
scientific/engineering or systems programming origins (FORTRAN, PASCAL, BLISS,
etc) do not support this data type.  COBOL and PL/I do.  In this representation
the decimal digits are represented by BCD-encoded nibbles (1/2-bytes) with the
number of digits and the location of the decimal point carried along in binary
counters.  One might be able to simulate this in C by using a structure
consisting of the two counters and (a pointer to) a character string with two
digits per character.  Since most non-commercial machines do not have packed
decimal arithmetic units, doing arithmetic with such structures would be very
painful from the standpoint of CPU cycles per operation.

				Rich Strebendt
				...!att!ihlpj!res