
Boost : 
From: Paul A. Bristow (boost_at_[hidden])
Date: 20020308 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 64bit integers will do?
Paul
Dr Paul A Bristow, hetp Chromatography
Prizet Farmhouse
Kendal, Cumbria
LA8 8AB UK
+44 1539 561830
Mobile +44 7714 33 02 04
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 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.
>
>
> Info: http://www.boost.org Send unsubscribe requests to:
> <mailto:boostunsubscribe_at_[hidden]>
>
> Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
>
>
>
>
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk