Which HP calculator had "The New Accuracy" first?

[Jonathan Busby]

I'm kinda out-of-the-loop on pre-Saturn HP Calculators, but I do believe that the HP-71B was the first to implement the IEEE Std 854-1987 radix-independent floating point standard.

Also, according to this page, William Kahan made many contributions to the floating point algorithms used on HP Calculators, although I'm not sure if any used the Kahan summation algorithm.

Kind of off-topic, but I'd like to see an RPN and/or RPL calculator that uses DEC64 which seems to have all the advantages of binary floating point's extended significand and exponent range while still retaining BCD / decimal floating point's accuracy and is also faster than both for good measure

Regards,

Jonathan

[Andres]

I think it has been said already, but just in case... The HP=25 needed to allocate ROM space for programmable functions, but the HP-22 and the HP-27 were not programmable, so there was more ROM space available to put more sophisticated code for these math functions in these models. While the HP-21 was not programmable indeed, it has no memory (apart from ACT registers) and I guess its ROM space was also limited. By the time HP-29C, 19C, 91, 67, 97 appeared, more ROM space was available and the improved routines became standard.

[aurelio]

(06-22-2020 01:53 PM)EdS2 Wrote:  

(06-22-2020 12:04 PM)aurelio Wrote:  Don't worry Joe, +1 even if I'm just a bit younger...

Yes, me too, and I'm not 60 yet.

I just tried the 29C in emulation and was surprised to see a different answer - was there another change in HP's arithmetic?

Here are my results:
HP-25: -9.99E-08 (same as emulated HP-35 with V4 ROM)

HP-67: 1E-09 (microcode emulation)
HP 29C: 1E-09 (microcode emulation)


HP 35s: zero
HP 30b: zero
HP-15C LE: zero

(I think the LE uses the same algorithms as the original 15C)

on the real I get
HP-35 (V2, V3,V4) -9.95E-08
HP-29c 1.00E-09
HP-25c -9.95E-08
HP 42s: zero

performing 1/X *

[EdS2]

(06-23-2020 06:15 PM)aurelio Wrote:  performing 1/X *

Hmm, interesting: why did you choose not to divide directly?

[aurelio]

(06-24-2020 07:28 AM)EdS2 Wrote:  

(06-23-2020 06:15 PM)aurelio Wrote:  performing 1/X *

Hmm, interesting: why did you choose not to divide directly?

I would try with a step more what changes and compare to see the difference, so I decided to enter first the denominator, the difference is noticeable just for the 25 and the 35 (with FIX09)

[Nihotte(lma)]

(06-22-2020 04:59 PM)Nihotte(lma) Wrote:  I've tested on my HP10bII+, too

729^33.5 / 3^201 -1
--> gives 0 [ with 729^33.5 ÷ ( 3^201 ) - 1 = ]

But, LN 729 x 33.5 ÷ ( LN 3 x 201 ) - 1 = gives -5E-12 (and curiously 1.00000000 in DISP . mode before applying - 1 = )

If i try it on the less recent hp35s and hp12c+ (in RPN mode this time) it gives the same results by using the LN function. Otherwise, on the hp35s with the LOG available function, the result is 0 !!

[Valentin Albillo]

(06-24-2020 12:51 PM)Nihotte(lma) Wrote:  If i try it on the less recent hp35s and hp12c+ (in RPN mode this time) it gives the same results by using the LN function. Otherwise, on the hp35s with the LOG available function, the result is 0 !!

In a number of HP calcs LOG seems to be more accurate than LN, for instance in the HP-15C that's frequently the case. Perhaps it has to do with BCD and LOG being Log₁₀.

V.

[Jim Horn]

(06-22-2020 01:07 AM)Joe Horn Wrote:  Oops! You're quite right. Let's call it a typo (even though it was more accurately a braino).

"And away go troubles, down the brain!" Not *quite* Roto-Rooter's tag line...

Jim (Older than Joe)

[brouhaha]

(06-24-2020 05:35 PM)Valentin Albillo Wrote:  

(06-24-2020 12:51 PM)Nihotte(lma) Wrote:  If i try it on the less recent hp35s and hp12c+ (in RPN mode this time) it gives the same results by using the LN function. Otherwise, on the hp35s with the LOG available function, the result is 0 !!

In a number of HP calcs LOG seems to be more accurate than LN, for instance in the HP-15C that's frequently the case. Perhaps it has to do with BCD and LOG being Log₁₀.

I haven't studied the internal operations of HP's log and exponential functions in depth (even though I've transplanted them into modified 16C microcode), but I suspect the reason could be that argument range reduction for log10 is easy to do in base 10, while argument range reduction for ln would be much more difficult to do accurately in base 10.

The Briggs algorithm as used in the calculators covers a very limited domain, so logarithm arguments above the upper limit of the domain have to be divided by a big enough power n of the base of the logarithm to get them into the domain. After Briggs' algorithm is performed, the value n is added to the result. For base 10 on a BCD calculator, the reduction is simply using the exponent of the argument as n, and clearing the exponent.

Similarly, for 10^x on a BCD calculator, range reduction can be done by setting aside the integer portion of the argument as n, feeding the fractional part into the Briggs exponential routine, then adding n to the exponent of the result.

It would therefore make sense in a calculator to implement natural logs and exponentials as wrappers around common logs and exponentials, rather than vice versa. I can't say with any certainty that this is what's actually going on in the HP calculators.

The same reasoning is why some log and exp implementations on binary systems, in both software and hardware, implement both natural and common log/exp in terms of base 2 log/exp.

[Steve Simpkin]

William Kahan mentions that the improved accuracy algorithms for scientific calculations that he developed for HP were first used in the HP-27 (publicly introduced around May 1976).

"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."

This is discussed starting around page 144 on the following interview.
Interview with Dr. William Kahan - August 2005

[John Garza (3665)]

Why did the accuracy decrease before it got better?

ROM space concerns?
If so, that would explain the more accurate TI machines.
TI had an edge in semiconductor engineering.

-J

[Steve Simpkin]

(10-13-2023 08:14 AM)John Garza (3665) Wrote:  Why did the accuracy decrease before it got better?

ROM space concerns?
If so, that would explain the more accurate TI machines.
TI had an edge in semiconductor engineering.

-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.
Interview with Dr. William Kahan - August 2005

[Gerson W. Barbosa]

(06-22-2020 04:52 PM)EdS2 Wrote:  From the results page:

…

9.000417403
HP-27
HP-19C
HP-29C
HP-41C
HP-41CV
HP-67
HP-91
HP-97, HP-97S
HP-10C, HP-11C, HP-15C (Voyager)
HP-31E, HP-32E, HP-33E, HP-34C (Spice)

And

HP-12C Platinum (Voyager), with this user program:


(12c Platinum) Fast & Accurate Trigonometric Functions

(see optional steps)

:-)