HP-65 accuracy error

[Don Shepherd]

Everyone who uses the HP-65 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.

[toml_12953]

(12-16-2019 04:51 PM)Don Shepherd Wrote:  Everyone who uses the HP-65 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.

I think that 45 years after its introduction, most people know by now!

[Don Shepherd]

(12-16-2019 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.

[TomC]

If I recall correctly, the early marketing literature of the HP21/25 mentioned the improvement of exponentiation functions. (or later?)

TomC

(12-16-2019 05:44 PM)Don Shepherd Wrote:  

(12-16-2019 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.

[teenix]

(12-16-2019 04:51 PM)Don Shepherd Wrote:  Everyone who uses the HP-65 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.

Common with all the classics and HP21.

cheers

Tony

[Gene]

Article was titled something like "The new accuracy - making 2^3 = 8"

[Jake Schwartz]

(12-16-2019 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 Hewlett-Packard Journal from November 1976, with the cover story being the HP-67/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

[SlideRule]

(12-16-2019 05:44 PM)Don Shepherd Wrote:  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.

Don
Any hints as to the identity of the the 65 program (my curiosity)?
SlideRule

[Don Shepherd]

(12-16-2019 09:48 PM)SlideRule Wrote:  Any hints as to the identity of the the 65 program (my curiosity)?
SlideRule

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 2-digit numbers representing letters of your message. The encryption results in a big base 10 number from the 5 2-digit numbers in base 40, and entering E decrypts the big base 10 number back into the original 2-digit base 40 numbers. Except it doesn't give you the same 2-digit 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

[n1msr]

Well, I am one of the people who had an HP-65 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.

[John Garza (3665)]

Also, I don't think the error was a huge problem back then. The 65 was not that far removed from the slide-rule days. The old slip-stick 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 SR-50 (HP-35 competitor) gets the right answers for those problems.

-J

[Steve Simpkin]

(02-22-2024 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 slide-rule days. The old slip-stick jockeys you have known to use logs and multiply.

But it is worth noting the TI algorithms back then were more accurate in general.
Even an SR-50 (HP-35 competitor) gets the right answers for those problems.

-J

William Kahan had a bit to say about the "increased accuracy" of TI models when he worked as a consultant for HP.

"Hewlett-Packard had come out with a beautifully engineered job called the HP-35, 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 HP-45, 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 full-page advertisement. It said, “Type in your telephone number. Now,” they said, “Take the logarithm.” The logarithm turns out to be a number form ten-point-something, or nine-pointsomething, 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
HP-45, which carried ten digits. You type in your ten-digit 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 HP-35, for all its faults—and it had lots. It was really a very nice job, and then, of course, it went to the HP-45, which was just sort of an expanded, extended version of the HP-35. 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 HP-45, and I had an SR51. And I discovered what was happening. It’s true that the HP-45’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 Hewlett-Packard 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 four-something 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

[John Garza (3665)]

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

[rprosperi]

Sometimes????

[Thomas Klemm]

This program for the HP-65 can be used for generic base conversions and therefore also between 40 and 100: Base Conversion for HP-65