HP Forum Archive 17

[ Return to Index | Top of Index ]

Creating local variables in RPL Message #1 Posted by Les Wright on 20 Apr 2007, 10:09 p.m. I am wondering if there are any more elegant ways of creating local variables aside from using ->. I am trying to port some short C programs to the HP48/49, and since I haven't yet gotten to the stage where I do everything on the stack with things like PICK, DUP, and ROT I find I use quite a few local variables to keep track of things. In my programs, I am finding I have programs within programs, since local variable declarations need to be set apart from the routine in which they are used by <<. If I have, say, 8 local variables to declare, I have a rather inelegant declaration looking like this: << 0 0 0 0 0 0 0 0 -> a b c d e f g h << prgm >> >>. This of course is nested in another pair of <<>> brackets since I need to take my input off the stack into yet other local variables, so my overall program form may look like this: << -> x y << 0 0 0 0 0 0 0 0 -> a b c d e f g h << prgm >> >> >> This is my RPL analogy to a function in C of the form float func(x,y). Of course, I know that the zeros can (and should where possible) be initialized with values based on the x and y input, or whatever other starting values the program uses. My point is that this seems to be a rather complicated way to do a very simple thing. Am I over complicating this? I must admit I came up with this approach by trial and error--took me a few hours, for example, to figure out that a local variable declaration must be followed immediately by an opening <<. Grateful for whatever wisdom you can offer. Les

Re: Creating local variables in RPL Message #2 Posted by James M. Prange (Michigan) on 20 Apr 2007, 11:06 p.m., in response to message #1 by Les Wright I assume that you mean in UserRPL, as using local variables in SysRPL is rather different; more flexible, but perhaps more complicated. Try changing: << -> x y << 0 0 0 0 0 0 0 0 -> a b c d e f g h << prgm >> >> >> to: << 0 0 0 0 0 0 0 0 -> x y a b c d e f g h << prgm >> >> to create local variables x and y with two objects from the stack, and local variables a through h with initial values of 0, and then within << prgm >>, when the desired values become available, use 'a' STO, 'b' STO, etc. to replace the values of the existing local variables. Current ROM revisions (starting with 1.19-4) for the 49 series also include the commands LOCAL for creating and initializing local variables from a list and UNBIND for deleting local variables, but I think that they're intended for ALG mode, and I don't know whether they can be used in RPN mode. Regards, James

Re: Creating local variables in RPL Message #3 Posted by Ron Allen on 21 Apr 2007, 8:19 p.m., in response to message #1 by Les Wright I have had some similar problems with LOCALS. It seems that the syntax wants to follow the minimum control path here, but don't assume that I have it figured out yet. Here's what I think I know about it. First, the local variables want to serve only the current program and the one being called by the level defining such variables LOCAL. If you do use a compiler, you can be a little more flexible. Since you apparently use the documentation, I advise using the "Advanced User Reference Manual" AND THE USER MANUAL. They seem to combine at times to resolve some things. There is a method with a compiler, at least by indirect reference which might help some in your quest. Rather than try to paraphrase the method,I'll just point you to the subject - COMPILED LOCAL VARIABLES. This method ostensibly will allow you to use locals in all the succeeding program levels called directly in sequence after the initiating definition. This means that any definition performed at level 3 treats the COMPILED LOCAL designation using special naming convention will be treated as LOCAL within the sequence. Better research it yourself. Best of luck, Ron

Re: Creating local variables in RPL Message #4 Posted by James M. Prange (Michigan) on 22 Apr 2007, 3:34 a.m., in response to message #3 by Ron Allen In UserRPL: A procedure (program or algebric object) can use any local variable already existing or defined for it, provided that a more recently created local variable with the same name doesn't exist. In other words, an "inner" procedure can use a local variable defined for any "outer" procedure, but an outer procedure can't use any local variable defined only for its inner procedures. A new, entirely separate, local variable can be defined with the same name as an already existing local variable. Only the most recently created (inner-most) existing local variable with a particular name is accessible. Note that the index of FOR loop is actually a local variable, existing for as long as the loop is running, so suppose that I define a local variable n for a program, and then use n as a FOR loop index name; in that case, any use of n within the loop uses the loop index, not the local variable n previously defined for the program. Also, local names can be the same as command names, library command names, or global names. So you could have a local variable named, for example, SIN, or i, or e, in which case only the local variable could be accessed, not the command with the same name. If you use the HALT command, or various other commands that suspend program execution, any existing local variable is retained, and may be used while the "suspended environment" exists, as long as a newer local variable with the same name doesn't exist. I'd forgotten about "compiled local variables". Starting with the 48G series, any name beginning with a <- character will be compiled as a local name, even if a local variable with that name doesn't currently exist and isn't being created. This simplifies using a local variable within a program (to be stored in a global variable) which will be called by name from within another program which defines that local variable. But note that compiling the name as local doesn't actually create a local variable; to use a local variable, it has to be currently defined. If you try to evaluate a local name for which no local variable is currently defined, you get (what else?) an "Undefined Local Name" error. Regards, James

