Writing DEG/RAD mode-insensitive code



#6

A lot of times, I see programs that depend on the calculator's angle mode being set in a particular way. Or, the program sets the angle mode based on what it needs. I gave some thought as to how to write programs that do trig, but don't depend on the angle mode being set properly. Two approaches came to mind:

1. Determine the angle mode at program start, change it as needed, and then change it back upon completion.

2. Determine the angle mode at program start, and then do conversions as necessary during processing.

Suppose we want to write a program that works in degrees (such as an aviation related program). First let's look at option 1:

Determining the angle mode is easy. We can then use a flag to remember what it is. The following sequence of instructions determines the angle mode, and sets flag 0 if it is radians. Then it sets the mode to degrees:

CF 0
4
SIN
X<0?
SF 0
DEG

To restore the initial angle mode later, we just need to do:

FS0?
RAD

For option 2, we use the same initial sequence as option 1, except we omit the DEG instruction at the end.

Then, just before any function that expects an angle as an argument, we do:

FS0?
D->R

After any function that returns an angle, we do:

FS0?
R->D

At the end of the program, there's nothing to do, since we didn't change the calculator's angle mode setting at all (although we could clear the flag just to clean things up).

Of course, using this method trades making one change to the calculator's state (the angle mode) for a different change (the setting of a flag), but the latter is probably less likely to interfere with something.

Thoughts?

Stefan


#7

My friend Stefan, that very interesting. So if we were to do this with my aviation programs, what would my program look like? Which would effect size of program less.

One thing I not like with my code is that if you break out of distance program, calculator stuck in RAD mode, and unsuspecting user may forget and be fooled by results.

#8

Quote:
A lot of times, I see programs that depend on the calculator's angle mode being set in a particular way. Or, the program sets the angle mode based on what it needs. I gave some thought as to how to write programs that do trig, but don't depend on the angle mode being set properly.

...

Suppose we want to write a program that works in degrees (such as an aviation related program)...

Determining the angle mode is easy. We can then use a flag to remember what it is.


Hi, Stefan --

I regularly use a celestial-object program, "Sky map and compass" for the HP-41, orginally written by Tom Sherman in 1986, and improved by Geir Isene. It requires inputs in degrees, but neither version included a DEG instruction to set the proper mode. I've gotten a few incorrect results that way.

It's worth mentioning that the HP-41 and HP-42S retain the angular-mode setting in system flags 42 and 43. Thus, the user can check the setting without having to infer it through calculation, store it as appropriate (perhaps as a variable or user flag), and reset it later.

Flag 42 set = grads mode; Flag 43 set = radians mode. These are not directly user-settable.

-- KS


#9

Detecting the initial angle mode, setting it to degrees and then getting back to the original mode appears to be to best way to do it. Another way is computing the conversion factor and using it throughout the program. For example, the following program returns sin(30) and atan(1) in degrees, regardless the angle mode:

LBL A
1
ASIN
90
/
STO K
30
RCL* K
SIN
1
ATAN
RCL/ K
RTN

This method would be useful only for calculator on which the angle mode cannot be changed programmatically. This is not the case in any HP calculator, by what I can remember...

Gerson.

#10

Quote:
Then, just before any function that expects an angle as an argument, we do:

FS0?
D->R

After any function that returns an angle, we do:

FS0?
R->D

Don't forget the calculator might also be set to GRAD mode :-)

Gerson.


Possibly Related Threads...
Thread Author Replies Views Last Post
  HP50g: Writing a function that returns a function Chris de Castro 2 907 12-10-2013, 06:49 PM
Last Post: Han
  Integration question and "RPN" mode comment Craig Thomas 16 2,765 12-05-2013, 02:32 AM
Last Post: Nick_S
  Writing RPL programs on OS X Sean Freeman 18 2,349 11-30-2013, 03:59 PM
Last Post: Sean Freeman
  HP PRIME: APP program code DISAPPEARS !! Joseph Ec 0 448 11-25-2013, 11:35 AM
Last Post: Joseph Ec
  HP Prime: Recommendation for future RPN Program Mode BruceTTT 3 843 11-13-2013, 10:03 PM
Last Post: BruceTTT
  [HP-Prime] - Shortcuts for program writing Jean-Michel 4 881 11-01-2013, 07:55 AM
Last Post: Jean-Michel
  Program to change entry mode on Prime Michael de Estrada 3 814 10-28-2013, 10:13 AM
Last Post: Han
  Prime: Exam mode (possible duplicate after funny response first time) Paul Townsend (UK) 1 614 10-24-2013, 03:09 PM
Last Post: Tim Wessman
  Does RPN entry mode cause the Prime keyboard to lock up ? Michael de Estrada 14 2,043 10-22-2013, 06:27 PM
Last Post: John Colvin
  HP Prime: Edit integer in RPN mode plivesey 15 2,002 10-18-2013, 04:34 PM
Last Post: kris223

Forum Jump: