HP-35s bug list

Posted by Paul Dale on; 22 Aug 2007, 6:22 p.m.

Here is a quick list I've made up which contains the list of known bugs in the HP-35s. Feel free to contact me
with new bugs and expansions for these bugs.

1. Vector input bug has been mentioned and very weird behavior shows up but I'm not aware of this being
isolated or repeatable. It might be related to memory full. I do have enough trust in the people reporting
problems to believe there is something to them.
2. Cos(x) for x near 90 is dud. For what appears to be the same reason, Tan(x) for x near 90 is also dud.
3. Checksums are meaningless. Discover how they work and interact with equations.
4. Program sizes are also meaningless. Again seems to be number related and again nothing proven.
5. Bad error message on indirection on J: 1000 ; STO J ; x<>(J). You get "INVALID (I)" error message if done
from the keyboard, from a program it gives the correct message.
6. Bad radix. If you are in RADIX, mode and you enter RADIX, in program mode it is displayed as "RADIX.". If
you run the program it behaves correctly.
7. Program entry bug for large programs. Create a 999 step program and then try to enter a new LBL.
You're not allowed. Delete one step, create the LBL and put the step back and all is fine.
8. In a program: VIEW (I) ; PSE will show the wrong value of I.
9. In ALL mode, the mantissa should be properly rounded so that the exponent fits on the screen. i.e. the
entire number is displayed without scrolling.
10. This sequence as a program displays (37): 10 instead of (10): 10. LBL Z ; 10 ; STO I ; STO (I) ; VIEW I ; PSE It
works fine in run mode and without the PSE. I've had a report that the keystrokes here should be: LBL Z ;
10 ; STO I ; STO (I) ; VIEW (I) ; PSE. Can somebody confirm please.
11. Pressing and releasing the binary operator keys real fast results in missed strokes.
12. The '1 (f) /c' sequence to display the current denominator doesn't work in ALG mode but is fine in RPN
mode.
13. TANH, SINH and COSH all have bugs when applied to large values. An OVERFLOW message given when
computing TANH for values greater than or equal to 30000. The TANH value is correct, 1, but the
OVERFLOW message is wrong. SINH and COSH generate the OVERFLOW message correctly, but return
the wrong values. Overflow is supposed to return 1E500, but with an argument greater than or equal to
30000 SINH and COSH return the mantissa of the argument and the characteristic is changed to 499.
e.g. SINH 31415 = OVERFLOW --> 3.1415E499
14. LBL A
156.25
STO X
208.333333334; There are eight 'threes' in there
STO R
1.77951304201
STO Q
-R*X/(X*Q-R); Should evaluate to roughly -467, and it does
-R*X/(X*Q-R); Should (still) evaluate to roughly -467, but
calculator outputs 31.323 instead!
RTN

This one is actually much more widely spread that just illustrated by this example. See this analysis for
other cases.
15. Some programs cannot be interrupted. Prompt messages without a PSE following them cause the
problem:

A001 LBL A
A002 SF 10
A003 LOCKUP DEMO
A004 0
A005 GTO A004

Warning: running this code will mostly likely cause all memory to be lost.

16. When scrolling through 'line count' program memory [via the <-MEM 2] menu, downward, I will find a
LBL; that the list seems to be stuck at. Seems to be related to have unlabeled statement(s) at the start
of program memory and entering this mode when at the top of program memory (GTO ..)
17. Input -1/3 i -1/3 by typing ". 1 . 3 CHS i . 1 . 3 CHS ENTER". Get "0.3333i-0.3333" instead of "-0.3333i-
0.3333". Works correctly when entering "0.3333333 CHS i 0.3333333 CHS ENTER".
18. It appears that registers G...L are used internally in the 2*2 lin. solve in an unusual way. If there is
anything other than a real number in these registers (a complex number or a vector) the linear solver
returns "no solution." Kind of interesting, as these registers are not overwritten after using the linear
solver which appears to indicate that these registers are not actually used.
19. Deleting a line with a label on it doesn't correctly update branches to that label and in fact can leave you
with a branch to a non-existent step. The documentation says it should update.

K001 LBL K Deleting K001 LBL K

K002 INPUT A L001 gives K002 INPUT A
K003 XEQ L001 -----------> K003 XEQ L001 this should be XEQ K006
K004 VIEW B K004 VIEW B
K005 RTN K005 RTN
L001 LBL L K006 B=pi*SQ(A)
L002 B=pi*SQ(A) K007 RTN
L003 RTN

20. Solve infinite loops for some program based functions. Assign FN=D and SOLVE the following for X. The
solve doesn't finish. This seems to be related to using a loop in the function being solved.

D001 LBL D
D002 10
D003 STO N
D004 DSE N
D005 GTO D004
D006 RCL X
D007 COS
D008 RTN

A workaround for this is to include an always false conditional after any INPUT statements with a RTN
instruction and a STOP. For example:

B001 LBL B
B002 INPUT T
B003 INPUT X
B004 CF 1
B005 FS? 1
B006 RTN
B007 FS? 1
B008 XEQ C001
B009 0.2xX-T
B010 RTN
C001 LBL C
C002 STOP
C003 RTN
21. Clear stack in run mode preserves LastX; in program mode it clears it. Bug report thread.
22. Pi sets LastX register.

2 [ENTER] 5 [x] 10,0000

[Pi] [LASTx] [x] 31,4159

Pi has been multiplied by X (10) instead of what should have been in LastX (5). Bug report thread.

Now for some items that cannot be classified as bugs, since they are documented or work correctly. These
items are still quite annoying and should be fixed:

1. GTO.a ENTER doesn't work as expected. GTO.a000 does.

2. INPUT (i) for i>=0 doesn't work. This is documented in the manual but still seems wrong.
3. Poor choice for the graphics for the "theta". It is much too close to the graphic for "8".
4. No easy way to extract to deconstruct complex numbers into pairs of reals.
5. No rectangular to polar conversions except for display purposes.
6. 2*2 lin. solve and 3*3 lin. solve look strange. 2x2 and 3x3 seems better. I.e. multiplication sign
instead of asterisk.
7. Input of numbers in bases other than 10 requires the suffix to be explicitly entered. This makes non-
base 10 unworkable.

Edited; 10 Dec 2015, 8:10 p.m.