The Museum of HP Calculators

HP Forum Archive 17

[ Return to Index | Top of Index ]

HP-35s bug list
Message #1 Posted by Daniel Diggelmann on 22 Aug 2007, 5:03 p.m.

I'm working in the R&D department of an aircraft manufacturer. I have ordered a larger quantity of HP-35s for our engineers. While talking to the main importer for Switzerland I mentioned that a few bugs have already been found. The importer had heard about the bugs and had a meeting with HP where HP told them that this was all just negative publicity, possibly spread on the internet by their competitors. What do you guys think of HPs position here?

The importer offered me to pass a buglist to HP if I could provide it. I know of the cos(x) bug for x= near to 90. I have also heard about the checksum error. Could we please collect all known bugs in this thread and I'll pass them to HP. I also made them clear that in aviation industry there's little room for errors. If we find out the HP-35s has unacceptable bugs I'll return them all to HP. I'm quite a HP fan but since about 10 years we have been let down with lousy hardware. The hardware of my personal HP-35s feels very good to me. But I can't believe that HP haven't fixed known bugs since the HP-33s. I understand that the HP-35s would have never been realised without a lot of pressure from the enthusiasts here. Now I think we should keep the pressure up in order to get back the quality we expect.

Thanks for all your contribution.

Daniel Diggelmann

Edited: 22 Aug 2007, 5:03 p.m.

      
Re: HP-35s bug list
Message #2 Posted by Paul Dale on 22 Aug 2007, 5:21 p.m.,
in response to message #1 by Daniel Diggelmann

I've put this list up as an article and will try to keep that current rather than editing here all the time. Check the article for the current state of affairs.


Here is a quick list I've made up. Feel free to expand and/or correct these:

  1. Vector input bug has been mentioned and very weird behavior shows up but I'm not aware of this being isolated or repeatable. 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.

  3. Checksums are meaningless. Seems to be related to numbers in programs but nothing definitely proven yet.

  4. Program sizes are also meaningless. Again seems to be number related and again nothing proven.

  5. Bad error message on indirection on J. You get "INVALID (I)" error message if done from the keyboard, from a program it gives the correct message: 1000 ; STO J ; x<>(J)

  6. Bad radix. If you are in RADIX, mode and you enter RADIX, in program mode it is displayed as RADIX.

  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. GTO.a ENTER doesn't work as expected. GTO.a000 does.

  9. INPUT (i) for i>=0 doesn't work. Strictly this is documented in the manual and so isn't really a bug.

  10. Poor choice for the grahpic for the "theta". It is much too close to the graphic for "8". Again, not strictly a bug.

This probably should go up as an article rather than being lost in the forum section.

- Pauli


<edited to include checksum and program size bugs>
<edited to include theta vs 8 discrimination problems>
<pointed to the article in progress>

Edited: 22 Aug 2007, 8:02 p.m. after one or more responses were posted

            
(Pauli: the checksum, the checksum ...) :-)
Message #3 Posted by Valentin Albillo on 22 Aug 2007, 5:28 p.m.,
in response to message #2 by Paul Dale

Best regards from V.

                  
Re: (Pauli: the checksum, the checksum ...) :-)
Message #4 Posted by Paul Dale on 22 Aug 2007, 5:38 p.m.,
in response to message #3 by Valentin Albillo

The checksum was mentioned in the initial post, but I should have remembered it too. Also the program size is screwy. I'll add both to my list.

- Pauli

            
Re: HP-35s bug list
Message #5 Posted by Bruce Bergman on 22 Aug 2007, 6:08 p.m.,
in response to message #2 by Paul Dale

Agreed. Some common, visible location would be the best. A wiki, in some respects.

Seems like several folks would like to consider the poor character layout choice for "theta" as a "bug" -- I'd at least pass it along to HP.

thanks, bruce

            
Re: HP-35s bug list
Message #6 Posted by Alain Mellan on 22 Aug 2007, 6:18 p.m.,
in response to message #2 by Paul Dale

