HP35 Bug Question

04202014, 10:12 PM
(This post was last modified: 04202014 10:17 PM by coloradokings.)
Post: #1




HP35 Bug Question
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 HP35 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.. 

04202014, 10:23 PM
(This post was last modified: 04202014 10:29 PM by Katie Wasserman.)
Post: #2




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

04202014, 10:56 PM
Post: #3




RE: HP35 Bug Question
Yeah, the HP65 also is affected by the y^x bug. It also has a "feature" that converts digits 8 and 9 from octal to decimal.


04202014, 11:11 PM
(This post was last modified: 04202014 11:14 PM by coloradokings.)
Post: #4




RE: HP35 Bug Question
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. 

04202014, 11:28 PM
(This post was last modified: 04202014 11:29 PM by Gerson W. Barbosa.)
Post: #5




RE: HP35 Bug Question
(04202014 10:23 PM)Katie Wasserman Wrote: The early HP calculators didn't calculate integer exponentiation exactly, they used logs and antilogs 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 HP11C: Internally: 5 LN... 1.609437912[43] 3 *.... 4.828313737[29] e^x.... 124.9999999[98] Displayed result: ....... 125.0000000 The HP35 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. 

04212014, 10:31 AM
Post: #6




RE: HP35 Bug Question
(04202014 11:28 PM)Gerson W. Barbosa Wrote:(04202014 10:23 PM)Katie Wasserman Wrote: The early HP calculators didn't calculate integer exponentiation exactly, they used logs and antilogs to compute them in order save space in ROM. The HP71B 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 16digit e^x), which in turn calls entry point DXP100 (a "doubleprecision" e^x, with the loworder digits of the doubleprecision argument in R0). I don't understand when these routines are called, or how accurate they make the y^x function; perhaps a Saturncode 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. <0ɸ0> Joe 

04212014, 01:47 PM
(This post was last modified: 04212014 01:47 PM by Dieter.)
Post: #7




RE: HP35 Bug Question
(04202014 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 13digit 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 

04232014, 02:51 AM
(This post was last modified: 04232014 03:10 AM by Katie Wasserman.)
Post: #8




RE: HP35 Bug Question
(04212014 10:31 AM)Joe Horn Wrote:(04202014 11:28 PM)Gerson W. Barbosa Wrote: My guess is they still do, the guard digts rounding the results properly. 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 7541985 standard, what other calculator has NaN as a value? I wonder if any HP (or nonHP) 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. katie 

04232014, 03:39 AM
Post: #9




RE: HP35 Bug Question
(04202014 11:28 PM)Gerson W. Barbosa Wrote: The HP35 lacks guard digits. How Improvements Were Achieved Quote:All HP calculators calculate \(y^x\) by the formula Guard digits are used within the keyboard functions but intermediate results are rounded. Cheers Thomas 

04232014, 03:58 AM
Post: #10




RE: HP35 Bug Question
(04232014 02:51 AM)Katie Wasserman Wrote: I wonder if any HP (or nonHP) calculator did/does real integer exponentiation, excluding integer modes and CAS modes, of course.What about calculating (2)^{3}? 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 

04232014, 06:31 AM
Post: #11




RE: HP35 Bug Question
(04232014 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 HP41CV. 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 

04232014, 07:48 AM
Post: #12




RE: HP35 Bug Question  
04242014, 12:03 PM
Post: #13




RE: HP35 Bug Question
(04232014 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 specialcase handling (signaling NaN's etc). In general, all the Saturnbased models shared a huge amount of Saturn code in their math routines. <0ɸ0> Joe 

« Next Oldest  Next Newest »

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