[Discuss] Financial database / balance?

[Jerry Feldman]

IBM's packed decimal had an effectively unlimited number of digits that
the COBOL or PL/1 programmer expressed (such as the COBOL 9999999.99 has
9 digits with 2 to the right of the decimal point and took up 5 bytes
with the sign taking up the rightmost nybble. External decimal is
similar except each digit is a byte. In IBM mainframe, before you could
perform arithmetic you had to pack the fields. In Burroughs, the
hardware had a flag where each field had a type flag so you could add a
signed external decimal to an unsigned packed decimal and yield a signed
external decimal. On microprocessors, BCD may be implemented on integer
or even floating point. But on IBM Mainframes if you wanted a 50 digit
packed decimal you could have it. The hardware had 3 types, Float,
Integer, and BCD. Microprocessors generally have only Integer and IEEE
floating point. (Jack this is coming from my wayback machine in the
1960s and 1970s where I worked with IBM and Burroughs mainframes in both
COBOL and assembler.

The 15 decimal digit limit seems to be related to double precision
floating point or possibly BCD implemented on 64-bit ints. Effectively
if I were going to implement a BCD template library in C++ I would not
limit the size. To be efficient I would possibly implement it in
integers because integer math is usually much faster.

On 01/15/2012 01:29 PM, Jack Coats wrote:
> I have had issues with IBMs packed decimal being to short (8 bytes,
> giving 15 decimal digits plus a sign) for keeping assets of large
> companies. (yes, very large.  Normally we resorted to either writing
> our own math package or using 'dollar only' accounting.  The IRS
> normally is OK with that.  Just don't try it on payroll!)
>
> The rounding errors with them only occurred during advanced operations
> (not add and subtract).  Division mainly.  But you had to keep track
> of your own decimal alignment.
>
> If doing financial modeling, keeping numbers rounded to the nearest
> thousand is often sufficient, depending on the data you are using.
> But then you can turn to double precision float for pretty good
> results.  If doing that, just realize a model is a 'guess' so the
> rounding isn't normally much of an issue.
>
> I am having to roll out my waybackmachine to remember some of those
> days. ... Glad someone else is doing this for a living!


-- 
Jerry Feldman <gaf at blu.org>
Boston Linux and Unix
PGP key id:3BC1EB90 
PGP Key fingerprint: 49E2 C52A FC5A A31F 8D66  C0AF 7CEA 30FC 3BC1 EB90