Understanding variables relative to the current active App

[Michael de Estrada]

Variables can have different contents and behavior depending on the current active App that is displayed at the top of the screen in Home or CAS view. This is because certain Apps have their own predefined variables that can supersede variables that have been created as User or CAS variables. For example, If you enter PMT in Home view, you will normally see P*M*T followed by the product of the contents of global reserved real variables P, M and T. However, if the Finance App is active, you will see PMT followed by the value of the payment value that shown in the Finance App. If you store a different value in PMT from Home view, it will then appear in the Finance App view. If, however, a different App such as Solve is active and you try to store a value in PMT, you will be asked if you want to create a variable named PMT and it will now appear as a User variable. If you make the Finance App active again, the value of PMT will not have changed. If you enter the User variable from the user menu, it will be the same as in the Finance App view, but if you return to another App that does not have a built-in variable PMT, then you will get back what you stored initially when the user variable was first created.

A similar situation occurs with the cell location names in the Spreadsheet App. It is especially important not to create CAS variables with the same names as App variables in PPL programs, since unpredictable results and crashes can occur if the variables are used or assigned values while the App is active. This is because the CAS variable can change type, such as a matrix becoming a list. Also, a CAS variable cannot be created if a variable of the same name already exists in the active App, e.g. a11 with a Spreadsheet App active.

[Michael de Estrada]

An additional curiosity that I found is that using App settings variables such as AAngle in a Spreadsheet will override the Home settings menu. If you have AAngle defined in a spreadsheet, you will not be able to change the angle setting in the Home view or in a program with HAngle. If you open the Home Settings view, at the top entry where you would normally choose the angle measure, instead you will see "See Symbolic Setup". If you attempt to change it in CAS Settings, it will revert to the AAngle setting, unless AAngle =0, in which case it will default to the global HAngle value.

[Han]

(01-05-2014 03:27 PM)Michael de Estrada Wrote:  An additional curiosity that I found is that using App settings variables such as AAngle in a Spreadsheet will override the Home settings menu. If you have AAngle defined in a spreadsheet, you will not be able to change the angle setting in the Home view or in a program with HAngle. If you open the Home Settings view, at the top entry where you would normally choose the angle measure, instead you will see "See Symbolic Setup". If you attempt to change it in CAS Settings, it will revert to the AAngle setting, unless AAngle =0, in which case it will default to the global HAngle value.

It is natural for an app's angle settings to override the system settings.

[Michael de Estrada]

(01-05-2014 03:38 PM)Han Wrote:  It is natural for an app's angle settings to override the system settings.

I find it curious that you should say that. Why should the current active App affect the operation of a totally unrelated calculation or program ? There is always going to be some App that is active, and if you are done with it and are doing something new that is unrelated, why should you need to change the active App in order to prevent it from interfering with your new activity ? Let's say your current active App has set the angle mode to degrees, but you are executing a program that requires radians, so it has the the statement HAngle:=1 that never gets executed because AAngle:=2 in the App. Your program fails to run correctly and you are scratching your head wondering why this has happened. IMO, what would be natural is for the program to at least temporarily override the angle setting during its execution.

[Han]

(01-05-2014 05:14 PM)Michael de Estrada Wrote:  

(01-05-2014 03:38 PM)Han Wrote:  It is natural for an app's angle settings to override the system settings.

I find it curious that you should say that. Why should the current active App affect the operation of a totally unrelated calculation or program? There is always going to be some App that is active, and if you are done with it and are doing something new that is unrelated, why should you need to change the active App in order to prevent it from interfering with your new activity ?

You don't have to change apps. As you noted, an app is always active. The HAngle is the default system-wide setting (I believe for both Home and CAS) that is the fall-back for all apps when AAngle is set to 0. That is, AAngle:=0 means use the system-wide HAngle setting. In terms of scope, an app runs inside the system-wide environment. So it must obey HAngle when AAngle is set to 0. Similarly, if you write a program -- it runs inside an app environment at any given time. So your program must likewise obey the hierarchy: first, it must obey AAngle, and if AAngle is 0, it must adhere to HAngle.

Quote:Let's say your current active App has set the angle mode to degrees, but you are executing a program that requires radians, so it has the the statement HAngle:=1 that never gets executed because AAngle:=2 in the App.

Which is exactly as designed. A program runs inside an app, and an app inside the entire system. So in terms of scope, the program's angle mode is first determined by AAngle and only only falls back onto HAngle when AAngle is 0. The issue you are raising is no different between program-inside-an-app vs app-inside-the-system.

Quote:Your program fails to run correctly and you are scratching your head wondering why this has happened. IMO, what would be natural is for the program to at least temporarily override the angle setting during its execution.

The failure of your program to run on every single combination of settings is not strong argument for changing the current design. A program should ideally run under all conditions, and its failure to do so is more often due to its author overlooking minute details.

This may be a difference in programming philosophy, but programs should avoid ever changing user's settings. In other calculators (and even the HP Prime), one can easily temporarily back up the user's settings and restore it. However, it is almost always possible to interrupt a program (without any lower-level hacking/programming) in such a way that the program never actually restores the user's settings. Taking the angle mode as an example, there are ways to avoid ever having to deal with changing a user's settings. Instead, your program should read the user's settings and handle it accordingly. If you prefer to use values associated with radian measure, then write a small subroutine that changes your programmed values to the appropriate angle based on the user's settings instead of changing the user's settings to match your programming style. To use a PC analogy: If you are writing a web page only uses java script, and your page shows up wrong because a user turned off javascript, should your code turn on the user's javascript -- even only temporarily to display your web page -- and then turn it off? Or should your web page be designed to account for no java script settings? I wrote sample code on how to bypass all the issues with the angle mode though it is limited to only HAngle. It would not be difficult to adjust it to account for AAngle as well.

Code:


EXPORT EXAMPLE()
BEGIN
  // let's say we like programming with "radian" values
  COS(ANG(PI/2)); // we expect this to be 0
END;

ANG(a)
BEGIN
  CASE
    // current app angle is in degrees; change our radian angle to degrees
    IF AAngle AND (AAngle==2) THEN RETURN(a/PI*180); END;

    // current app angle is 0; check HAngle; if HAngle==1 then convert
    IF (AAngle==0) AND HAngle THEN RETURN(a/PI*180); END;

    // all other settings are radians; so no conversion needed
    RETURN(a);
  END;
END;

If you would rather temporarily change a user's settings, however, then change AAngle within your program, not HAngle. And of course, make sure to restore it so you don't break the app (though the author of such an app should likewise code in such a way that this shouldn't be an issue).

[Han]

(01-05-2014 05:14 PM)Michael de Estrada Wrote:  IMO, what would be natural is for the program to at least temporarily override the angle setting during its execution.

In the sense of a compiler option? That would be nice. Let's keep our fingers crossed.

[Michael de Estrada]

Actually, your code would not be useful for the program I'm using, since the variables are dummies used in calls to the CAS solver, where trig and hyperbolic functions are used that require radians mode. I know that I can use a complicated workaround, but why should I have to do this ? Personally, I think the way the Prime operates creates unnecessary confusion and complexity.

[Han]

(01-05-2014 07:31 PM)Michael de Estrada Wrote:  Actually, your code would not be useful for the program I'm using, since the variables are dummies used in calls to the CAS solver, where trig and hyperbolic functions are used that require radians mode. I know that I can use a complicated workaround, but why should I have to do this ?

You don't have to. It's just my own person preference not to ever touch a user's settings. I have had to many students complain to me that they aren't getting the right results because they ran some program that changed their angle settings. The most egregious cases were games (on the HP48) that took over interrupts and left the user's clock and date completely time-shifted!

Anyway, you can always just force the angle mode to whatever you want -- just please make your program also re-instate the user's settings. Does the following work in your case?

Code:


LOCAL usrang=AAngle; // back up user settings
AAngle:=1; // set radian mode; non-zero value also overrides HAngle

// do your stuff here

AAngle:=usrang; // restore user angle mode

You can even encapsulate this into a "wrapper":

Code:


// usage: RUNRAD("Program(arg1, arg2)")
EXPORT RUNRAD( prg );
  LOCAL usrang=AAngle;
  AAngle:=1;
  EXPR(prg);
  AAngle:=usrang;
END;

The only issue here is if the user presses the [On] key to interrupt the program, then AAngle may not be restored properly.

Quote:Personally, I think the way the Prime operates creates unnecessary confusion and complexity.

While I do think the Prime does have a bit of complexity to it, I think this particular issue is fairly easy to understand once you get accustomed to the fact that an app is always in view, and the hierarchy of AAngle and HAngle.