10. Theta sign in complex display mode is hard to differentiate from an eight.

11. Missing re/img extraction may be considered as bug?

            
Re: HP-35s bug list
Message #7 Posted by Paul Dale on 22 Aug 2007, 6:24 p.m.,
in response to message #2 by Paul Dale

I've put the list into an article.

I'll keep it updated as new bugs are found and errors in the list reported.

I've also split the list into genuine bugs and annoyances that are harder to classify as bugs. Feel free to dispute my classifications.

- Pauli

                  
Re: HP-35s bug list
Message #8 Posted by Thomas Radtke on 22 Aug 2007, 6:44 p.m.,
in response to message #7 by Paul Dale

It has already been mentioned that only improper fractions can be entered, i.e., the expression a..b, resulting in a/b on the 32SII, cannot be entered. I'd consider this a design flaw.

Edit: Not quiet correct, of course 0.a.b can be entered but this seems to be unnecessarily laborious.

Edited: 22 Aug 2007, 6:46 p.m.

                        
Re: HP-35s bug list
Message #9 Posted by Walter B on 22 Aug 2007, 6:53 p.m.,
in response to message #8 by Thomas Radtke

Hallo Thomas,

to reach a/b, you are free to enter .a.b - same number of keystrokes as the a..b you miss AND more logical ;-)

                              
Re: HP-35s bug list
Message #10 Posted by Thomas Radtke on 22 Aug 2007, 7:35 p.m.,
in response to message #9 by Walter B

How could I possibly miss *that*? Oh well...

Thanks Walter :-)

            
Re: HP-35s bug list
Message #11 Posted by Katie Wasserman on 22 Aug 2007, 6:31 p.m.,
in response to message #2 by Paul Dale

Also, in a program:

    VIEW (I)
    PSE

will show the wrong value of I

            
Re: HP-35s bug list
Message #12 Posted by DLF on 22 Aug 2007, 6:46 p.m.,
in response to message #2 by Paul Dale

Since you mentioned it for another item you listed, it's worth noting that the "Cos(x) for x near 90 degrees" bug is also alluded to in the documentation (pg. 4-4 in the English User's Guide).

Quote:
Here is a quick list I've made up. Feel free to expand and/or correct these:

  1. Vector input bug has been mentioned and very weird behavior shows up but I'm not aware of this being isolated or repeatable. 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.

    blah...blah


                  
Re: HP-35s bug list
Message #13 Posted by Gerson W. Barbosa on 22 Aug 2007, 9:26 p.m.,
in response to message #12 by DLF

Nope, at page 4-4 they say sin(pi) is not equal to zero because pi is represented internally with fifteen places (although the computed answer appears to have been taken with pi to only twelve places). In fact, sin(3.14159265359 rad) = -2.0676153735661672045E-13, to 20 places, whose first 12 digits agree to the answer given by the 33s, after rounding.

The point here is cos(x) -- and tan(x) -- not being correctly computed for x near 90 degrees. For instance, cos(89.999) returns 1.745329091E-5. The correct result at this precision is 1.74532925191E-5. Even worse, tan(89.99999) returns 5,729,578.122 instead of 5,729,577.95131. These mistakes might not affect practical applications, but should not occur in a XXIst-century calculator...

Gerson.

Edited: 22 Aug 2007, 9:29 p.m.

                        
Re: HP-35s bug list
Message #14 Posted by DLF on 23 Aug 2007, 12:42 a.m.,
in response to message #13 by Gerson W. Barbosa

Thanks for the clarification; I just assumed it was a related "rounding error." And it appears that pi is definitely *not* 15 places internally, but only the 12 places that you noted is actually being used. So the documentation is wrong about that. (As a technical writer myself, I never like discovering that!)

                              
Re: HP-35s bug list
Message #15 Posted by Raymond Del Tondo on 23 Aug 2007, 3:26 a.m.,
in response to message #14 by DLF

The Saturn-based calcs, like the original HP-32S and HP-32SII,
have an internal accuracy of fifteen digits plus sign.

