HP-48G local variables within subroutine

[grbrum]

Hello. Can someone help with the syntax of using local variable being used in subsequent formulas?
Example
<< -> a b ‘a/b’ ‘ b*b’ >>

In this example I want to load the stack with a and b and the output to be a/b and a*b
the manual makes reference to using a left arrow key( alpha+right shift+left arrow)
But I don’t find an example of the syntax.

Thanks

[FLISZT]

(05-16-2023 11:41 PM)grbrum Wrote:  …
<< -> a b ‘a/b’ ‘ b*b’ >>
…

As written, you program won't work.

With, for example, a=2 and b=4, you get: 1/2 and 'b*b'.
Only the first part of what you want is evaluated.

If you change your program by:
<< -> a b ‘ b*b’ ‘a/b’ >>
then you obviously get (always with a=2 and b=4) 16 and 'a/b'.

So, in algebraic notation, the program should be something like:
<< DUP UNROT -> a b ‘a/b’ SWAP -> b ‘ b*b’ >>
A bit cumbersome because you have:
1) to think about the movements of values in the stack;
2) to declare a new local variable "b".

Instead, try this :
<< -> a b << a b / b b * >>
You'll get 1/2 and 16.

Now, let's call the above program SUBR.
If this SUBRoutine is called by an other program then you have to use "compiled local variables".
And so, SUBR becomes :
<< -> <-a <-b << <-a <-b / <-b <-b * >>
(no space between the left arrow and the name of the local variable)

For a better visualization:

Code:

« → ←a ←b 
     « ←a ←b / 
       ←b ←b *
     »
»

The calling program could be something like:
<< … value1_onStack value2_onStack SUBR … >>

Hope it helps.

Edit: typos

[grbrum]

Hello. This was perfect. Great lesson. Thanks

[FLISZT]

(05-17-2023 03:21 AM)grbrum Wrote:  Hello. This was perfect. Great lesson. Thanks

Hello,

Far from perfect: I did another typo!

I forgot the left arrows in the initialization (first line) of the variables "a" and "b" :

Code:

« → ←a ←b    
     « ←a ←b / 
       ←b ←b *
     »
»

But you probably realized that.
I'm hopping again !

[Werner]

(05-17-2023 01:58 AM)FLISZT Wrote:  If this SUBRoutine is called by an other program then you have to use "compiled local variables".

There is no reason to use compiled local variables here.
If your subroutine was simply
DIVMUL « a b / b DUP * »
and you called it from another program that defined a and b, eg
MAIN « → a b 'DIVMUL' »
then you would need compiled local variables, because when creating DIVMUL, a and b are GLOBAL variables while when calling DIVMUL from MAIN they should be local.
So, create DIVMUL as
DIVMUL « ←a ←b / ←b DUP * »
and MAIN as
MAIN « → ←a ←b 'DIVMUL' »

Cheers, Werner

[FLISZT]

(05-17-2023 07:22 AM)Werner Wrote:  There is no reason to use compiled local variables here.
…

Oh yes! Absolutely!
I saw "left arrow" in grbrum's post and I didn't think enough.
Lack of sleep... I need to go to bed.

Best regards

[Boub65]

Hello and thanks for the examples.
My question is how can I use a local variable to do intermediate calculations within a subroutine that is NOT arguments transmitted to the subroutine NOR global variables.
For example I want to put a * b in "local variable" local_c to use it later in the subroutine.
Example :
《 -> a b 《 a b * 'local_c' STO then use local_c in this subtoutine... 》》

The scope of the local variable local_c would be restricted to the subroutine and we would not find it in the global variables (using VAR) after the subroutine ends. aka LSTO in Free42.
I hope I am clear enought?

[2old2randr]

You can do
« 0 → a b c « a b * c STO ... » »
i.e., push 0 onto the stack and then assign to 'c' over the same scope as 'a' and 'b'.

Another way would be
« → a b « a b * → c « ... » » »

The second form may be preferable when you have deeply nested code. Here 'c' is visible only in the innermost scope.

[FLISZT]

Hello,

@Boub65
If I understand you correctly, in your example a local variable named (e.g.) local_c could exist in the main program but also in a subroutine.

⇒ First possibility

As 2old2randr explains, you can use nested code(s) in the main program kind.

⇒ 2nd possibility

Now, you need to use the variable local_c in both a main program and one (or more) distinct subroutine(s); then local_c must be a compiled local variable.
This is the only case where compiled local variables are needed. Their names begin always with a left arrow: ←local_c
This type of variable did not exist on hp-28. It must have been created for the 48G/GX/G+ serie, if I'm not mistaken, and was kept for later RPL models.

So, one example:

Main program

Code:


<< → a b ←c   @ declaration/initialization of the local variables / compiled or not
   << ... called_SUBR ...
   >>
>>

called_SUBR

Code:


<< → d e f … @ possible local variables specific of the subroutine / they may be called a, b, c, but beware of confusion…
   <<
      ... ←c ...   @ use of the compiled variable c previouly declared/initialized in the main program
   >>
>>

And don't forget that a variable, whether local or not, compiled or not, can contain any kind of object: numbers and strings of course, but also algebraic objects, lists, pieces of code (which can be, if needed, some kind of functions that you can carry anywhere in your application), the name of another variable... and even a directory.
It's just a matter of need, taste and creativity.

Best regards

[grbrum]

(05-17-2023 06:00 AM)FLISZT Wrote:  

(05-17-2023 03:21 AM)grbrum Wrote:  Hello. This was perfect. Great lesson. Thanks

Hello,

Far from perfect: I did another typo!

I forgot the left arrows in the initialization (first line) of the variables "a" and "b" :

Code:

« → ←a ←b    
     « ←a ←b / 
       ←b ←b *
     »
»

But you probably realized that.
I'm hopping again !

You pointed in the right direction and it worked. Thanks

[BruceH]

(05-17-2023 10:33 PM)2old2randr Wrote:  You can do
« 0 → a b c « a b * c STO ... » »
i.e., push 0 onto the stack and then assign to 'c' over the same scope as 'a' and 'b'.

Another way would be
« → a b « a b * → c « ... » » »

The second form may be preferable when you have deeply nested code. Here 'c' is visible only in the innermost scope.

Slight correction on the first version - c needs to be quoted in order to store into it.
« 0 → a b c « a b * 'c' STO ... » »

[Thomas Klemm]

(05-17-2023 07:22 AM)Werner Wrote:  There is no reason to use compiled local variables here.

Gerhard's recursive program to calculate OEIS A035327 was an eye-opener to me for the use of compiled local variables.
I used them in a program to create a list of combinations.
Otherwise I don't think I used them.