HP-35 Bug Question

[coloradokings]

I apologize if this topic is documented elsewhere - but I searched the forum and couldn't find any relevant reference.

I just purchased my first HP-35 calculator. It is a model 2 (no 35 printed on the front label).
It has the 2.02 and trig bugs and also has the raised dot on the number 5 key.
No serial number though - either on the back label or inside the battery compartment.

Here's my question: There seems to be a bug in the Y^X function. I'm not sure if this is a known bug (related to the ln2.02 bug) or if the calculator is just "broken". I'm hoping someone might be able to put me straight on this.

Examples of errors (in X^Y format) where r = recurring digit
2^2 = 3.99r; 3^2 = 8.00r3; 4^2 = 16.; 5^2 = 32.00r1; 6^2 = 63.99r8; 7^2 = 128
and
2^3 = 3.99r; 3^3 = 8.00r3; 4^3 = 81.00r11; 5^3 = 243.00r4; 6^3 = 729
same sort of thing for other X^Y calculations.

Anyone have any ideas if this is just a standard facet of the 2.02 bug? And if not, is it something of interest of just a broken calculator?

Thanks..

[Katie Wasserman]

Your x^y findings are well known. The early HP calculators didn't calculate integer exponentiation exactly, they used logs and anti-logs to compute them in order save space in ROM. There's some discussion of this in this thread.

[Don Shepherd]

Yeah, the HP-65 also is affected by the y^x bug. It also has a "feature" that converts digits 8 and 9 from octal to decimal.

[coloradokings]

Thanks to both of you - for responding so quickly!
That's good to know.
I actually just managed to download an old pdf manual and found that on page 21 there is a section on Operating Limits - Accuracy - so it looks like this is more a limitation that a bug.
Thanks again.

[Gerson W. Barbosa]

(04-20-2014 10:23 PM)Katie Wasserman Wrote:  The early HP calculators didn't calculate integer exponentiation exactly, they used logs and anti-logs to compute them in order save space in ROM.

My guess is they still do, the guard digts rounding the results properly. For instance, on the HP-11C:

Internally:
5 LN... 1.609437912[43]
3 *.... 4.828313737[29]
e^x.... 124.9999999[98]
Displayed result:
....... 125.0000000

The HP-35 lacks guard digits. Also, because of limited ROM space, it doesn't handle the negative x case.
As I said, this is just a guess, though.

[Joe Horn]

(04-20-2014 11:28 PM)Gerson W. Barbosa Wrote:  

(04-20-2014 10:23 PM)Katie Wasserman Wrote:  The early HP calculators didn't calculate integer exponentiation exactly, they used logs and anti-logs to compute them in order save space in ROM.

My guess is they still do, the guard digts rounding the results properly.

The HP-71B IDS shows that your guess is correct for at least the '71 and all models that use the same code. For normal inputs, it calculates "the usual e^(x*ln y) calculation" (comment at ROM address 0D2EE), performing each step to 15 internal digits, and only rounding the final result to 12 digits.

However #1: that code also sometimes calls entry point EXP16M (a 16-digit e^x), which in turn calls entry point DXP100 (a "double-precision" e^x, with the low-order digits of the double-precision argument in R0). I don't understand when these routines are called, or how accurate they make the y^x function; perhaps a Saturn-code expert can either decipher that section of the 71 IDS, or peruse the code in the HP 50g with Jazz or Nosy and figure out what it's doing.

However #2: What the HP Prime does can only be answered by Cyrille (for Home's x^y) or Bernard (for CAS's x^y), because they wrote that code from scratch (respectively), not merely porting it from the Saturn code.

[Dieter]

(04-20-2014 10:12 PM)coloradokings Wrote:  There seems to be a bug in the Y^X function. I'm not sure if this is a known bug (related to the ln2.02 bug) or if the calculator is just "broken".

As already explained, this is not a bug and also nothing is broken. What you see is a result of the limited accuracy of the HP35 since it did not have the additional three guard digits that were implemented later to avoid the results you posted.

You will find more information on this topic in the November 1976 issue of HP Journal. At that time the HP91 was introduced – it first used the 13-digit internal precision. You can find this issue as a PDF on hp.com, cf. page 16 f.

Even today not every result is always perfect. Take a look at this thread from last August, especially the last post.

Dieter

[Katie Wasserman]

(04-21-2014 10:31 AM)Joe Horn Wrote:  

(04-20-2014 11:28 PM)Gerson W. Barbosa Wrote:  My guess is they still do, the guard digts rounding the results properly.

The HP-71B IDS shows that your guess is correct for at least the '71 and all models that use the same code.

Does any other HP calculator use the same math code as the 71? I thought that it was unique in its use of the IEEE 754-1985 standard, what other calculator has NaN as a value?

I wonder if any HP (or non-HP) calculator did/does real integer exponentiation, excluding integer modes and CAS modes, of course. Assuming that enough guard digits were used you couldn't directly test for this because you'd always get the correct result. However you might be able to infer that the calculator used some fast algorithm for exponentiation by timing how long it took for various integer power calculations.

[Thomas Klemm]

(04-20-2014 11:28 PM)Gerson W. Barbosa Wrote:  The HP-35 lacks guard digits.

How Improvements Were Achieved

Quote:All HP calculators calculate \(y^x\) by the formula
\[y^x=e^{x \ln y}\]
This is evaluated by subroutine calls to ln, multiply, and exponential. On the HP-35 these subroutine calls were identical to the keyboard functions of the same name. The function \(y^x\) did the same as the key sequence
x<>y, ln, x, e^x

Guard digits are used within the keyboard functions but intermediate results are rounded.

Cheers
Thomas

[Thomas Klemm]

(04-23-2014 02:51 AM)Katie Wasserman Wrote:  I wonder if any HP (or non-HP) calculator did/does real integer exponentiation, excluding integer modes and CAS modes, of course.

What about calculating (-2)³? There must be a check that the exponent is an integer.

Quote:Assuming that enough guard digits were used you couldn't directly test for this because you'd always get the correct result. However you might be able to infer that the calculator used some fast algorithm for exponentiation by timing how long it took for various integer power calculations.

We can read the source, step through the code with a debugger or analyze the trace.

Cheers
Thomas

[Thomas Klemm]

(04-23-2014 03:58 AM)Thomas Klemm Wrote:  We can (...) analyze the trace.

Created a trace for both \(2^3\) and \((-2)^3\) with Nonpareil for the HP-41CV. In both cases you can find:

06931471805600
20794415416800

From this I conclude that the logarithm is used even if the exponent is an integer.

Cheers
Thomas

[Paul Dale]

(04-23-2014 02:51 AM)Katie Wasserman Wrote:  I thought that it was unique in its use of the IEEE 754-1985 standard, what other calculator has NaN as a value?

The 34S does

- Pauli

[Joe Horn]

(04-23-2014 02:51 AM)Katie Wasserman Wrote:  Does any other HP calculator use the same math code as the 71?

Yes; all the RPL models (28/48/49/50) use the same code as the '71 for most math routines, with just a few minor modifications, such as removing much of the special-case handling (signaling NaN's etc). In general, all the Saturn-based models shared a huge amount of Saturn code in their math routines.