But please note that the 35s is not a Saturn-based machine,
and thus it isn't necessarily 100 percent compatible.

Maybe the docs haven't been updated accordingly...

Raymond

                              
Re: HP-35s bug list
Message #16 Posted by Gerson W. Barbosa on 23 Aug 2007, 9:26 a.m.,
in response to message #14 by DLF

In fact, it's been shown that pi is a double-precision constant in all Saturn-based calculators. This is true on the HP-35s as well. Do the following, in RAD and in ALL display mode:

pi 9E-11 - ENTER SIN 1E22 *

You'll get
    3.1415926535
    897,932,384,626

That's pi to 23 digits:

3.1415926535897932384626

This was already discussed here, some years ago:

http://www.hpmuseum.org/cgi-sys/cgiwrap/hpmuseum/archv014.cgi?read=62301

When pi is shown in the display, it is rounded up to 12 digits. Therefore the calculator's answer for sin(pi) is equivalent to sin(3.14159265359 rad), which is absolutely correct.

Regards,

Gerson.

Edited 4 grammar.

Edited: 23 Aug 2007, 10:58 p.m. after one or more responses were posted

                                    
Re: HP-35s bug list
Message #17 Posted by DLF on 23 Aug 2007, 8:10 p.m.,
in response to message #16 by Gerson W. Barbosa

Gerson --

Maybe I'm just dense then, but (ignoring symbolic-mode calculators for a moment) why is sin(pi) on a "double-precision" 35s equiv. to sin(3.14159265359 rad), and not sin(3.1415926535897932384626 rad)?

-- DLF

                                          
Re: HP-35s bug list
Message #18 Posted by Gerson W. Barbosa on 23 Aug 2007, 10:54 p.m.,
in response to message #17 by DLF

I think I didn't make myself clear, sorry! When I wrote sin(pi), I meant pi rounded up to 12 digits, not the internal double-precision constant used in the trigonometric routines to ensure better accuracy.

An example might help us understand how this works:

Let's consider the HP-15C, whose internal pi constant is 3.14159265359. So on the HP-15C sin(3.141592654) will return -sin(3.141592654 - 3.14159265359)= -sin(4.1E-10) = -4.1E-10. In the third quadrant, sin(x) = -sin(x - pi). If the argument is the second quadrant, for instance, x = 3.14159265 then sin(x) = sin(pi - x). In this case, the HP-15C returns sin(3.14159265359 - 3.14159265) = sin (0.00000000359). For very small arguments, sin(x) = x. So, what we get here are the last three digits of the 12-digit internal pi constant: 3.14159265359. Had the HP-15C a double-precision pi internally, we would obtain 0.000000003589793239, that is, 3.1415926535897932385 - 3.14159265.

Gerson.

                                                
Re: HP-35s bug list
Message #19 Posted by DLF on 24 Aug 2007, 11:33 a.m.,
in response to message #18 by Gerson W. Barbosa

Gotcha! And thanks for humoring me.

                                                      
Re: HP-35s bug list
Message #20 Posted by Gerson W. Barbosa on 24 Aug 2007, 1:34 p.m.,
in response to message #19 by DLF

You're welcome!

FWIW, with the HP CALC application on the HP-200LX, in the proper modes, we can easilly get pi to 32 digits:

PI
ENTER
SIN

-> 3.141592653589793 2.384626433832795e-16

            
Re: HP-35s bug list
Message #21 Posted by Gerson W. Barbosa on 22 Aug 2007, 10:25 p.m.,
in response to message #2 by Paul Dale

Not exactly bugs, rather a feature. Anyway, suggestions for improvement:

1) XEQ [label] ENTER is rather cumbersome. Also, since XEQ stands for 'execute', ENTER appears to be redundant. Besides, the ENTER key always seems to be so far far away to me :-)... Why not simply XEQ [label]? XEQ [.] nnn should be used for a particular line.

2) In ALL mode, the mantissa should be properly rounded so that the exponent fits in the screen, a la 32S, 32Sii, 33s, etc... Or, at least, a flag should be provided for this option.

