Best HP Financial Calculator

[Dave Britten]

(05-05-2015 11:22 PM)TASP Wrote:  Don't mean to derail the topic, but with really enormous numbers being used in the government and media in descriptions of large financial deals and policies, is there a need behind the scenes for the actual 'bean counters' to have access to machines with greater precision than we typically see with our HPs ??

Would 20 digit precision be sufficient (assuming accurate algorithms coded into the machine) for computing the debits and credits of a really large pension system, perhaps handling 10s of trillions coming in and going out over the next 30 to 50 years ??

Or do even the most conservative and OCD of the bean counters find 10 digits and scientific notation sufficiently accurate for noodling out such enormous sums ??

You raise an interesting point. Anecdote time.

We used to have this really old "report" program at work. It was just a simple Delphi program, written well before my hire date, that could run text files containing a report definition (really no more than a title, an ODBC data source name, and an SQL query), and dump the reports to Excel, slowly, via COM. We had a ton of reports for this thing, and it was used by sales, purchasing, accounting, management, etc.

One of the accounting reports would simply list all the AP checks from our ERP system. The AP head would run this periodically - monthly, I think - and upload this list to the bank, as a means of fraud detection. (i.e. do our cleared checks match the ones we think we wrote?)

This had been used for a number of years, but one day, it was suddenly off by about 2-3¢. And yet running the SQL query manually produced the correct results. We quickly isolated a single check in the output that was showing the wrong total when run with our reporter. The question of why still remained, though.

Miraculously, I was able to dig up the source code for the report tool in some alcove of our IT file share. Perhaps just as miraculously, I also managed to find the installation media for the version of Delphi it was built in. (Delphi was already pretty dated even when this happened around 2007, and this was written in some old version like Delphi 4.) So I cracked open the code that handled dumping the results to Excel, and found a case statement that would deposit cell values into Excel based on the data type of the column retrieved from the query. And wouldn't you know it, the tool was retrieving the value into a single-precision float variable!

This was apparently the largest AP check we had ever written since we started using this particular report; I don't remember the exact amount, but it was large enough to overflow the precison of a single, and Delphi happily rounded the result by a few cents. After a quick code change to replace the variable with something like a double or fixed-point decimal, our list of checks matched, and we all hoped we'd never have to touch the source code of that warty little thing again.

So your concern is not limited to the realm of incomprehensibly obscene amounts of money.

(I think we ended up having to fix at least one other small problem with that reporter, though damned if I can remember what it was.)