Post Reply 
Accuracy Management of early HPs
09-12-2022, 12:07 AM
Post: #11
RE: Accuracy Management of early HPs
(09-11-2022 08:44 PM)Matt Agajanian Wrote:  Hi all.
Lets me just say.
I feel this thread I started does have some relevance. For example, the 12C has been a mandatory part of a financier, banker, and accountant’s equipment.
In their world, they’ll probably encounter figures in the millions or in the extreme, billions. So, I would think accuracy their first concern. I could only guess if figures in the trillions cross a financial pro's situations. Well then, accuracy must be their primary point of interest (pun intended). At least results or variables should be of the utmost accuracy.
So, whatever range of monies any financial pro requires, I
would presume they would put top importance on the accuracy in calculations from the 12C or other calculators.

That dovetails nicely into the second half of the improved accuracy algorithms for scientific calculations that Dr Kahan developed for HP and that were first used in the HP-27. As it turns out, he discovered problems with the financial calculations used in the HP-27 (and earlier financial models) that led to the internal recall of the HP-27 before the first one was even sold.

KAHAN:
"The first calculator that was doing what I said they should do was the HP-27, and they sent me a
prototype that I could play with to see whether things were working out the way I said. Things
were working out the way I said they would. The functions really did look a lot better. In fact,
Dennis Harms actually wrote a little paper, I think, that got published in The HP Journal
somewhere. But I was puzzled because on the top row of the calculator’s keyboard, they had
these five keys: n, i, pv, pmt, and fe. I said, “And what do they do?” “Oh,” they said, “you don’t
have to know that.” It was on a need-to-know basis, you see. So I looked at these things, and I
finally figured out what they were doing. These for calculating the relationship among the
interest rate, the initial loan value, a regular payment, like payment on a mortgage—the balloon
payment, and the number of payments all totaled. That’s what it was supposed to do. It didn’t
take me long to figure that out. I mean, after all, I had attended an actuarial science course in
which such things were discussed, even if I had read in the back of the class. Then I said, “You
know, if they’re going to compute the interest rate, that’s a non-trivial computation. I wonder if
they can get it right.” And, of course, they couldn’t. So there were cases where I could see that,
although it’s a ten-figure calculator, they’ve only got six figures correct of the interest rate. It
didn’t take me long to find that.
And I phoned my contact at Hewlett-Packard. I said, “Listen, I figured out what you’re doing
here, but I’ve got to tell you, you’re losing digits. I’ve got this very simple example. It took me
only a few moments to construct, and your interest rate is good to only six figures.” And the guy
said, “Well, that’s okay; all we need is six figures.” I said, “Look, you’re going to lose more.” I
found an example, and I called him up, and I said, “Look, here’s an example where you’ve lost
all but four of your figures, and if you want to give me longer, I’ll find some where you lose
them all.” But the fact that he had only four figures correct, that started to worry him. And I
could hear the tone of his voice change—there were pauses. Then I said, “But you know, there is
a way to do this that’ll get it right. And furthermore, it will liberate you from one of the
constraints that you’ve put on the input data I see. That’s an unnecessary constraint.” And I
described the algorithm to him, and then I sent him something.
Yes, he microcoded it up, and he found the calculator worked faster for these interest rate
calculations. The answer was just fine, right out to the last digit. And it didn’t have this
unnecessary restriction, and everything about this was just marvelous except for one thing: they
already had a warehouse full of these calculators in cartons with their manuals, ready to hit the
Christmas market. What should they do? I was invited to a meeting, and David Packard was at
the head of the table of this meeting. I didn’t have much to say. I didn’t have to because my
views were being represented by one of these guys who said, “Our consultant found a bug. The
bug appears to be serious. We found a way to repair the bug; the consultant provided that. All we
have to do is replace ROMs. Unfortunately, that means we have to unsolder the old ROMs and
solder new ROMs in. You can’t just do a plug-in, but we’ve got tools for doing that. What are we
going to do with the thousands of boxes? Should we put them out on the market and insert a little
slip into each one saying, ‘Sorry, there’s a little glitch, and if you send your calculator back,
we’ll fix it’?”And David Packard said, “No, we’re not going to sell a defective product. It’s one thing to put
them out on the market when we didn’t know there was a defect, and then later we have to chase
down people. It’s something else to sell something when we know it’s defective.” And he said,
“We will withdraw the calculators from the warehouse. We’ll make the necessary fix, change the
ROMs, and so on. So we won’t make the Christmas market. We’ll have to go for the Easter
market,” so to speak, or some other subsequent market. That shot my respect for David Packard
up several notches. Now I knew he was a good guy. I knew he was technically competent. I
knew that he ran a company based on what I would have to call humane principles. It wasn’t just
good business. It was broadly humane. But he didn’t delay in that decision. It wasn’t as if it was
an agonizing decision. It was clearly the proper decision. He made it there in my hearing, and I
have to tell this story because there aren’t very many people who know it. And if you wonder
why David Packard had earned the respect of so many of the people who knew him, this is
another one of those stories. But in the meantime, I was in. From now on, I was participating in
these calculators. That was all being done down in Cupertino. The next big task was going to be
the HP-92."


The improved financial calculation algorithms that Dr. Kahan developed for the HP-27 and HP-92 were carried on into the HP-12C and are still in use today, many decades later. They are one of the reasons the HP-12C is considered a de facto standard when it comes to TVM calculations.

Here is an alternate link to the interview with Dr Kahan:
Interview with Dr. William Kahan - August 2005
Visit this user's website Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
RE: Accuracy Management of early HPs - Steve Simpkin - 09-12-2022 12:07 AM



User(s) browsing this thread: 1 Guest(s)