3) 2*2 lin. solve and 3*3 lin. solve look strange. 2x2 and 3x3 seems better. I would guess that was the original idea, but then some 'translated' that x as *.

4) Exchange the positions of Sigma+ and R/S keys.

Regards,

Gerson.

Edited: 22 Aug 2007, 10:27 p.m.

                  
Re: HP-35s bug list
Message #22 Posted by Raymond Del Tondo on 23 Aug 2007, 3:19 a.m.,
in response to message #21 by Gerson W. Barbosa

For your first note:
AFAIK they made the XEQ work the way it does because you can
use it to jump to a specific program line in another program.
Consider you're in line A012, and want to call
a specific line in program B, say B056.
Then you will enter XEQ B056, followed by pressing ENTER.

I still don't like the programming model,
which is a blown-up 32S/33s programming model,
but at least you _can_ call code slices
which you otherwise could not reach.

Besides, IMHO the ENTER bar is in the perfect position;-)

Raymond

                        
Re: HP-35s bug list
Message #23 Posted by Gerson W. Barbosa on 23 Aug 2007, 9:38 a.m.,
in response to message #22 by Raymond Del Tondo

Quote:
Besides, IMHO the ENTER bar is in the perfect position;-)

IMEMHO, you are right! Now, I wish there were also a big-ENTER-key 50g. It would be a perfect companion to the 35s.

Regards,

Gerson.

                        
Re: HP-35s bug list
Message #24 Posted by Gerson W. Barbosa on 23 Aug 2007, 9:51 a.m.,
in response to message #22 by Raymond Del Tondo

Quote:
Consider you're in line A012, and want to call a specific line in program B, say B056. Then you will enter XEQ B056, followed by pressing ENTER.

I think XEQ .B056 to accomplish this would be better:

- same number of keystrokes;

- Only two keystrokes when calling B001 (XEQ B).

Or would this present some inconsistency I have not perceived?

Gerson.

P.S.: ENTER could be reserved for shortcuts:

XEQ .B7 ENTER, rather than XEQ .B007

Edited: 23 Aug 2007, 9:55 a.m.

                              
Re: HP-35s bug list
Message #25 Posted by Marcus von Cube, Germany on 24 Aug 2007, 10:39 a.m.,
in response to message #24 by Gerson W. Barbosa

Quote:
I think XEQ .B056 to accomplish this would be better:
The dot notation is used in program mode to navigate to a different line without changing the program, at least on my 33s. So it is not free for your intended purpose.
                                    
Re: HP-35s bug list
Message #26 Posted by Gerson W. Barbosa on 24 Aug 2007, 12:12 p.m.,
in response to message #25 by Marcus von Cube, Germany

Would you please explain? I know how GTO.Lnnn works in run mode, but I haven't been able to see how XEQ.Lnnn would work in program mode.

Thanks,

Gerson.

                  
Re: HP-35s bug list
Message #27 Posted by Karl Schneider on 24 Aug 2007, 3:21 a.m.,
in response to message #21 by Gerson W. Barbosa

Hi, Gerson --

Quote:
Why not simply XEQ [label]? XEQ [.] nnn should be used for a particular line.

Good idea, but we'd need XEQ [.] Lnnn, where L is a letter label.

Quote:
In ALL mode, the mantissa should be properly rounded so that the exponent fits in the screen, a la 32S, 32Sii, 33s, etc

Or in any mode for which the display length is too short to accommodate the full number. I, too, preferred the "legacy" method (which actually pre-dates Pioneer models) because it shows the full exponent, providing the magnitude of the number that cannot be overlooked.

However, the HP-35s, with its 14 display positions, cannot display a complete "longest-possible" complex number, even if the mantissa were rounded to only one digit. 15 display positions would be required to show such a number, e.g.:


1.0111x10-234 + i*5.0555x10-432 

would have to be displayed as


-1E-234i-5E-432 

