RE: [boost] Re: BCD and/or Fixed point decimal classes

From: Paul A. Bristow (boost_at_[hidden])
Date: 2002-03-08 06:34:35

Enron shows graphically that accountants know the price of everything to the
nearest cent, but the value of nothing! (Apologies to Oscar Wilde.)  They
NEED to use floating point, and include uncertainty in their calculations.
But I doubt they will. Meanwhile surely 64-bit integers will do?

Paul

Dr Paul A Bristow, hetp Chromatography
Prizet Farmhouse
Kendal, Cumbria
LA8 8AB      UK
[phone]
Mobile [phone]
mailto:pbristow_at_[hidden]

> -----Original Message-----
> From: danl_miller [mailto:danl_miller_at_[hidden]]
> Sent: Thursday, March 07, 2002 3:22 AM
> To: boost_at_[hidden]
> Subject: [boost] Re: BCD and/or Fixed point decimal classes
>
>
> --- 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.
>
>
> Info: http://www.boost.org  Send unsubscribe requests to:
> <mailto:boost-unsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>