The Museum of HP Calculators
HP Articles Forum
[Return to the Index ]
[ Previous | Next ]
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.
- 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.
There might be a workaround. When the problem shows up, go to the equation editor and move to the start of the begining of the list. That is:
- Press EQN
- Press up and right until the message EQN LIST TOP appears on the bottom line.
- Input a vector normally.
If it doesn't work, try turning it off and back on. This has been working for me consistently and I cannot reproduce the bug any more.
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.
Checksums are meaningless. Discover how they work and interact with equations.
Program sizes are also meaningless. Again seems to be number related and again nothing proven.
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.
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.
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.
In a program: VIEW (I) ; PSE will show the wrong value of I.
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.
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.
Pressing and releasing the binary operator keys real fast results in missed strokes.
The '1 (f) /c' sequence to display the current denominator doesn't work in ALG mode but is fine in RPN mode.
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
208.333333334 ;There are eight 'threes' in there
-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!
This one is actually much more widely spread that just illustrated by this example. See
this analysis for other cases.
Some programs cannot be interrupted. Prompt messages without a PSE following them cause the problem:
A001 LBL A
A002 SF 10
A003 LOCKUP DEMO
A005 GTO A004
Warning: running this code will mostly likely cause all memory to be lost.
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 ..)
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".
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. Bug report thread.
Deleteing 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
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
D003 STO N
D004 DSE N
D005 GTO D004
D006 RCL X
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
B007 FS? 1
B008 XEQ C001
C001 LBL C
Clear stack in run mode preserves LastX, in program mode it clears it. Bug report thread.
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:
- GTO.a ENTER doesn't work as expected. GTO.a000 does.
- INPUT (i) for i>=0 doesn't work. This is documented in the manual but still seems wrong.
- Poor choice for the grahpics for the "theta". It is much too close to the graphic for "8".
- No easy way to extract to deconstruct complex numbers into pairs of reals.
- No rectangular to polar conversions except for display purposes.
- 2*2 lin. solve and 3*3 lin. solve look strange. 2x2 and 3x3 seems better. i.e. multiplication sign instead of asterisk.
- Input of numbers in bases other than 10 require the suffix to be explicitly entered. This makes non-base 10 unworkable.
Edited: 25 Jan 2023, 5:51 p.m.
[ Return to the Message Index ]
Go back to the main exhibit hall