The HP-42S did not have this problem; it could display up to 22 characters on one line, with each decimal point requiring a position.

-- KS

Edited: 24 Aug 2007, 3:27 a.m.

                        
Re: HP-35s bug list
Message #28 Posted by Gerson W. Barbosa on 24 Aug 2007, 10:45 a.m.,
in response to message #27 by Karl Schneider

Hello Karl,

Quote:
Quote:
Why not simply XEQ [label]? XEQ [.] nnn should be used for a particular line.

Good idea, but we'd need XEQ [.] Lnnn, where L is a letter label.


That was a typo. Thanks for pointing out the mistake! Anyway, I don't think an extra keystroke in these cases should be a problem because they will not occur very often. Also, it's unlikely anyone will use all 26 labels in a calculator which has no I/O system. Chances are only a few programs will reside in memory at a time, so there will be plenty of letter labels left. If M constains some matrix routines for determinant, inverse matrix, etc., it would be better using XEQ D, XEQ I, etc., instead of XEQ .M065, XEQ M.110, etc., for instance.

Quote:
The HP-42S did not have this problem; it could display up to 22 characters on one line, with each decimal point requiring a position.

On the other hand, some consider the tiny characters in the HP-42S a weakness. I like the larger characters in the HP-35s, so that's ok for me. Perhaps providing a way to use both display lines to show a complex number could be offered as an option:

1.0111111E-234
i5.0555555E-432

The user would know this is only one complex number, otherwise the bottom display line would show

0i5.055556E-432

Also, as someone has suggested, HMS-> should be changed to ->H.

Regards,

Gerson.

      
Re: HP-35s bug list
Message #29 Posted by bill platt on 23 Aug 2007, 11:19 a.m.,
in response to message #1 by Daniel Diggelmann

Another desirable feature to be suggested for addition:

composition and decomposition of Vectors. Also cross product.

            
Re: HP-35s bug list
Message #30 Posted by Daniel Diggelmann on 23 Aug 2007, 5:00 p.m.,
in response to message #29 by bill platt

Dear colleagues,

Thanks very much for all your responses to the bug list. I've passed them on the importer which has already passed them to HP Europe. Let's hope they fix them in the next series.

Regards from Switzerland, Daniel

      
Re: HP-35s bug list
Message #31 Posted by gteague on 27 Aug 2007, 5:53 a.m.,
in response to message #1 by Daniel Diggelmann

is this a bug?

p5-4 & 5-5 of the manual say that you can show the value of the maximum denominator '/c' by issuing the commands: '1 (f) /c'.

i cannot get this to work in alg mode although entering a number between 2-4095 works and entering 0 works to set the default of 4095. entering a '1' seems to have no effect whatsoever.

in other words, i can issue '64 (f) /c' in alg mode, then switch to rpn mode and issue '1 (f) /c' and the display will show '64'.

i could not find a sequence of commands that would show the value of '/c' in alg mode.

/guy

            
HP-35s bug list -- is this a bug?
Message #32 Posted by gteague on 27 Aug 2007, 7:54 p.m.,
in response to message #31 by gteague

this question seems to have gotten lost or orphaned, but i didn't know where the 'official' bug list was being kept.

upon reflection, this might simply be a owners manual 'bug' rather than a hardware/software bug.

/guy

                  
Re: HP-35s bug list -- is this a bug?
Message #33 Posted by Paul Dale on 27 Aug 2007, 8:54 p.m.,
in response to message #32 by gteague

The bug list is kept here: HP-35s bugs. I've added this one.

- Pauli

                        
Re: HP-35s bug list -- is this a bug?
Message #34 Posted by Gerson W. Barbosa on 27 Aug 2007, 9:42 p.m.,
in response to message #33 by Paul Dale

Quote:
The bug list is kept here: HP-35s bugs.

Quote:
Cos(x) for x near 90 is dud.

Tan(x) is duff too :-)

Edited: 28 Aug 2007, 8:17 a.m.


[ Return to Index | Top of Index ]

Go back to the main exhibit hall