kurt@fluke.UUCP (Kurt Guntheroth) (11/21/84)
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?
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. BCD floating point is wasteful and slow and is probably
not the best answer. 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.
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.
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?
--
Kurt Guntheroth
John Fluke Mfg. Co., Inc.
{uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!kurtlarry@extel.UUCP (11/28/84)
Here! Here! I think you hit the nail on the head. I am working on some accounting type packages and fixed point or even 64 bit integers would work nicely. Larry Pajakowski ihnp4!tallab1!extel!larry
geoff@desint.UUCP (Geoff Kuenning) (11/30/84)
In article <62@vax2.fluke.UUCP> kurt@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
gino@voder.UUCP (Gino Bloch) (11/30/84)
<this line might be missing> > 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 > -- > Kurt Guntheroth > John Fluke Mfg. Co., Inc. > {uw-beaver,decvax!microsof,ucbvax!lbl-csam,allegra,ssc-vax}!fluke!kurt Two of my friends and I want to divide $100.00 equally ... -- Gene E. Bloch (...!nsc!voder!gino)
henry@utzoo.UUCP (Henry Spencer) (12/03/84)
> ... 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. You mean, they use it when their preconceptions say it's appropriate, and scorn it when their preconceptions say it's not. Last I heard, business types using the big Burroughs machines don't seem to mind that there is no BCD on the machine at all, and their COBOL compilers are doing all the arithmetic in binary. > ... 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. The original article was *claiming* that BCD is the optimum representation; most of us think the case made for it is so poor that it's hardly worth trying to rebut. There are many things that might be useful in C. Far too many. > 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. So what does this have to do with BCD? When I got *my* degrees, BCD was a joke. It still is. > 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. A standard extended-precision-integer package would probably suffice, and whether it used BCD or binary representation would be (and should be!) an irrelevant implementation decision. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
ka@cbosgd.UUCP (Kenneth Almquist) (12/06/84)
One additional point: not all machines have hardware support for BCD arithmetic. As it stands, the C language can be implemented *efficiently* on a reasonably large number of machines. Kenneth Almquist
geoff@desint.UUCP (Geoff Kuenning) (12/08/84)
In article <554@cbosgd.UUCP> ka@hou3c.UUCP (Kenneth Almquist) writes: >One additional point: not all machines have hardware support for BCD >arithmetic. As it stands, the C language can be implemented *efficiently* >on a reasonably large number of machines. The 68000 doesn't have floating point... -- Geoff Kuenning ...!ihnp4!trwrb!desint!geoff