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.