Understanding variables relative to the current active App

[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).