Verifying existence of a variable

The Museum of HP Calculators

HP Forum Archive 16

Verifying existence of a variable
Message #1 Posted by James Jones on 25 June 2006, 4:24 p.m.

Please excuse me if this is covered elsewhere. If it is, I haven't found it.
In a program, I want to store and retrieve the result of calculatgion in a matrix named M1.
Sometimes, I stop the program partway through the procedure and restart the next day.
It is a simple matter to have...

<< -> xin yin zin tin << .......... {calculations....result in the form of:}
[xout yout zout tout] Rownumber M1
{test dimensions of M1, redimension if needed}
{put vector [xout yout zout tout] into correct row of M1} >>
The problem I have not solved is "How to have the program test for the existence of M1 prior to running the program, because if M1 exists when I restart, then I do not want to re-initialize it.


Re: Verifying existence of a variable
Message #2 Posted by Han on 25 June 2006, 4:29 p.m.,
in response to message #1 by James Jones

It looks like your code is in RPL. Do you have an HP48 by any chance? If so, there is a command called VTYPE which takes a variable name and returns the type of object stored in that variable. If nothing is stored in that variable, a -1 is returned to the stack.

Quote:
Please excuse me if this is covered elsewhere. If it is, I haven't found it.
In a program, I want to store and retrieve the result of calculatgion in a matrix named M1.
Sometimes, I stop the program partway through the procedure and restart the next day.
It is a simple matter to have...

<< -> xin yin zin tin << .......... {calculations....result in the form of:}
[xout yout zout tout] Rownumber M1
{test dimensions of M1, redimension if needed}
{put vector [xout yout zout tout] into correct row of M1} >>
The problem I have not solved is "How to have the program test for the existence of M1 prior to running the program, because if M1 exists when I restart, then I do not want to re-initialize it.


Re: Verifying existence of a variable
Message #3 Posted by James Jones on 25 June 2006, 7:39 p.m.,
in response to message #2 by Han

Yes, I do have a 48. Actually 2, a 48g and a 48gx. I started with a 21, upgraded to a 41C when it first came out and finally got these 48's on sale in 1995 more or less.
I learned to use and program the 41C in one weekend, but the 48s were not what I expected, so they mostly sat for the past ten years.
Learning now to use them. It's not so bad.
Thank you for the info on VTYPE. It will be used!
Also, I figured out that merely putting the variable name into an

IFFERR Variablename THEN ELSE END
structure would not generate an error, but that putting the name there and then trying to RCL would generate an error which I could trap.
Two solutions in only one afternoon.


Re: Verifying existence of a variable
Message #4 Posted by Han on 25 June 2006, 11:05 p.m.,
in response to message #3 by James Jones

Here's another method. If you know the type of the object stored under a particular variable, you can also use the TYPE command:
IF M1 DUP TYPE 6 == THEN "Nothing stored in 'M1'" END
Notice that M1 is called; if nothing is stored in M1, then the variable name is simply placed onto the stack. Otherwise, the contents of the variable is called onto the stack.
May I also suggest the Advanced User's Reference Guide? It is freely available in PDF at www.hpcalc.org. This reference details every single built-in command in the HP48G/GX. There is also a similar guide for the HP48S/SX called the HP48 Programmer's Reference Guide (available on the CDs from this museum).
Han
Edited: 25 June 2006, 11:07 p.m.

Re: Verifying existence of a variable
Message #5 Posted by James Jones on 26 June 2006, 3:13 a.m.,
in response to message #4 by Han

Han,
Yes, the Advanced User's Manual. Downloaded. 764 pages. May not print it right away.
Thx for the other tip. I got the programs to work. Ode to Joy, etc.
If you don't mind, one other thing I need to figure out it this:
<< -> variablename << ..... yields a local variable for use within the program and it frees up memory after termination.
But, is there some way to declare other local variables which do not correspond to values on the stack?
-James
H

Re: Verifying existence of a variable
Message #6 Posted by James M. Prange (Michigan) on 26 June 2006, 3:48 a.m.,
in response to message #5 by James Jones

A local variable can't be created without a value (taken from the stack) to store in it.
What you can do is, at the beginning of the program, put "dummy" values on the stack and store them into local variables. Later, when you have something you want to store in one of these local variables, put its quoted name on the stack and use the STO command. For example:
%%HP: T(3); \<< @ Begin program. 0 0 0 @ Dummy values for local variables. \-> a b c @ Bind local variables. \<< @ Begin defining procedure for local variables. \<< @ Begin subprogram. "My subprogram, possibly using local variable 'b' or 'c'" \>> @ End subprogram, leaving it on stack. 'a' STO @ Store subprogram in local variable 'a'. @ Do whatever, using local variables 'a', @ 'b' and 'c' as desired. \>> @ End defining procedure, abandoning local @ variables. \>> @ End program.
Regards,
James
Edited: 26 June 2006, 9:09 a.m.

Re: Verifying existence of a variable
Message #7 Posted by James Jones on 26 June 2006, 11:54 a.m.,
in response to message #6 by James M. Prange (Michigan)

Actually, this is good news. It means I did not misread the manual. (ha!)
There does not need to be as many dummy variables as there are unique intermediate results, only as many as there are unique intermediate result at one time.
With graditude,


Re: Verifying existence of a variable
Message #8 Posted by GE on 28 June 2006, 6:13 a.m.,
in response to message #7 by James Jones

Beware that these local variables are not accessible from programs called from the program where they were created.
Example : program ZZZ creates local variable PPP.
ZZZ calls TTT.
TTT cannot access PPP.
Sad.

There is actually a way to circumvent this fatal flaw, it involves the use of a back arrow (<-) in front of the variable name, I have never dug that far. Now you know why I do't touch RPL even with a very long fork.

Re: Verifying existence of a variable
Message #9 Posted by Han on 28 June 2006, 12:54 p.m.,
in response to message #8 by GE

This is explained in the Advanced User's Guide. Any local variable whose name starts with the <- symbol has larger scope than one without.

Re: Verifying existence of a variable
Message #10 Posted by Marcus von Cube, Germany on 29 June 2006, 4:13 a.m.,
in response to message #8 by GE

Quote:
Beware that these local variables are not accessible from programs called from the program where they were created.
...
There is actually a way to circumvent this fatal flaw...
Visibility rules in structured languages typically don't allow the access to variables that a calling function defines from the called function, if the functions aren't nested, i. e. the called function is *defined* whithin the caller. (C and C++ don't have a means to nest functions in code, Java can do it by nesting classes.)
Assume the following:

A function 'FA' makes use of a variable named 'VA' which is assumed to exist outside the function, a global variable.
Another function 'FB' defines a local variable with name 'VA' for some internal purpose.
Now, 'FB' calls 'FA'. If 'VA' as defined in 'FB' were visible in the called function 'FA', an undesired side effect would occur.
If you really wanted 'FA' to modify the local variable 'VA' in 'FB' instead of a global variable, you need to nest the code. Then it's clear what is meant with the identifier 'VA'.
Marcus

[ Return to Index | Top of Index ]

Go back to the main exhibit hall