Re: BCD and/or Fixed point decimal classes

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 
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.)

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.

> 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 
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."

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 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 
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.

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 
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.

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