New to RPL; Please critique this working sample. Thanks.

[Nick]

I'm new to RPL. Please critique the following code. I was surprised at the amount of nesting required to implement the local variable + algebraic object style -- that I could not simply keep accumulating (or even reusing) the local variables across multiple objects within the same scope.

Device: HP-48G [Revision R]
Formula: http://www.cs.utsa.edu/~cs1063/projects/...ation.html
Input: M D Y
Output: JD

This was my first thought (failed):

Code:

<< -> m d y
    'IP((14-m)/12' ->NUM -> a
    'y+4800-a' ->NUM -> y
    'm+12*a-3' ->NUM -> m
    'd+IP((153*m+2)/5)+365*y+IP(y/4)-IP(y/100)+IP(y/400)-32045'
>>

...but experimentation showed that the local variables are only accessible to the algebraic or program object immediately following their definition and any subsequent objects within the same scope lose access to the previously defined local variables after additional were defined.

The corrected code:

Code:

<< -> m d y
  << 'IP((14-m)/12' ->NUM -> a
    << 'y+4800-a' ->NUM
       'm+12*a-3' ->NUM -> y m
       'd+IP((153*m+2)/5)+365*y+IP(y/4)-IP(y/100)+IP(y/400)-32045'
    >>
  >>
>>

15087d ; 298.5

Is this appropriate / necessary for handling multiple formulas and the creation of additional local variables? It seems the structure and scope could get messy.

Any feedback is appreciated.

Thanks,
Nick

Edit: Added Device Model / Revision

[wojtek]

Small improvement to reduce number of << >>

Code:


<< 0 -> m d y a
      << 'IP((14-m)/12'  'a' STO
          'y+4800-a' EVAL 'y' STO
          'm+12*a-3' EVAL 'm' STO
          'd+IP((153*m+2)/5)+365*y+IP(y/4)-IP(y/100)+IP(y/400)-32045'
          EVAL
     >>
>>

0 in the beginning puts 0 on the stack so you can declare all local variables in the first line.
So if you enter 1 1 2000 and then run the code you get 2451545 as JD.
EVAL is not needed after 1st expression but is necessary after 2nd and 3rd because you modify variables y and m from these expressions.
You would get faster code if you would convert it to RPN

[DavidM]

(09-14-2016 05:56 AM)Nick Wrote:  I'm new to RPL. Please critique the following code...

There's a syntactical issue with your code pertaining to the use of locals, but in a more general sense, you may want to review this thread: Basic RPL question

There's a lot there, but it touches on several topics that are pertinent to your example.

Regarding the syntactical issues, you are actually creating two distinctly different copies of 'y' and 'm' in your code. Note that the "→" operator actually creates a local in addition to assigning its value. RPL lets you create multiple locals with the same name (which you almost never want to do), so you are effectively blocking access to the original ones in that last algebraic with the way you've written things. Local evaluation will return the most recently created instance when there's more than one with the same name. To assign values to preexisting locals, always use the '<varname>' STO syntax within their scope.

Speaking of scope, the best way to think of it in the context of locals is that the existence of a local is only defined for the immediately following object after local creation. That is why you have to group multiple RPL steps into a single code object with "<< ... >>" brackets to insure that they all can access the local. As you've discovered, nesting is allowed here. Just don't recreate more locals with the same name!

[Philippe]

Hi,

May be you are looking for compiled local variables as explained in section 1.10 "RPL programming" of "advanced user's reference manual" (hp49/50)

Philippe

[Nick]

(09-14-2016 09:40 AM)wojtek Wrote:  

Code:

<< 0 -> m d y a

I like that technique.. that opens up a lot and cleans up the nesting.

...then stacking and evaluating the formulas.. it's a good mix, that makes sense to me. I haven't thought about RPN being faster... I'd guess the formulas would have another layer of interpretation.

I read mention that formulas could be used to improve readability, that's what started this test. I'll try it in RPN as well and compare (perhaps benchmark).

Right, Formula 'a' ->NUM was optional but as there was nothing to simplify, would it improve performance slightly in this case to reduce it or is it better practice to let the interpreter handle it later in each separate evaluation.. or it just depends (I can see that in some cases it might improve accuracy)?

Thanks.

(09-14-2016 02:12 PM)DavidM Wrote:  you are actually creating two distinctly different copies of 'y' and 'm' in your code.

It was clear that I was 'overwriting' them in some way (I had assumed it was changing the value). Knowing that two distinct objects remain will be useful to know.

Right, thinking of local variable 'scope' in those therms helps. I had to make peace with the debugger and do some trial and error to figure out why my sequenced approach wasn't working. The added flexibility of RPL makes it easy to think for a moment you might be working in a higher level language than you are.

I'll have to think more on the link. I recall in the Advanced User's Guide that locals reemerge as they were which can cause different behaviors than coming off of the stack/variables. Thank you.

(09-14-2016 09:51 PM)Philippe Wrote:  May be you are looking for compiled local variables...

I did try that but was unable to expand the scope. It may be the usage of compiled locals is still unclear to me.

Thanks @ All.

[Nick]

RPN Version 1 (initialized a; stacked m₂):

Code:

<< 14 4 PICK - 12 / IP
   -> m d y a
   << y 4800 + a - 'y' STO
      12 a * m + 3 -
      153 * 2 + 5 / IP
      d +
      365 y * +
      y 4 / IP +
      y 100 / IP -
      y 400 / IP +
      32045 -
    >>
>>

# 56610d ; 260

The size is smaller than before.

RPN Version 2 (list operations):

Code:

<< 14 4 PICK - 12 / IP
   -> m d y a
   << y 4800 + a - 'y' STO
      12 a * m + 3 -
      153 * 2 + 5 / IP
      d +
      365 y * +
      y { 4 -100 400 } / IP ΣLIST +
      32045 -
    >>
>>

# 7368d ; 246.5