From: p_michel_andre (michel.andre_at_[hidden])
Date: 2002-03-07 03:30:10
--- In boost_at_y..., "danl_miller" <danl_miller_at_b...> wrote:
> 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
> 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
All currencies and financial entities aren't rounded to two decimals
with eq rates need an higher scale and one need to do rate based
calculations on a higher precision and then round the result as one
> Floating-point is considered absolutely unacceptable by most
> accounting departments at such major financial institutions.
It's quite useless for all kinds of calculations involving decimal
numbers in the financial industry.
> 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.
The same problem comes here if you want to use eg 6 or 8 or go even
higher for temporary results and the truncate.
> Thus 10 years ago in my financial-employment days, I would have
> "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."
But even with 64bit and 32bit integers it would be nice to have a
standard way of dealing with them as the integer and a scale.
template<typename integral_t, typename scale_t>
with all ops and constructors as one would expect for for a numeric
Both Scale_t and Integral_t would be integral types representing the
scale and the integral part of the decimal. The Integral_t could be a
BCD type for arbitrary precision. And for 64-bit you could declare
number<long long, char>.
> 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
> set. If you were to write a BCD library for Boost and
> that BCD library were adopted as part of some C++ standard, I would
> expect a commercial x86-based implementation of this then-
> BCD library to be written in x86 assembly. As an effort reduction,
> would expect that the Boost library be written in portable C++ for
> foreseeable future, despite probably being notably slower.
Yepp actually BCD could be implemented in hardware as well if it
becomes standard and then it would be noticably further. Buth
software versions of BCD perfroms in 10 or 100 orders of magnitudes
slower than IEEE floats. Se http://www2.hursley.ibm.com/decimal/ for
a good deal of information about arbitrary precision decimal
arithmetic and even an ANSI C implementetation of arbitrary precision
decimal arithmetic (but under a severely restricted IBM alphaWorks
license which says that i must delete the source code for the library
after 90 days).
> Also fixed-point (nonBCD) representations might be very useful on
> fixed-point digital-signal processors. Indeed, DSP instructions on
> 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-
> fixed-point arithmetic & number representations. They seem as
> they are for drastically different purposes---finance versus
> engineering---and drastically different guts---base-10 in nybbles
> versus base-2 in bits.
With correct rounding rules fixed point (binary rep) can be quite
useful in finance as well in some cases where such as the cas you
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk