Global variable

[Powersoft]

In this layout of my program I have 3 EXPORT procedures.
My main procedure is Plan13(t). I will need a lot of global variable.
How can I get the variable X in Plan13() as global for INITSAT() and
SATVEC().

Thanks for any help.

Code:


EXPORT SET_OBSERVER()
BEGIN
END;

EXPORT SET_TIME() // Set cime to calculate TSince
BEGIN
END;

INITSAT() // Init Satellite
BEGIN
END;

SATVEC() // Calc position and speed Satellite
BEGIN
print(X); // test
END;

EXPORT SET_TLE()
// Set TLE variable in List L1
BEGIN
  LOCAL YE,TE,IN,RA,EC,WP;
  LOCAL MA,MM,M2,RV;
  INPUT({YE,TE,IN,RA,EC,WP,MA,MM,M2,RV},"TLE",{"YE","TE","IN","RA","EC","WP","MA","MM","M2","RV"});
  L1:={YE,TE,IN,RA,EC,WP,MA,MM,M2,RV}; //will be used in other routines
END;

//-------------sequence---------------
// 1. set TLE
// 2. set time
// 3. init Satellite
// 4. do calations


EXPORT Plan13(tsince) //Main programm
BEGIN
  LOCAL X;
  X=10;
  SATVEC(); // Calculate X,Y,Z,vX,vY,Vz
END;

[DrD]

(06-25-2017 06:56 PM)Powersoft Wrote:  How can I get the variable X in Plan13() as global for INITSAT() and
SATVEC().

Thanks for any help.

HOME Reserved variables (Upper case), such as 'X' are global, by default. (Note uppercase X is not declared as a Local variable...)

Example:

Code:


EXPORT temp()
BEGIN
  X:=PI;
END;

Now at the command entry line, type X and you will see that it contains PI as set in the program, and can be used globally.

[cyrille de brébisson]

Hello,

As a general rules, try to reduce the use of global variables.
Global variables (exported or not), in theory, should be limited to variables that needs to live PAST the end of the execution of the program.

While it is true that using a global variable is an easy way to deal with data that needs to be used by multiple functions, it is much cleaner to pass said data to the functions as parameters and have them be local variables of the calling function. This usually avoids a lot of problems!

If you indeed have a LOT of variables, you can group them in a list passed as a parameter and use the list sto/recal syntax to access them.

They are a number of home global variables (L1, A-Z...), but using them in programs, although easy, is not the cleanest way to do things. You should use your own variables as much as you can.

Cyrille

[DrD]

I like to use reserved variables in programs, as they are very efficient. For example, they don't have to be explicitly declared. They live beyond program execution. They are very useful for debugging, or further, (external), processing.

While a program is operating, the content of global variables is manageable. The content TYPE is always known. While there is no guarantee that outside influences might not, subsequently, modify reserved, (or other global variables), that content remains under program control within the program. The data is changeable externally. (So don't use global's for constants)! Use of global variables is a programming simplification, one that all levels of programming experience can appreciate.

Cyrille, can you explain a little further why the use of global variables is not a good idea, or why they should generally be avoided? Perhaps, due to system memory management issues, etc.? (Very infrequently, I have had to "Reset" the emulator, for example. I have not had to do that with the physical calculator, so far). Also, (so far), I have not encountered any downside to using Reserved variables, and I have used them frequently.

An enhancement suggestion: creation of a HOME "RESTART" version of the CAS "restart" command to reset all Reserved variables to their initial value, with [options] for [A]LL reserved variables, or to omit [L]ists, [M]atrices, etc.

As usual, I appreciate your greater knowledge, and look forward to learning from your explanations!

-Dale-

[toml_12953]

(06-26-2017 05:27 AM)cyrille de brébisson Wrote:  Hello,

While it is true that using a global variable is an easy way to deal with data that needs to be used by multiple functions, it is much cleaner to pass said data to the functions as parameters and have them be local variables of the calling function. This usually avoids a lot of problems!

Cyrille

If we could pass parameters by either reference or value instead of just by value, we could eliminate most global variables. This would also save space when passing large arrays.

[Han]

(06-26-2017 11:48 AM)DrD Wrote:  I like to use reserved variables in programs, as they are very efficient. For example, they don't have to be explicitly declared. They live beyond program execution. They are very useful for debugging, or further, (external), processing.

While a program is operating, the content of global variables is manageable. The content TYPE is always known. While there is no guarantee that outside influences might not, subsequently, modify reserved, (or other global variables), that content remains under program control within the program.

This is the biggest reason to NOT use (system, i.e. reserved) global variables. I am of the opinion that these variables should be left to the user for quick on-screen calculations -- much like in the days of old where scientific calculators only had a few registers to save partial computations. Programs should have their own variables; more on why below.

Quote:The data is changeable externally. (So don't use global's for constants)! Use of global variables is a programming simplification, one that all levels of programming experience can appreciate.

You can still access non-exported variables for debugging purposes using their fully qualified names.

Quote:Cyrille, can you explain a little further why the use of global variables is not a good idea, or why they should generally be avoided? Perhaps, due to system memory management issues, etc.? (Very infrequently, I have had to "Reset" the emulator, for example. I have not had to do that with the physical calculator, so far). Also, (so far), I have not encountered any downside to using Reserved variables, and I have used them frequently.

When several programs start using the same reserved variables, and those programs should happen to call each other, then you can easily imagine the mess that could result. But the other (bigger) reason for avoiding them is if a user makes frequent use of these variables for their own quick calculations, then your program could very well destroy their data. My personal philosophy is that all programs should never touch a user's data and leave every global variable, setting, flag, etc. as they were unless the program is designed to explicitly modify the user's data and/or system settings.

Quote:An enhancement suggestion: creation of a HOME "RESTART" version of the CAS "restart" command to reset all Reserved variables to their initial value, with [options] for [A]LL reserved variables, or to omit [L]ists, [M]atrices, etc.

As usual, I appreciate your greater knowledge, and look forward to learning from your explanations!

Home "restart" seems like a good command for users; but as a programming command I would probably never use it (again, to preserve the user's data/settings).

I do not speak for Cyrille, of course, or anyone else for that matter; just my 2 cents.

[DrD]

(06-26-2017 03:09 PM)Han Wrote:  When several programs start using the same reserved variables, and those programs should happen to call each other, then you can easily imagine the mess that could result. But the other (bigger) reason for avoiding them is if a user makes frequent use of these variables for their own quick calculations, then your program could very well destroy their data. My personal philosophy is that all programs should never touch a user's data and leave every global variable, setting, flag, etc. as they were unless the program is designed to explicitly modify the user's data and/or system settings.

Programmer's willing to use global's must consider the consequences. What you see as a pathway to trouble, I see as potentially added value. Every program step must be considered, if there is a reasonable expectation for success. Global variables are no different, and is yet another tool that can offer efficiency. My personal philosophy is, I see greater value in the global features, and no more risky than a myriad of other existing commands or functions.

I agree with your personal philosophy, and see no contradiction between us, where you say, " ... unless the program is designed to explicitly modify the user's data and/or system settings." Globals imply that there is a design to explicitly modify them, (or not). The debug advantage, or post processing advantage, and no requirement to declare them 'efficiency', are all good reasons to justify globals. I have come up with many programs, some just created in passing, or for examples, and some more robust that are in my master program list, that use globals exclusively, or in a mix combination with locals. To date, I have not seen any ulterior consequences, perhaps other than my own development pains, but nothing in the final work, that use of globals made into a mess.

Other than fear of ambiguous scenario's that "could happen," are there any tangible reasons not to use globals, that you can think of? Sure, you can create a program, and destroy the global data content it relies on, but such a program still works as you designed it. Thus its not a tangible reason to blame the use of global's for those consequences. The same can be said for any other aspects of a program structure. A program is only as good as its actual design, warts and all.

[Han]

(06-26-2017 04:02 PM)DrD Wrote:  

(06-26-2017 03:09 PM)Han Wrote:  When several programs start using the same reserved variables, and those programs should happen to call each other, then you can easily imagine the mess that could result. But the other (bigger) reason for avoiding them is if a user makes frequent use of these variables for their own quick calculations, then your program could very well destroy their data. My personal philosophy is that all programs should never touch a user's data and leave every global variable, setting, flag, etc. as they were unless the program is designed to explicitly modify the user's data and/or system settings.

Programmer's willing to use global's must consider the consequences. What you see as a pathway to trouble, I see as potentially added value. Every program step must be considered, if there is a reasonable expectation for success. Global variables are no different, and is yet another tool that can offer efficiency. My personal philosophy is, I see greater value in the global features, and no more risky than a myriad of other existing commands or functions.

I agree with your personal philosophy, and see no contradiction between us, where you say, " ... unless the program is designed to explicitly modify the user's data and/or system settings." Globals imply that there is a design to explicitly modify them, (or not). The debug advantage, or post processing advantage, and no requirement to declare them 'efficiency', are all good reasons to justify globals. I have come up with many programs, some just created in passing, or for examples, and some more robust that are in my master program list, that use globals exclusively, or in a mix combination with locals. To date, I have not seen any ulterior consequences, perhaps other than my own development pains, but nothing in the final work, that use of globals made into a mess.

Global variables, from a design point of view, are there so that users do not have to declare them for every use. Imagine for a moment if global variables did not exist from a user standpoint (and without even brining in programs into the picture). Such a setup would be very tedious. I am sure that this is only one of the reasons for the existence of (system) global variables. That their availability it is also a convenience to the programmer does not mean that programmers should just haphazardly modify the contents of such global variables. If your programs are for your own personal use, then I see no problem. But if you were publishing your programs, then I think it is plainly a matter of courtesy in not tampering with the global variables -- or at least restoring their contents after completion.

Quote:Other than fear of ambiguous scenario's that "could happen," are there any tangible reasons not to use globals, that you can think of? Sure, you can create a program, and destroy the global data content it relies on, but such a program still works as you designed it. Thus its not a tangible reason to blame the use of global's for those consequences. The same can be said for any other aspects of a program structure. A program is only as good as its actual design, warts and all.

Just because a program runs without bugs does not mean it cannot have undesirable effects. As already stated, if your programs are for public consumption, and they modify the users' data already existing in (system) global variables, then I think that is bad practice (just my own personal opinion). Sure, they make debugging and programming easier, but you can access any program's variable from the command line -- even if not exported -- by simply fully qualifying them. And their contents persist even after the program ends. So there really is no reason to be using system variables once you are at the stage of publishing your program. Lastly, even if you do use the global variables, a quick search and replace (with locals) once your coding is complete would also ensure that user data will never get tampered by your programs. If that is too much trouble, even a wrapper program which stores the user's contents prior to running, and restoring them after completion, would be preferable in my opinion.

Code:


UserData:={};

mywrapper()
begin

// program modifies L1 and L2
UserData:={}; // force reset
UserData(0):=L1;
UserData(0):=L2;

myprogram();

// restore L1 and L2
L1:=UserData(1);
L2:=UserData(2);

end;

EDIT: I would even go as far as to suggest minimizing the use of EXPORT.

[DrD]

For published programs, or public consumption in general, I have to agree that using reserved variables can become an interference to pre-existing user data. This can be a preventable issue, as you've shown, if care is taken to back-up, then restore data at the end of the program. I have never published a program, per se. I have contributed suggestions designed to help others, which may have had that side effect, though. So in that sense, this IS a tangible reason to avoid using them.

On the other hand, I don't use reserved variables to store data that must be non-volatile. If lists or matrices are important enough to reside without compromise, I make a back up of the calculator, or use other variables to back up the reserved ones. The device itself is prone to 'issues' that, sometimes, make it necessary to Reset the device, clearing all memory. So the mere act of ever using reserved variables as some kind of permanent memory, is placing that data at risk.

[cyrille de brébisson]

Hello,

- About system global variables in HP Prime (specific to this setup).
These variables are intended, and used, by users in home calculations. They often will have data in them which is of value to them. As a result, a "proper" program should NOT modify them (unless it is it's explicit purpose).

Now, if one is creating a program for his personal use without any intention to give it to others, he can do as much collateral damages as he wants.
Also, use of these variables, especially for a beginner programmer who is migrating from "home screen user" to "automation" and then "programming", make the learning of programming easier.
The availability of these variables also makes development of a quick and dirty program easy...

These reasons are why these variables are available in programs.


- About global variables in a program (in general, and here we are starting to get into programming philosophy)

Use of global variables in a program/function means that your function is not independent anymore but dependent on a global state. This makes your function much harder to test and debug. It also means that you can call the function twice with the same parameters and get a different result! (don't they say that the person doing the same thing twice and expecting a different result is crazy?)...
As a general rule, global should be avoided (if/when practical and possible).

Of course, we all know that this is not always practical, which is why global exists, however minimizing them is usually a good practice.

- About global variables in Prime.
PPL offers a LOT of different ways to handle variables (global or not)... Without even going into the CAS stuff... and you should always try to use the most adapted one...

Home and app system variables (like A-Z, L2, XMin....) These should be left alone except if you explicitly intend on modifying them.

Home and app user variables (HVars and AVars). HVars should also be left alone, however AVars are fair use for the app program as they are part of the app state of which the program belong to. Their explicit aim was to allow app program to maintain some state in between compilations.

Program globals
They come in 2 favors: exported and non exported. Both have the same life span (they get reset when the program source gets edited). Both are available from outside the program (with full qualification for the non exported ones). They should be your first choice when you need a program global

program locals
function parameters and variables defined by local.

As stated, the only thing missing is a pass by reference... Although you could do it using expr... but this is kludgy...

As I said above, lots of choices! but as a general rule, you should try to always use the most restrictive version as it is the least likely to cause troubles.

Cyrille

[DrD]

Thanks for the guidance, Cyrille. Normal usage in my case hasn't included the wider effects of publishing, or mixing with other external situations. Han's points, and your guidance have revealed important things to consider, when using global variables. Convenience always comes at a cost ...

-Dale-