HP65 accuracy error

12162019, 04:51 PM
Post: #1




HP65 accuracy error
Everyone who uses the HP65 needs to be aware of the known accuracy error in the y^x function for larger values.
10 ENTER 6 Y^X yields 1000000 as expected 10 ENTER 7 Y^X yields 9999999.99 10 ENTER 8 Y^X yields 99999999.60 the error gets greater the larger you go. Just be aware. 

12162019, 05:26 PM
Post: #2




RE: HP65 accuracy error
(12162019 04:51 PM)Don Shepherd Wrote: Everyone who uses the HP65 needs to be aware of the known accuracy error in the y^x function for larger values. I think that 45 years after its introduction, most people know by now! Tom L Cui bono? 

12162019, 05:44 PM
Post: #3




RE: HP65 accuracy error
(12162019 05:26 PM)toml_12953 Wrote: I think that 45 years after its introduction, most people know by now! Yeah, those who have collected and used and programmed the 65 probably do, but I've seen some people here on the forum who are restoring and newly acquiring the 65, and they may not know this. I mention it because last night I entered a new 65 program and it didn't give the expected results, and I traced it down to this y^x accuracy error. 

12162019, 06:38 PM
Post: #4




RE: HP65 accuracy error
If I recall correctly, the early marketing literature of the HP21/25 mentioned the improvement of exponentiation functions. (or later?)
TomC (12162019 05:44 PM)Don Shepherd Wrote:(12162019 05:26 PM)toml_12953 Wrote: I think that 45 years after its introduction, most people know by now! 

12162019, 06:53 PM
Post: #5




RE: HP65 accuracy error
(12162019 04:51 PM)Don Shepherd Wrote: Everyone who uses the HP65 needs to be aware of the known accuracy error in the y^x function for larger values. Common with all the classics and HP21. cheers Tony 

12162019, 07:10 PM
Post: #6




RE: HP65 accuracy error
Article was titled something like "The new accuracy  making 2^3 = 8"


12162019, 08:55 PM
Post: #7




RE: HP65 accuracy error
(12162019 07:10 PM)Gene Wrote: Article was titled something like "The new accuracy  making 2^3 = 8" That article, "The New Accuracy: Making 2^3 = 8", written by Dennis Harms, appeared on page 16 of the HewlettPackard Journal from November 1976, with the cover story being the HP67/97. At the end, Dennis acknowledges Dave Cochran, Professor William Kahn and Bill Egbert. For those keeping score at home, Dave Cochran spoke at the HHC2018 conference in San Jose, William Kahn spoke at the original HP conference in 1979 in Santa Clara and Bill Egbert spoke at the 1981 conference in Corvallis, Oregon, where he presented the Saturn CPU to the public for the first time. Jake 

12162019, 09:48 PM
Post: #8




RE: HP65 accuracy error  
12162019, 11:02 PM
(This post was last modified: 12172019 11:55 PM by Don Shepherd.)
Post: #9




RE: HP65 accuracy error
(12162019 09:48 PM)SlideRule Wrote: Any hints as to the identity of the the 65 program (my curiosity)?Yes, it's a little encryption/decryption program I adapted for the 65 from a version I wrote for the 12c. For the 65, you press A to display no decimals, then press E to encrypt five 2digit numbers representing letters of your message. The encryption results in a big base 10 number from the 5 2digit numbers in base 40, and entering E decrypts the big base 10 number back into the original 2digit base 40 numbers. Except it doesn't give you the same 2digit numbers you started with because of the Y^X error. The 12c version of this program works fine. updated on Dec. 17, 2019  I modified the program below to remove the two Y^X operations and just used regular multiplication to adjust the multipliers in each loop instead of the Y^X operations, and now the program works fine. If anyone is interested, I'll post the new code. It's good to know that there is a relatively easy workaround for this problem. Here is the 65 version that does not work correctly (lowercase for ease of entry): lbl a dsp . 0 rtn lbl d (decode) sto 1 0 sto 2 sto 3 lbl 2 rcl 1 40 / sto 4 lst x x<>y frac x 10 rcl 3 y^x generates the wrong number x sto + 2 rcl 4 int sto 1 0 x=y goto 3 2 sto + 3 goto 2 lbl 3 rcl 2 rtn lbl e (encode) sto 1 0 sto 2 sto 3 lbl 1 rcl 1 100 / int sto 1 lst x frac 100 x 40 rcl 2 y^x x sto + 3 1 sto + 2 4 rcl 2 x<=y goto 1 rcl 3 rtn 

02222024, 01:43 PM
(This post was last modified: 02222024 01:45 PM by n1msr.)
Post: #10




RE: HP65 accuracy error
Well, I am one of the people who had an HP65 restored recently (in 2023 after owning it for almost 30 years  it was a freebee back then).
I was caught out by this [in]accuracy quirk. On my 67 I have been able to use the 10^x function to help store/shift digits around in a register. I can multiply (or divide) by 10 explicitly to move a digit on the 65, but that seems cumbersome. Interesting! But glad this post is here to confirm this 65 "feature" :) PS: the thing I find odd is that the 65 executes faster than the 67. Except I now have a teenix.org board in the 67, which has a turbo mode, so the 67 can be faster. 

02222024, 03:06 PM
(This post was last modified: 02222024 11:50 PM by John Garza (3665).)
Post: #11




RE: HP65 accuracy error
Also, I don't think the error was a huge problem back then. The 65 was not that far removed from the sliderule days. The old slipstick jockeys would have known to use logs and multiply.
But it is worth noting the TI algorithms back then were more accurate in general. Even an SR50 (HP35 competitor) gets the right answers for those problems. J 

02222024, 07:14 PM
Post: #12




RE: HP65 accuracy error
(02222024 03:06 PM)John Garza (3665) Wrote: Also, I don't think the error was a huge problem back then. The 65 was not that far removed from the sliderule days. The old slipstick jockeys you have known to use logs and multiply. William Kahan had a bit to say about the "increased accuracy" of TI models when he worked as a consultant for HP. "HewlettPackard had come out with a beautifully engineered job called the HP35, which was the first scientific calculator with all the scientific functions instead of just the add, subtract, multiply, divide, and maybe a square root. And then they came out with the HP45, which was an improved version. It had more functionality. But in the meantime, Texas Instruments came out with a calculator that was a great deal cheaper, and here’s how they advertised their calculator. So TI had this advertisement in the papers. It was a fullpage advertisement. It said, “Type in your telephone number. Now,” they said, “Take the logarithm.” The logarithm turns out to be a number form tenpointsomething, or ninepointsomething, actually. “Now hit the exponential key. Do you get your phone number back? You do on our calculator.” HP knew that it was the target of this advertisement because it did that on an HP45, which carried ten digits. You type in your tendigit phone number, take the log, take the exponential, and the last digit or two would change but, apparently, not on the TI calculator. HP was very worried about this, because it seemed to impugn the integrity of their beast. It was a very neat job, the HP35, for all its faults—and it had lots. It was really a very nice job, and then, of course, it went to the HP45, which was just sort of an expanded, extended version of the HP35. And the other guys were getting into the act. What one fool can do, another can, so TI had gotten into the act using relatively similar algorithms.And HP was now embarrassed because it appeared that their calculator was somehow defective, and they were worried about it—I mean, really worried about it. They thought they had a certain reputation, and it was being undermined by this calculator. So fortunately, I asked what the problem was all about, and I said, “Can you send me samples of the calculators for me to play with before I come to the meeting?” And they did. So I had an HP45, and I had an SR51. And I discovered what was happening. It’s true that the HP45’s arithmetic was somewhat grotty in spots, but it wasn’t that bad. But what TI was doing was clever. You see, the 45 did its arithmetic to ten significant decimals, period. Everything was done to ten significant decimals, including the internal algorithms that computer logs and exponentials. TI was doing their arithmetic internally carrying 13 significant decimals, but they only showed you ten. So that meant that, though you type ten digits in, as soon as you did some arithmetic, you had 13 decimal digits. But you only saw ten significant decimals. Well, that could hide a lot of sins, couldn’t it? The TI thing was cheaper, but that’s because HewlettPackard can’t do anything that’s cheap there. Their whole culture is such that, whatever they do, it’s going to be expensive. So I discovered that if you did this log exponential thing seven times, then the last digit would change. You see, their arithmetic at the 13th digit was grottier, if anything could be grottier, than the 45. And because it was worse arithmetic intrinsically, it meant that it didn’t take very long for the error to creep up through those three digits. Seven times was enough. So I then was able to turn up and say, “Look: everybody who looks at that ad is being fooled. They think that the TI machine is reproducing your telephone number, but it isn’t. It’s your telephone number with a last digit diminished by one, followed by a certain number of nines, like two nines and a digit. Then it gets rounded up, you see, so it shows up properly in the display. They round in the display, even though they don’t round the arithmetic.” I said, “You do this seven times, and then you’re going to get something with your digit, less one, and followed by a foursomething something because the arithmetic is so crummy. After you’ve done it seven times, your telephone number changes. Do you feel that that’s honest? Is this an honest ad?” Well, certainly it’s got to be mysterious. Somebody who doesn’t realize what’s going on has to find it mysterious that after he does this seven times, that digit changes. That was a shock, and now they realized that they were in a world that was not the world they thought they were in. Whatever the hell was going on, they really weren’t in control of it, but I also came with a proposal to cure the problem. I said, “You can do what they do, except for one thing: in order to be honest, round every result back to ten digits even if you carry thirteen to compute it.” And I said, “If you do that, then each operation, taken by itself, will give you a rather honest answer, and you can explain this log exponential thing. That’s easy because when you take the log, you’ve got the right log. It’s correct to within just a little bit worse than half a unit in the last digit of the display. Then you can say ‘Now, it’s that error that propagates when you take the exponential because, if we recovered your telephone number, we’d be getting the exponential not of the number that you see before you. It would have to be the exponential of something else." This is discussed starting around page 144 on the following interview. https://drive.google.com/file/d/1Jlg9EWQ...KigpIzwcol 

02222024, 11:54 PM
(This post was last modified: 02222024 11:58 PM by John Garza (3665).)
Post: #13




RE: HP65 accuracy error
Yep, the 'Guard Digits' as they are called in TI machines are well known. Even explained in the manuals. A simple way to get more accuracy. Though very few people will need 10 digit accuracy for anything.
And... dare I say it... marketing wars can sometimes skirt the line of honesty! J 

02232024, 03:19 AM
Post: #14




RE: HP65 accuracy error
Sometimes????
Bob Prosperi 

02232024, 04:28 AM
(This post was last modified: 02242024 03:29 AM by Thomas Klemm.)
Post: #15




RE: HP65 accuracy error
This program for the HP65 can be used for generic base conversions and therefore also between 40 and 100: Base Conversion for HP65


« Next Oldest  Next Newest »

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