UserRPL local variables not available to algebraics? - Printable Version +- HP Forums (https://archived.hpcalc.org/museumforum) +-- Forum: HP Museum Forums (https://archived.hpcalc.org/museumforum/forum-1.html) +--- Forum: Old HP Forum Archives (https://archived.hpcalc.org/museumforum/forum-2.html) +--- Thread: UserRPL local variables not available to algebraics? (/thread-215867.html) UserRPL local variables not available to algebraics? - John R. Graham - 03-28-2012 I can't imagine that this topic hasn't been covered, but I couldn't find it. I don't usually do algebraic notation, so maybe I'm missing a nuance here. I was helping my college age son write a program where he wanted to evaluate an algebraic expression stored in a global variable against stack supplied variables. Simple, I thought. Just define local variables that match variables in the algebraic. However, local variables don't appear to be available to an algebraic. I can store the named variables in globals with STO and the algebraic can access them, but not if they're local. Is it possible to define local variables in such a way that the algebraics can see them? Compiled local variables don't appear to work either. - John Re: UserRPL local variables not available to algebraics? - Paul Dale - 03-28-2012 At a guess the local variables would have to exist at the point the algebraic object is defined for them to be referenced correctly. In the absence of this, they'll be interpreted as global variables. - Pauli Re: UserRPL local variables not available to algebraics? - Gerry Schultz - 03-28-2012 I thought local variables were created at the time the program is run and only last as long as the program is executing. So if the values are located on the stack, I would think you would write the program to use the values on the stack or re-write the program to prompt for the values of the newly declared local variables when executing the program. Am I missing something? Gerry Re: UserRPL local variables not available to algebraics? - Paul Dale - 03-28-2012 Locals are created when a program is run and destroyed when it finishes. What happens if you put a STOP in such a program? What about executing something like -> a b << 'a*b+4' 'EQN' STO >> from the command prompt? There are ways to have an active input and local variables defined. - Pauli Re: UserRPL local variables not available to algebraics? - Luiz C. Vieira (Brazil) - 03-28-2012 Hi. Can you post the command line contents you used? Cheers. Luiz (Brazil) Re: UserRPL local variables not available to algebraics? - Luiz C. Vieira (Brazil) - 03-28-2012 Hi. Depending on the calculator you use, given a and b in the stack you'll have only the evaluated value stored in 'EQ' (e.g.: HP28C/S). The equivalent to STOP in this case would be HALT, IIRC. Cheers. Luiz (Brazil) Re: UserRPL local variables not available to algebraics? - Kiyoshi Akima - 03-29-2012 ```<< -> a b << 'a+b' EVAL >> >> ``` This program does the expected thing on the 50g, adding the first two elements on the stack. Edited: 29 Mar 2012, 2:21 a.m. Re: UserRPL local variables not available to algebraics? - Alexander Oestert - 03-29-2012 Assume you STO the following in 'ALG' <<'A*B' >> and this in 'TST' << A STO B STO << ALG >> EVAL ->NUM {A B} PURGE >> then you put say 5 and 6 on stack lines 1: and 2: and press TST from the VAR menu, you will have 30. on line 1: of the stack. The program uses A STO B STO instead of -> A B to make A and B global variables in order for 'ALG' to be able to see them. The PURGE is necessary because any subsequent run of TST could not STO A and B again when they already exist. The algebraic expression STOed in 'ALG' however continues to exist after the program is run. Edited: 29 Mar 2012, 2:16 a.m. Re: UserRPL local variables not available to algebraics? - Marcus von Cube, Germany - 03-29-2012 Quote: The PURGE is necessary because any subsequent run of TST could not STO A and B again when they already exist. Wouldn't 'A' STO 'B' STO solve this dilemma? Re: UserRPL local variables not available to algebraics? - Alexander Oestert - 03-29-2012 Quote: Wouldn't 'A' STO 'B' STO solve this dilemma? Yes and no. Doing it your way would make a subsequent program run possible as A and B could be used again without being PURGEd before. But after the program run A and B would still exist in the VAR menu as they are global variables. John asked for local variables, so I assumed he wanted them to not exist beyond the scope of the program. My way is the closest I could get to that. Edited: 29 Mar 2012, 2:33 a.m. Re: UserRPL local variables not available to algebraics? - Paul Dale - 03-29-2012 Try this instead: `<< 0 0 -> A B << 'A*B' >> 'ALG' STO >> EVAL` Local variables in an algebraic expression. The way to use them would then be in a program: `<< -> A B << ALG EVAL >> >>` - Pauli Re: UserRPL local variables not available to algebraics? - Alexander Oestert - 03-29-2012 Very nice and elegant! OT When will the WP-34s have RPL and an algebraic mode? ;-) Re: UserRPL local variables not available to algebraics? - C.Ret - 03-29-2012 Quote: ```<< -> a b << 'a+b' EVAL >> >> ``` The following syntax will do it as well : ` << -> a b 'a+b' >>` In HP28C/S manual it is call analytical user's function. Compare to your program strucure code, this can be formaly derivate or integrate as any other built-in analytical function of the system. Re: UserRPL local variables not available to algebraics? - cyrille de Brébisson - 03-29-2012 Quote: I don't usually do algebraic notation, so maybe I'm missing a nuance here. I was helping my college age son write a program where he wanted to evaluate an algebraic expression stored in a global variable against stack supplied variables. Simple, I thought. Just define local variables that match variables in the algebraic. However, local variables don't appear to be available to an algebraic. I can store the named variables in globals with STO and the algebraic can access them, but not if they're local. hello yes, but what you need to understand is that when an object is compiled (when you press ENTER on something), names will be compiled as local variables ONLY if the local exists at that time... so, doing: 'A+B' 'C' STO followed by calling C EVAL in a program when A and/or B are local variable will cause A+B to still refer to the GLOBAL variables as local A/B did not exist at that point... also, doing: 2 'A' STO << 0 -> A << 'A' 1 -> A << EVAL >> >> will return 1 because when 'A' was compiled, a local variable A DID exist and 'A' will evaluate a local, in this case the A containing 1... doing: 2 'A' STO << 0 -> A << 'A' 1 -> A << >> >> EVAL will err as there is no more local A when 'A' is evaluated... cyrille Re: UserRPL local variables not available to algebraics? - Dave Britten - 03-29-2012 This is the most important (and most confusing) part, since there's no easy visual indication of how it was compiled. You can use TYPE to determine if a name is local or global, though (I forget the return codes, but it's different for the two). Re: UserRPL local variables not available to algebraics? - John R. Graham - 03-29-2012 Hi, Luiz. Something funny going on here. The calculator in question is a 50g, by the way. I have a global variable named 'Eqn' with value '2*X^2+9*X+7'. The program I am trying is as follows: ```<< -> X << Eqn EVAL >> >> ```The EVAL doesn't touch the quoted algebraic, leaving it on the stack unmodified. Here's the funny thing, though. If I include the same equation literally in the program, like so ```<< -> X << '2*X^2+9*X+7' EVAL >> >> ```then it works properly, evaluating the algebraic. In addition, if I create a global variable X, the much less elegant ```<< 'X' STO Eqn EVAL 'X' PURGE >>```works. This seems to hinge on the absence of the inner << >> program quotes. Restoring them seems to mask the local variable X from the algebraic in some very specialized circumstances. - John Edited: 29 Mar 2012, 11:07 a.m. after one or more responses were posted Re: UserRPL local variables not available to algebraics? - John R. Graham - 03-29-2012 Cyrille, Thanks. This is exactly consistent with the symptoms I'm seeing (see my reply to Luis above). If I create the proper local variable context, do you know how I can force a recompile of the algebraic expression? - John Re: UserRPL local variables not available to algebraics? - Paul Dale - 03-29-2012 You must create the expression inside a context that has the local variables defined. You might be able to convert the expression to a string, create the context and then convert it back. - Pauli Re: UserRPL local variables not available to algebraics? - Alexander Oestert - 03-29-2012 See below the different ways how to make this work in a program. You might want to try an entirely different approach: By pressing Eqn in the VAR menu put the algebraic expression on the stack. Then press the silver down arrow, by that entering the expression in the EQW writer. Then [right shift] [TOOL] (the orange pipe operator|). You will get the = right to your expression with a blinking cursor arrow. Enter X on its left side and the value you want to evaluate the expression with on its right side, say X=5. Press ENTER. Press EVAL. Press EVAL again. The numerical result is on the stack. Re: UserRPL local variables not available to algebraics? - Marcus von Cube, Germany - 03-29-2012 Shouldn't something like 'A+B' 'EQ' STO << -> A B << EQ ->STR OBJ-> EVAL >> >> work? Re: UserRPL local variables not available to algebraics? - John R. Graham - 03-29-2012 Okay, good suggestion! The following ```<< -> X << Eqn ->STR OBJ-> EVAL >> >> ``` works just fine. Understanding the precompilation nuance makes all the difference. It's pretty abstruse, though. Thanks very much to Cyrille, Pauli, and Marcus. - John Edited: 29 Mar 2012, 10:10 a.m. Re: UserRPL local variables not available to algebraics? - Kiyoshi Akima - 03-29-2012 Try it this way: ```'2*<-X^2+9*<-X+7' and << -> <-X << Eqn EVAL >> >> ``` In your approach the local variable X is not defined at the point Eqn is defined. This is what compiled local variables are for. Re: UserRPL local variables not available to algebraics? - Luiz C. Vieira (Brazil) - 03-29-2012 HI. In brief, just about the first part (I'm in a hurry now, will post more later), try ->NUM instead, like this: ```<< -> X << Eqn ->NUM >> >> ```It forces a numeric result. One of the EVAL rules is to keep a variable name once it is evaluated. I believe it will work the way you want. The second part is correct, once another EVAL rule is to replace variables for their contents when an algebraic is evaluated. Bill Wickes' 'HP48 Insights' has great material about this. Cheers. Luiz (Brazil) Edited: 29 Mar 2012, 1:42 p.m. Re: UserRPL local variables not available to algebraics? - Eric Smith - 03-29-2012 The key point is that the local variable has to be in scope at the time that any reference to it is compiled. You can't do something like this: 'a+b' 'foo' STO << -> a b foo >> 'bar' STO 3 7 bar because at the time you define foo, the compiler has no reason to expect a and b to be local variables, and compiles them as globals. Re: UserRPL local variables not available to algebraics? - Gilles Carpentier - 03-29-2012 Hi John another way could be : ```« -> X « Eqn {X , 'X'} | EVAL » » ``` Works fine I don't know what you want to do with the global Eqn, but why not something like this : `'Eqn(X)=2*X^2+9*X+7' DEFINE ` Then 5 Eqn or 'Eqn(5)' EVAL does the job or if you want to keep Eqn exactly as '2*X^2+9*X+7' ```'2*X^2+9*X+7' 'Eqn' STO 'F(X)'Eqn = DEFINE ``` Then 5 F or 'F(5)' EVAL or 'Y' F or 'Y^2+9' F or what you want if you need to work in symbolic way Edited: 29 Mar 2012, 4:31 p.m. Re: UserRPL local variables not available to algebraics? - Gilles Carpentier - 03-29-2012 Note that this way works (replace the <- by arrows) : ```'<-a+<-b' 'foo' STO « -> <-a <-b « foo EVAL » » 'bar' STO 3 7 bar ``` but it's awfull in my opinion and i don't see any interest of that. Re: UserRPL local variables not available to algebraics? - cyrille de Brébisson - 03-31-2012 Actually, there is something that you can do... If my memory serves me well (and I do not have a 50 around me for testing), ANY variable that starts with a forward? arrow is ALWAYS compiled as a LOCAL.. so you should be able to do '>A+>B' << 1 2 > >A >B << EVAL >> >> and it should work.... I am just not 100% sure that the magic chr is that arrow.... cyrille Re: UserRPL local variables not available to algebraics? - Luiz C. Vieira (Brazil) - 03-31-2012 HI. Wouldn't it be the left-arrow? Like this:`'<-A + <-B' << 1 2 -> <-A <-B << EVAL >> >>`At least this 'left-arrow' being used to define/create compiled variables is what I remember reading about at James Donnelly's "The HP48 Handbook". Cheers. Luiz (Brazil) Edited: 31 Mar 2012, 2:48 a.m. Re: UserRPL local variables not available to algebraics? - Paul Dale - 03-31-2012 If this is true, I've learned something. Pity my 48SX and 49G are both dead and my 28S has no battery door so I can't test. - Pauli Re: UserRPL local variables not available to algebraics? - Luiz C. Vieira (Brazil) - 03-31-2012 Hi, Paul. I checked my October 1994, 2nd. Edition volume, p. 46, and the ID for compiled local variables is indeed the preceding left-arrow character. I am not sure about after which model it was implemented, the cover picture of Donnelly's book has an HP48GX. Do not know if the 48S/SX or the 28C/S had such feature. Cheers. Luiz (Brazil) Re: UserRPL local variables not available to algebraics? - Gilles Carpentier - 04-05-2012 I tried on my old 48sx but I can not remember how to enter such a char on a SX (back arrow) . There is no CHARS menus on the 48SX ... Re: UserRPL local variables not available to algebraics? - Paul Berger (Canada) - 04-05-2012 To get left arrow it alpha R-shift(blue) cursor left key, same as on a 48G. Re: UserRPL local variables not available to algebraics? - Alexander Oestert - 04-05-2012 As far as I can tell from the manual of the 48sx and an actual side-by-side test of the 48s and the 48g, the 48s doesn't have local compiled variables available, the 48g does. EDIT for clarification Edited: 5 Apr 2012, 1:55 p.m. after one or more responses were posted Re: UserRPL local variables not available to algebraics? - Gilles Carpentier - 04-05-2012 Just tested : It works on my 49 but not on my 48SX