
Boost : 
From: p_michel_andre (michel.andre_at_[hidden])
Date: 20020307 03:30:10
 In boost_at_y..., "danl_miller" <danl_miller_at_b...> wrote:
> 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.)
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
would excpect.
> Floatingpoint 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.
> 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.
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 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."
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.
Something like.
template<typename integral_t, typename scale_t>
struct number
{
private:
scale_t scale_;
integral_t integral_;
}
with all ops and constructors as one would expect for for a numeric
type.
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 64bit 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
> 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 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.
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 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 arbitrary
precision
> 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.
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
mention above.
/Michel
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk