Re: BCD and/or Fixed point decimal classes

From: danl_miller (danl_miller_at_[hidden])
Date: 2002-03-06 22:22:15

--- In boost_at_y..., "p_michel_andre" <michel.andre_at_e...> wrote:
> Hello!
> 
> I've tried to search the archive for references on discussions of 
> Fixed point decimal and/or Binary Coded Decimal arbitrary precision 
> libraries.
> 
> Would there be any intrest in discussing and making a requirement 
> description on such a library. I would be willing to implement such
a 
> library.
> 
> /Michel

  Back before 64-bit integers, 32-bit integers were considered too
small for most serious software at major financial institutions
because a 32-bit unsigned integer is capable of storing only
$42,949,673.00 if precision to the nearest-cent (instead of the
nearest mil) is required and a 32-bit 2s-complement signed integer is
capable of storing only $21,474,836.00 if precision to the
nearest-cent (instead of the nearest mil) is required.  (And $42
million is a tiny amount of money at some financial institutions---a
full 3 orders of magnitude less than the assets managed by my former
employer.)

Floating-point is considered absolutely unacceptable by most
accounting departments at such major financial institutions. 
(Accountants/auditors working in the $100+ million world please
respond if there are any such members of Boost.)  Back 10 years ago
when I worked at such a financial institution, there was a fair amount
of debate between the COBOL & C/C++ community about precision of
integers and whether C/C++ was permissible at all as a language due to
its inherent 32-bit limitations (when used on a 32-bit CPU
architecture, which was all that we had generally available 10 years
ago).

  As it turned out in my own case, a truce was called when C/C++ was
deemed appropriate for asset classes whose total holdings at that
employer were far far below the $42 million level.  COBOL (and its
arbitrary-precision arithmetic) was deemed as the language appropriate
for the overall asset management software which needed to work with
monies as large as $50 billion.

  Thus, yes, I think that the absence of arbitrarily-precision
arithmetic & number-representations is both a real & perceived problem
for C & C++ software on 32-bit (and smaller) CPU-architectures.

  In recent years the availability of a few 64-bit CPU-architectures
has raised an interesting alternative to BCD in the financial software
world.  With advent of AMD's 64-bit Hammer (ClawHammer, SledgeHammer)
extensions to the IA-32 instruction set used on Pentium/Athlon CPUs
and with Intel's Itanium (and with rumors that Intel has a 64-bit
extension of their own for IA-32 in case AMD's Hammer series shows
that there is demand for a 64-bit version of the x86 family), we might
even see 64-bit CPUs enter the mainstream.  In recent years many C &
C++ compilers have added support for long long as a representation of
64-bit integers.  64-bit integers could represent
$184,467,XXX,XXX,XXX,XXX.XX or $184,467 trillion (assuming that
accuracy to the nearest cent is required instead of the nearest mil)
which is quite comfortable for all financial calculations worldwide
for the forseeable future, I would think. 

  Thus 10 years ago in my financial-employment days, I would have said
"Amen.  My prayers have been answered!"  Nowadays I would say,
"BCD/arbitrary-precision arithmetic would be convenient in certain
contexts where 64-bit integers are not available."

  Quite honestly in a mature implementation of a BCD library, a BCD
library for x86 CPU architectures should be implemented in
assembly-language because of direct support for BCD in x86 instruction
set.  If you were to write a BCD library for Boost and hypothetically
that BCD library were adopted as part of some C++ standard, I would
expect a commercial x86-based implementation of this then-standardized
BCD library to be written in x86 assembly.  As an effort reduction, I
would expect that the Boost library be written in portable C++ for the
foreseeable future, despite probably being notably slower.

  Also fixed-point (nonBCD) representations might be very useful on
fixed-point digital-signal processors.  Indeed, DSP instructions on a
fixed-point DSP processor might be a very useful implementation of
fixed-point arithmetic, especially when fixed-point
number-representations would be combined with the matrix library.  I
am no DSP expert.  Would any DSP-knowlegable people care to comment?

  This brings up another comment of mine:  Shouldn't
arbitrary-precision BCD arithmetic & number representations be kept
separate conceptually from binary & 2s-complement arbitrary-precision
fixed-point arithmetic & number representations.  They seem as though
they are for drastically different purposes---finance versus
engineering---and drastically different guts---base-10 in nybbles
versus base-2 in bits.