
Boost : 
From: danl_miller (danl_miller_at_[hidden])
Date: 20020306 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 64bit integers, 32bit integers were considered too
small for most serious software at major financial institutions
because a 32bit unsigned integer is capable of storing only
$42,949,673.00 if precision to the nearestcent (instead of the
nearest mil) is required and a 32bit 2scomplement signed integer is
capable of storing only $21,474,836.00 if precision to the
nearestcent (instead of the nearest mil) is required. (And $42
million is a tiny amount of money at some financial institutionsa
full 3 orders of magnitude less than the assets managed by my former
employer.)
Floatingpoint 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 32bit limitations (when used on a 32bit 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
arbitraryprecision 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 arbitrarilyprecision
arithmetic & numberrepresentations is both a real & perceived problem
for C & C++ software on 32bit (and smaller) CPUarchitectures.
In recent years the availability of a few 64bit CPUarchitectures
has raised an interesting alternative to BCD in the financial software
world. With advent of AMD's 64bit Hammer (ClawHammer, SledgeHammer)
extensions to the IA32 instruction set used on Pentium/Athlon CPUs
and with Intel's Itanium (and with rumors that Intel has a 64bit
extension of their own for IA32 in case AMD's Hammer series shows
that there is demand for a 64bit version of the x86 family), we might
even see 64bit CPUs enter the mainstream. In recent years many C &
C++ compilers have added support for long long as a representation of
64bit integers. 64bit 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 financialemployment days, I would have said
"Amen. My prayers have been answered!" Nowadays I would say,
"BCD/arbitraryprecision arithmetic would be convenient in certain
contexts where 64bit 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
assemblylanguage 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 x86based implementation of this thenstandardized
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 fixedpoint (nonBCD) representations might be very useful on
fixedpoint digitalsignal processors. Indeed, DSP instructions on a
fixedpoint DSP processor might be a very useful implementation of
fixedpoint arithmetic, especially when fixedpoint
numberrepresentations would be combined with the matrix library. I
am no DSP expert. Would any DSPknowlegable people care to comment?
This brings up another comment of mine: Shouldn't
arbitraryprecision BCD arithmetic & number representations be kept
separate conceptually from binary & 2scomplement arbitraryprecision
fixedpoint arithmetic & number representations. They seem as though
they are for drastically different purposesfinance versus
engineeringand drastically different gutsbase10 in nybbles
versus base2 in bits.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk