For which models was 2^3>8?

[Joe Horn]

According to my best attempt to pinpoint the moment when 2^3 began to equal 8 in the evolution of HP calculators, I've compiled the following partial table of model introductions in historical order:

HP-35  1972-07
HP-80  1973-02
HP-56  1973-04
HP-66  1973-04
HP-45  1973-05
HP-65  1974-01
HP-70  1974-08
HP-55  1975-01
HP-21  1975-02 ???
HP-25  1975-08     2^3>8
========================
HP-22  1975-09     2^3=8
HP-91  1976-03
HP-27  1976-05
HP-25C 1976-07 ???
HP-67  1976-07
HP-97  1976-07
HP-10  1977-07
HP-29C 1977-07
HP-92  1977-07
HP-19C 1977-09
HP-97S 1977-12

Therefore the accuracy improvement seems to have happened between the inaccurate HP-25 (introduced August 1975) and the accurate HP-22 (introduced one month later). HOWEVER that leaves me with two questions:

(1) This implies that the HP-21 used the old inaccurate math, but I don't have one to verify that on. Could somebody with a real physical HP-21 (no simulators please) please check whether it returns 8.000000002 or exactly 8? Be sure to set DSP 9 of course.

(2) This also implies that the HP-25C is more accurate than the HP-25, which I highly doubt. Could somebody with a real physical HP-25C (not 25, and no simulators please) please check whether it returns 8.000000002 or exactly 8? Be sure to set FIX 9 of course.

Thanks in advance!

[james summers]

Joe

8.000000002 on my 21 S/N 1508s

Also 8.000000002 on my 25C S/N 1805S

[Joe Horn]

(04-04-2017 06:26 AM)james summers Wrote:  8.000000002 on my 21 S/N 1508s
Also 8.000000002 on my 25C S/N 1805S

Thanks, James! That completes the table.

[james summers]

Fortunately, the only two Woodstocks I have were the ones that were needed!

[Dave Britten]

I should check my Sinclair Cambridge Programmable. I think we'll be lucky if it's accurate to more than 2 significant figures.

[pier4r]

Why does it happen?

I mean if it would be , say, \( 169^{0.5} \) I could understand computation errors, but \( 2^3 \) seems pretty straightforward to me, it is even a base two power.

So does anyone have an explanation for it? It would be interesting.

[Dieter]

(04-04-2017 05:20 PM)pier4r Wrote:  Why does it happen?

I mean if it would be , say, \( 169^{0.5} \) I could understand computation errors, but \( 2^3 \) seems pretty straightforward to me, it is even a base two power.

So does anyone have an explanation for it? It would be interesting.

The explanation is simple and straightforward: y^x is calculated as e^x · ln y.
So 2³ is not evaluated as 2·2­·2 – how far should this go? Up to the 4th power? the 5th? The 10th?

That's why 2³ is calculated as e^{3 · ln 2}. With 10-digit precision the exponent is 3 · 0,6931471806 = 2,079441542 and the exponential of this is 8,0000 00002 56...  Especially powers of 2 (and 5) are prone to such roundoff errors because of the rounded 10-digit logarithm.

This improved as the calculators internally used a higher precision than displayed. Since 1976 most HP 10-digit calculators work with 13-digit internal precision – and the problem is solved. Well, in most cases, that is. ;-)

More details can be found in the November 1976 issue of HP-Journal, p. 16 f.

BTW, evaluating x³ by using the y^x function always has been a quite bad idea. Beside the accuracy issue this method is sloooow. Remember: there are two transcendental functions involved in every simple power calculation. On classic HPs you can see the display go blank for a short moment during such power calculations – simply because the operation takes that much time. A much better way is [ENTER] [x²] [x] or [x²] [LastX] [x] which even sets LastX correctly. Some newer calculators even allow [x²] [RCLx]L which does it all in the X-register.

BTW2: Your example 169^0,5 can be evaluated by the square root function which uses a completely different approach that does not cause the mentioned errors (and is also much faster). And the fact that 2³ is a base 2 power does not mean anything on a calculator that uses real BCD arithmetics, i.e. base 10.

BTW3: Who cares about the 10th digit? My first calculator returned exactly 5 (five!) significant digits of all transcendental functions. ;-)

Dieter

[pier4r]

Thanks Dieter! Yes I choose the square root of 169 because as far as I know it involves a bit of calculations and it could lead to errors.

For the \( e^{x \cdot ln(y)} \) I did not think they would use that unless rational numbers were used as input. For special cases, like 2, I also thought about shortcuts ( shifting bits ). Well, once again, today I learned.

[bshoring]

Great explanation Dieter. Interesting side note: On the HP-35 doing x^y the display goes blank for a split second, but on the HP-80 doing y^x causes the display to flicker as if it is running a program. I have to wonder if the HP-80 was programmed differently in order to pack so many functions (programs actually) into it.

[james summers]

Thanks for the great explanation, Dieter.

Just playing around, my MK-61, after a slight pause gives 7.9999993.
Doing [2] [ENTER] [ln] [3] [x] [e^x] also gives 7.9999993.

The 25C is more accurate, but similar, in that [2] [ENTER] [3] [y^x] and [2] [ENTER] [ln] [3] [x] [e^x] both give 8.000000002.

However, my 32E, 41CV and 15C, whilst giving [2] [ENTER] [3] [y^x] as 8.000000000, for [2] [ENTER] [ln] [3] [x] [e^x] they give 8.000000003.

Edited to add for Dave that my Sinclair Cambridge Scientific, which doesn't have the luxury of a [y^x] key, gives 7.9998.

[Dieter]

(04-04-2017 06:45 PM)james summers Wrote:  Thanks for the great explanation, Dieter.

Just playing around, my MK-61, after a slight pause gives 7.9999993.
Doing [2] [ENTER] [ln] [3] [x] [e^x] also gives 7.9999993.

Interesting. Without guard digits it should be 7.9999973. What are the intermediate results you get for ln 2 and 3x this?

(04-04-2017 06:45 PM)james summers Wrote:  The 25C is more accurate, but similar, in that [2] [ENTER] [3] [y^x] and [2] [ENTER] [ln] [3] [x] [e^x] both give 8,000000002.

The 25 uses 10 digits as opposed to 8 in the MK-61.

(04-04-2017 06:45 PM)james summers Wrote:  However, my 32E, 41CV and 15C, whilst giving [2] [ENTER] [3] [y^x] as 8.000000000, for [2] [ENTER] [ln] [3] [x] [e^x] they give 8,000000003.

Why do you add an [ENTER] before the log? It's classic RPN. ;-)

The HP32/41/15 of course use the "new accuracy" since 1976 with three additional guard digits. That's why even with a manually calculated exponentional you get the correctly rounded value ...003. The difference to the HP25 result ...002 is probably due to different algorithms and/or rounding methods. In 1976 there were more improvements than just adding the guard digits, cf. the mentioned HP Journal article.

BTW, if you do not have access to the latter: most of the interesting stuff is available on hpl.hp.com.

Dieter

[james summers]

(04-04-2017 07:18 PM)Dieter Wrote:  

(04-04-2017 06:45 PM)james summers Wrote:  Thanks for the great explanation, Dieter.

Just playing around, my MK-61, after a slight pause gives 7.9999993.
Doing [2] [ENTER] [ln] [3] [x] [e^x] also gives 7.9999993.

Interesting. Without guard digits it should be 7.9999973. What are the intermediate results you get for ln 2 and 3x this?

[2] [ln] = 6.9314717 E-01
[3] [x] = 2.0794415
[e^x] b = 7.9999993

(04-04-2017 07:18 PM)Dieter Wrote:  

(04-04-2017 06:45 PM)james summers Wrote:  However, my 32E, 41CV and 15C, whilst giving [2] [ENTER] [3] [y^x] as 8.000000000, for [2] [ENTER] [ln] [3] [x] [e^x] they give 8.000000003.

Why do you add an [ENTER] before the log? It's classic RPN. ;-)

Because I'm an idiot! ;-)

[Dieter]

(04-04-2017 07:42 PM)james summers Wrote:  [2] [ln] = 6.9314717 E-01
[3] [x] = 2.0794415
[e^x] b = 7.9999993

So the log and exp functions may have errors in the last digit.
The correct eight-digit values are ln 2 = 0,69314718 and e^2,0794415 = 7,9999997.

Dieter

[bshoring]

Because the earliest calculators didn't have the 3 guard digits, you could do 1.000001 Enter 1,000,000 y^x and get e (2.718281828). This doesn't work on the HP-22 and later calculators. The first 2 financial calcs don't have e^x.

[Thomas Okken]

(04-04-2017 05:51 PM)Dieter Wrote:  The explanation is simple and straightforward: y^x is calculated as e^x · ln y.
So 2³ is not evaluated as 2·2­·2 – how far should this go? Up to the 4th power? the 5th? The 10th?

How about all the way? It's really quite efficient if you use exponentiation by squaring: x^n = (x^(n/2))^2 if n is even, and x*(x^((n-1)/2))^2 if n is odd; apply recursively or iteratively. The algorithm is O(log(n)). This is how Free42 gets 2^3=8 exactly, despite not using extended precision for intermediate results.

[teenix]

(04-04-2017 06:16 PM)bshoring Wrote:  Great explanation Dieter. Interesting side note: On the HP-35 doing x^y the display goes blank for a split second, but on the HP-80 doing y^x causes the display to flicker as if it is running a program. I have to wonder if the HP-80 was programmed differently in order to pack so many functions (programs actually) into it.

I know I know, so simulators :-)

Just curious though, the simulators returned the same results

The HP35 took 1720 instructions to process so about 1/2 second display off time assuming 800KHz clock.

The HP80, HP70 leave the display on for calculations because they can take a lot of time to process some financial problems. That way the user knows it is busy.
The HP80 took 1546 instructions to process and the HP67 took 1632.

cheers

Tony

[Dave Britten]

(04-04-2017 10:26 PM)Thomas Okken Wrote:  

(04-04-2017 05:51 PM)Dieter Wrote:  The explanation is simple and straightforward: y^x is calculated as e^x · ln y.
So 2³ is not evaluated as 2·2­·2 – how far should this go? Up to the 4th power? the 5th? The 10th?

How about all the way? It's really quite efficient if you use exponentiation by squaring: x^n = (x^(n/2))^2 if n is even, and x*(x^((n-1)/2))^2 if n is odd; apply recursively or iteratively. The algorithm is O(log(n)). This is how Free42 gets 2^3=8 exactly, despite not using extended precision for intermediate results.

I'm guessing they didn't want to spend the probably very limited ROM/RAM space of the old models to handle special cases of powers like that.

[bshoring]

(04-05-2017 07:50 AM)teenix Wrote:  

(04-04-2017 06:16 PM)bshoring Wrote:  Great explanation Dieter. Interesting side note: On the HP-35 doing x^y the display goes blank for a split second, but on the HP-80 doing y^x causes the display to flicker as if it is running a program. I have to wonder if the HP-80 was programmed differently in order to pack so many functions (programs actually) into it.

I know I know, so simulators :-)

Just curious though, the simulators returned the same results

The HP35 took 1720 instructions to process so about 1/2 second display off time assuming 800KHz clock.

The HP80, HP70 leave the display on for calculations because they can take a lot of time to process some financial problems. That way the user knows it is busy.
The HP80 took 1546 instructions to process and the HP67 took 1632.

cheers

Tony

Tony, thanks for enlightening me on why this function operates differently on the HP-80 from the HP-35. I have both actual calculators, so it's fun to see the differences. I've also downloaded your simulators for the 70 & 80, and I am very impressed. Yes, they operate just like the originals.

[Andres]

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. 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 feasible and the improved routines became standard.