The Museum of HP Calculators

HP Forum Archive 14

[ Return to Index | Top of Index ]

Workaround for 33S ->HMS bug
Message #1 Posted by Norris on 5 Sept 2004, 3:07 p.m.

If you are using the 33S on an NCEES civil engineering or surveying exam, then you may be concerned about the ->HMS bug described here

Basically, the 33S ->HMS function works incorrectly for certain negative values. So far as is known, it works correctly for all positive values.

A simple workaround for this bug is to load the following program:

LBL U
CF 4
x<0?
SF 4
FS? 4
+/-
-> HMS
FS? 4
+/-
CF 4
RTN

To use: Key in XEQ 5 for the ->HMS function, instead of [Right-Shift] 5

This program simply converts negative input values to positive values, because the ->HMS function appears to work correctly for positive values. If the input value was originally negative, then the output value is changed back to negative. If the input value was originally positive, then neither the input nor the output values are affected.

The program uses Label U and Flag 4. You can omit the last CF 4 statement if you don't mind seeing the "4" annunciator in the display.

For PE and PLS candidates in California, note that the NCEES calculator rules are not enforced on the state-specific land surveying and civil surveying exams. For California-specific engineering and surveying exams, the ideal workaround is to use an HP48.

Edited: 5 Sept 2004, 3:08 p.m.

      
Re: Workaround for 33S ->HMS bug
Message #2 Posted by Tom (UK) on 6 Sept 2004, 7:56 a.m.,
in response to message #1 by Norris

Thanks for the code, but:

HP should be fixing this (and other) bug(s).

Surely the product is not up to the specification that HP claim so HP should fix it?

            
Re: Workaround for 33S ->HMS bug
Message #3 Posted by Norris on 6 Sept 2004, 12:16 p.m.,
in response to message #2 by Tom (UK)

There is no easy way to fix the bugs in my 33S. In practice, they will not be corrected unless (1) HP redesigns the 33S, and (2) offers to swap old buggy units for new improved ones.

In my opinion, yes, HP should do this. Unfortunately, there's no guarantee that they actually will. So for now, I'm stuck with my 33S in its present condition, and I have to make the best of it. I can't put my exam on hold pending an HP decision that may never come.

For my purposes, the only bug that I am concerned about is the ->HMS bug, and I can avoid it by pressing XEQ U instead of [Right-Shift] U.

                  
Re: Workaround for 33S ->HMS bug
Message #4 Posted by Tom (UK) on 6 Sept 2004, 2:44 p.m.,
in response to message #3 by Norris

Agreed (and aggrieved!)

I use the XEQ U for a very simple HMS+ function that I use quite often on my HP32Sii (which I miss from my HP67):

LBL U

-> HR

x<>y

-> HR

+

-> HMS

RTN

Having to use one of the valuable 26 program tags to correct a bug is not ideal (but is understandable in your circumstances). I'm probably one of those holding off buying this RPN (rather than a RPL) calculator until HP sort out the bugs on the HP33S - or bring out the HP43S! (Cue wish list 'calculator HP never made').

Perhaps if HP had a bit of competition in the programmable / RPN / exam market they would sort out (and reduce the UK price of) this calc. Or perhaps they would just withdraw from the market because HP don't seem to want to compete at this level of the calc market anymore?

      
Re: Workaround for 33S ->HMS bug
Message #5 Posted by bill platt on 7 Sept 2004, 10:05 a.m.,
in response to message #1 by Norris

Norris,

Clever work!

The good thing about the 33s being buggy is that we get to see clever programming posted.

Best regards,

Bill

Now, for a tougher challenge, write a program which works around the "-0" problem-----

            
Re: Workaround for 33S ->HMS bug
Message #6 Posted by Norris on 7 Sept 2004, 1:27 p.m.,
in response to message #5 by bill platt

As far as I know (please correct me if I am wrong), the only way to generate the -0 bug is to deliberately enter 0, followed by +/-.

NOTE: I was wrong and was corrected. Therefore, the workarounds discussed below do not, in fact, work. But I am leaving this post up for continuity

My recommended workaround for this bug is as follows:

** Don't enter 0, followed by +/- **

This workaround is simple and causes me minimal inconvenience, yet it seems to be working well in practice.

**********

If it was really necessary, I suppose you could "fix" the ->theta,r function with the following:

LBL T
x=0?
ABS
y,x->theta,r
RTN

And a similar program would address the COMPLXLN function; just change the first line to LBL B and the fourth line to CMPLXLN.

However, I prefer my original suggested workaround, and that's what I'm using, at least for now.

Edited: 7 Sept 2004, 8:40 p.m. after one or more responses were posted

                  
Re: Workaround for 33S ->HMS bug
Message #7 Posted by bill platt on 7 Sept 2004, 1:52 p.m.,
in response to message #6 by Norris

Hi Norris,

I am not so sure it is so simple as you state-----

take a look at this:

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

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

I have not re-read the whole business---I just recalled that Karl's analysis existed and I thought you aught to see it!

Best regards,

Bill

Edited: 7 Sept 2004, 1:53 p.m.

                        
Re: Workaround for 33S ->HMS bug
Message #8 Posted by Norris on 7 Sept 2004, 2:26 p.m.,
in response to message #7 by bill platt

Yes, I think you may be right. I'll give it some more thought.

                        
Re: Workaround for 33S polar bug
Message #9 Posted by Norris on 7 Sept 2004, 9:03 p.m.,
in response to message #7 by bill platt

OK, here is a new & improved workaround for the 33S polar conversion bug. I think this one does work, but try it out for yourself.

LBL T
CF 4
x=0?
SF 4
FS? 4
Rv (roll down)
FS? 4
0
CF 4
x<>y (swap)
x=0?
SF 4
FS? 4
Rv (roll down)
FS? 4
0
CF 4
x<>y (swap)
y,x->theta,r
RTN

To use: key in XEQ 4 for conversion to polar coordinates, instead of [left-shift] 4.

Program uses Label T and Flag 4. It simply checks the x- and y-registers for zeros. If any are found, they are overwritten with nice fresh zeros before the conversion is performed. Nonzero values are unaffected.

For whatever reason, this routine seems to eliminate the silly "rotating sequence of answers" previously described by Karl Schneider here.

For example, start with (0,3). Convert to polar coordinates with [left-shift] 4, then back to rectangular coordinates with [right-shift] 4. You can repeat several times and watch the values change. But this will not happen if you load the program above, and substitute XEQ 4 for [left-shift] 4.

It's not entirely clear to me why this should work, but it seems like maybe it does.

Edited: 7 Sept 2004, 9:06 p.m.

                              
Re: Workaround for 33S polar bug
Message #10 Posted by Norris on 7 Sept 2004, 11:56 p.m.,
in response to message #9 by Norris

This version is better. It overwrites the zeroes more elegantly, without the need for a flag. Still seems to work, as far as I can tell.

LBL T
x=0?
CLx
x<>y (swap)
x=0?
CLx
x<>y (swap)
y,x->theta,r
RTN

                                    
Re: Workaround for 33S polar bug
Message #11 Posted by Karl Schneider on 9 Sept 2004, 12:48 a.m.,
in response to message #10 by Norris

Norris --

Good work on the elegant and robust workaround for the HP-33S polar-conversion bug. Also, my thanks to you and others for crediting my earlier posts on the "bug" topics.

If you have any idea about the HMS bug I analyzed earlier, you are welcome to attempt a "fix". Quite frankly, I'm not sure what that problem is.

-- KS

                                          
Re: Workaround for 33S polar bug
Message #12 Posted by Norris on 9 Sept 2004, 1:22 a.m.,
in response to message #11 by Karl Schneider

As far as I can tell, the crude workaround posted here effectively handles the HMS bug. It is based on your previous posting, which indicates that the bug only affects negative values. The workaround simply changes negative values to positive, runs the conversion on the positive value, then changes the result back to negative.

I am relying on this workaround, so please let me know if there are any problems with it.

                              
Re: Workaround for 33S polar bug
Message #13 Posted by bill platt on 8 Sept 2004, 11:38 a.m.,
in response to message #9 by Norris

Norris,

Congratulations!

This is quite interesting indeed! Yes, the "rotating answers" which are produced by the built-in function are indeed "cured" by your boolean test/replace.

In fact, you have solved both the "-0" problem and the rotating answers in the case of y=y, x=0 Rect-->Polar

Apparently, the built-in function of Polar-->rectangular (denoted "-->y,x") functions correctly.

(I only checked your second, more elegant solution--the one without resorting to flags)

Best regards,

Bill

[ Return to Index | Top of Index ]

Go back to the main exhibit hall