|Re: The chip makers "corrected it" years ago|
Message #12 Posted by Fred Lusk (CA) on 15 Dec 2002, 3:00 p.m.,
in response to message #11 by Dave Hicks
Thanks for your reply. My argument is not BCD vs floating point math. Frankly, as a user, I am more interested in an accurate and precise result than how the machine actually comes up with it. A CPU housing a fast-fingered chimp with an HP-42S would be enough for me!
My argument is that regardless of the method used to make a calculation, the CPU has not finished its job if it returns 5x10^-15 for zero. I am looking at this from the standpoint of the user, not computer science. The user has the right to expect the correct result, and with vast number of unsophisticated computer users out there, it is even more important. Even with floating point math, it should be very easy to count the number of decimal places going in so the result can be reported properly coming out. Floating point or not, we can't deny that a subtraction problem done with numbers having only two decimal places must return a result with only two decimal places. That's the reality of arithmetic. Even though numbers in the scientific/engineering world often have a tolerance, most of us properly use numbers as exact in the arithmetical sense, not with a +/- after them. I would rather the computer return the arithmetically correct result and let me worry about the tolerances.
I first ran across this problem in a practical way about twelve years ago. Back in the days when this was all my 386 could handle, I built a 1.8 MB spreadsheet to calculate an assessment spread (this is where we take the cost of a construction project and prorate it to the benefiting lots-650 in this case-in proportion to the benefit). The spreadsheet dealt only with dollars and cents and used only addition, subtraction, multiplication, and division. Although some of the division problems did result in fractional pennies, all critical amounts were rounded to the nearest penny. Part of this spreadsheet took data on cash payments from the property owners collected by the County and compared it to my own calculation. I set up an error-check column to ensure that the County hadn't messed up the Q&A data base I made for them. I hadn't included any round-offs here because all three numbers that went into each error-check calculation had been previously rounded to two decimal places or had been directly input to two decimal places. The result of all 650 calculations was supposed to be zero. Imagine my surprise when one of them wasn't. I had long since forgotten the finer points of floating point calculations. As a civil engineer, it is not something I deal with every day. In any event, it took a few minutes for me to find the one offending calculation and several hours to determine that nothing bad had actually happened to either my spreadsheet or the data from the County.
Over the years I have tested many similar equations to the one I posted. Most produce the correct results, but many do produce the spurrious digits. I have also tested this on many of the programs I have used. The only two that ever got the correct answer was Q&A 4.0 (which was programmed to use only 7 or 8 decimal places) and Word for Windows 1.0.
In spite of the protests of those who know a lot more about computers than I do (and I know a fair amount for not being in the field), I still maintain that this spurrious digits problem is a real problem, an easily fixable problem, and the responsibility of the chip makers and/or the programmers. My first vote, though, is that this should be corrected at the CPU level. It should never be an issue to the user.
On another note: this is one of my two favorite hangouts on the Internet (the other being Astromart) and I appreciate what you have done for the HP community here. Happy Holidays.