Accountants, Finance, Language

[Geoff Kuenning]

In article <62 at vax2.fluke.UUCP> kurt at fluke.UUCP (Kurt Guntheroth) writes:

>This bogus BCD thing crops up again and again.  It poisoned the ANSI BASIC
>standard too.  Won't you guys examine the NEEDS of financial people?

If you think BCD is bogus, maybe you ought to be asking the financial
people why they still use it.  Address your question to the PhD's at TJ Watson
Research Center, not to your average COBOL programmer.

>Financial people want dollars and cents calculations that come out exact.
>The first thing that seems to come into people's minds when they hear ths is
>BCD floating point.

Wrong.  The first thing that comes to the mind of any person who has even
limited financial experience is BCD _f_i_x_e_d point.  I don't think I've seen
hardware floating point support for BCD numbers since I left the good old
1620.

>BCD floating point is wasteful and slow and is probably not the best answer.

Why is it wasteful?  As to speed, the speed of (hardware) BCD floating point
is comparable to the speed of (hardware) BCD fixed point.

>Floating point will represent numbers that are both larger and smaller than
>financial people need, and doing exact calculations
>in floating point can lead to problems in roundoff, truncation, and so
>forth, even if the number is kept in BCD.

This demonstrates enough ignorance of numerical floating point problems
that I wrote three paragraphs rebutting it before I decided I was cluttering
the net.  If anybody is interested, mail me (including the above quote).

>What financial people 'need' is a fixed point representation.  Fixed point
>numbers are like integers, only you get shifting of the product in a
>multiplication or the quotient in a division to make the decimal point line
>up in the right bit position.  You get EXACT results, and an out-of-range
>number causes a very conventional integer over/underflow.  Fixed point
>numbers can be manipulated in binary so they are optimally fast and densely
>encoded.  Any architecture which handles integers can handle them.

I have news for you.  Why do you think BCD machines (like the 370) have BCD
shift instructions?  The financial people are almost the only ones in
computers who understand fixed point representations thoroughly, in both
binary and BCD.

What the financial community _d_o_e_s_n_'_t 'need' is a bunch of know-it-alls who
give advice without (a) knowing enough about the problem to give meaningful
advice and (b) researching what the financial people have found out over
the last 30 years.  I hate to break it to you, but as was pointed out on the
net a week and a half ago, the financial people have heard of binary, and long
ago.  They use it when it's appropriate.  They don't when it's not.

>Now, will all the financial people on usenet who use C for their programming
>please raise their hand?  Hmmmm.  That's what I thought, not enough to make
>the effort of adding a new data type worth the trouble.  Now can we get on
>to something else?

It is true that not many people do financial programming in C.  (It may
interest you to know that _m_y financial code is written in 'awk', and it works
quite well, thank you, though I keep dollars and pennies separate to avoid
precision problems).  However, there are more reasons than financial
programming to put in a new data type.  The original article was pointing
out that BCD is the optimum representation for a lot of types (a point
which has yet to be successfully rebutted by the know-it-alls) and such a
type might be useful in C.  Contrary to popular belief, the financial
community has developed one or two things that have found their way into what
egotists would like to think is "mainstream" computer science.  When I got
my degree, database was a joke.  It certainly isn't today.

A lot of modern databases (e.g., Ingres, Unify) are written in C.  And they
have to manipulate financial data types in an efficient representation.  A
BCD type (or at least a standard BCD subroutine package) would help them a lot.
-- 

	Geoff Kuenning
	...!ihnp4!trwrb!desint!geoff