Re: Creating local variables in RPL Message #5 Posted by Ron Allen on 22 Apr 2007, 7:46 p.m., in response to message #4 by James M. Prange (Michigan) Thanks, James, for the details on local variables! As usual you show considerable research into the subject. I am sure you understand this structure as you do the rest of it. I am puzzled by the distinguishing characteristics between RPN and RPL PROGRAMMING. Is it somehow similar to BASIC in that it can be compiled by USERRPL or run under an Interpreter? There so many good things hinted at by the instructions, but they fail ME) to produce the end result I think I am reading into it. I think I will try to organize this thought in another post more on point by tomorrow and generate a question then. Kind of confusing in this topic. Ron

Re: Creating local variables in RPL Message #6 Posted by Les Wright on 22 Apr 2007, 10:23 p.m., in response to message #4 by James M. Prange (Michigan) Quote: In other words, an "inner" procedure can use a local variable defined for any "outer" procedure, but an outer procedure can't use any local variable defined only for its inner procedures. I have capitalized on this fact in a little routine I just wrote to compute the incomplete beta function by its continued fraction expansion. The local variables a, b, and x are used both in the outer procedure, and in the inner procedure that specifically computes the continued franction. Indeed, whether or not x < (a+1)/(a+b+2) determines whether a, b and x are passed "straight" to the inner procedure or whether b, a, and 1-x are passed to a, b, and x in the inner procedure and the complementary function is computed by a reflection formula. Despite James' initial advice, I have found that breaking up my local variable definitions in a "nested" way makes my programs easier to read and makes it very clear (at least to me) which procedure a local variable is local to. Les

Re: Creating local variables in RPL + RPL IN GENERAL Message #7 Posted by Ron Allen on 23 Apr 2007, 11:48 p.m., in response to message #6 by Les Wright Really enjoy the knowledge that flows between you two. I wonder if you or some will take on some relatively simple subjects, simple to many on this forum - but sometimes confusing to me. What is the essential difference between RPL and RPN? Is it like the difference in Excel between the live,interpreted language of RPN and the pre-programed structure of the same language, with some few exceptions, referred to as RPL? A language that can be programmed and compiled via C++ or other compilers into machine language for more rapid execution. Using the case of "COMPILED LOCAL" variables, is this a description of variables compiled by the machine language compiler or by the process that uses the interpreter level, RPL, being a structured object made up of RPN commands, etc.? In my book this would be very similer to BASIC INTERPRETER and QBASIC or VBASIC. By the way, I am speaking of the 50. So, does the COMPILED LOCAL VARIABLE have the flexibility discussed when it operates fully compiled as machine language or "compiled" as RPL? Is there a third alternative? One more question, please. Is my system up-to-date and ready to share with Excel and Word? I get "Version HP50-C Revision #2.08" Thanks, Ron Edited: 23 Apr 2007, 11:53 p.m.

Re: Creating local variables in RPL + RPL IN GENERAL Message #8 Posted by Karl Schneider on 24 Apr 2007, 12:52 a.m., in response to message #7 by Ron Allen Hi, Ron -- Quote: What is the essential difference between RPL and RPN? Flippant answer: RPN is like a sharp, no-nonsense dress shirt and trousers, but RPL is like a leisure suit. Serious answer: RPN is a means of calculation by postfix operation, in which operands are maintained in a stack, and operators are not stored, but are executed immediately upon request. RPL is an adaptation of RPN to an object-oriented LISP-like structure, in which all forms of data -- simple forms such as actual numbers or display-setting values, or compound forms such as entire programs, entire matrices, or algebraic expressions -- are represented as "object types" that are carried in a dynamic-depth stack. Operations invariably "consume" their inputs, so that compound inputs are not preserved for subsequent use or re-trial unless previously saved to a named variable. -- KS

Re: Creating local variables in RPL + RPL IN GENERAL Message #9 Posted by Ron Allen on 24 Apr 2007, 2:44 a.m., in response to message #8 by Karl Schneider Karl a favorite professor used to say, "There's no such thing as a flippant answer, just flippant questions." **************************************************** I always wondered how anyone could flunk a course in quantum theory when the possible answers to multiple response questions were: **************************************************** probably so probably not who knows who cares not sure about the "uncertainty" principle get a half-life! ****************************************************** Seriously, Karl. Thanks! Edited: 24 Apr 2007, 2:01 p.m.

[ Return to Index | Top of Index ]

Go back to the main exhibit hall