[Discuss] Financial database / balance?

[gaf at blu.org (Jerry Feldman)]

On 01/14/2012 12:43 PM, Richard Pieri wrote:
> On 1/14/2012 9:44 AM, Jerry Feldman wrote:
>> But, Richard Pieri has a very good point about BCD (Binary Coded
>> Decimal). The problem with BCD is that it is generally not supported in
>> any common microprocessor that I am aware of, but you can use a 64 bit
>> int and scale it. Using a 64-bit integer you are not going to lose any
>> precision as a LONG_MAX is
>
> Implementing a BCD math library isn't difficult.  It certainly would
> be slower than using native INTs and FLOATs but not devastatingly so.
>
> You can use INTs as Jerry suggests and pretend that decimals don't
> exist except for display purposes.  So, for example, $1,524.79 would
> be stored as 1524790 which gives you three places of decimal precision
> (mils).
>
However, double precision floating point has a precision up to 15
decimal digits, BUT the data is stored in binary (assuming IEEE) with 1
sign bit, 11 exponent bits, 52 bits (actually 53 since there is a hidden
bit in normalized numbers) for the mantissa. One issue is that some
decimal numbers cannot be stored exactly. Mainframes used to have BCD
hardware. BCD is interesting in that the programmer defines the
precision of the number, and the digits are stored either as nybbles or
bytes. One issue we used to run into is that IBM stores packed decimal
always with a sign nybble. Burroughs hardware could operate on either
packed or external decimal, with or without a sign. Made conversions
interesting. COBOL and PL/1 had the tools for dealing with these numbers.

In the case of using both 64-bit ints (longs on Linux and Unix, and long
longs on Windows) AND BCD is that you have to scale your numbers. Not a
big deal, you can write a C++ or Java class for those. You also have to
think in terms of rounding. For personal use, using 64-bit ints are
probably the better alternative in terms of the amount of coding, but
your can check the Internet and easily find BCD classes to work with.

-- 
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