[question]userRPL, functions or (sub)subprograms and directories

[pier4r]

A basic program in userRPL that makes use of local variables and no algebraic expression is the following (If Im not mistaken)

Code:


%%HP: T(0)A(D)F(.);
@ You may edit the T(0)A(D)F(.) parts.
@ The earlier parts of the line are used by Debug4x.

\<<
  10
  11
  \->
  uFlocal1
  uFlocal2
  \<<
    uFlocal1 SF
    uFlocal2 CF
    
    uFlocal1 FS?
    "local flag 1 set?"
    \->TAG

    uFlocal2 FS?
    "local flag 2 set?"
    \->TAG
  \>>
\>>

Now when programs gets a bit more complicated (note1) I usually try to use functions to split it in blocks.

As far as I know there are at least two ways to emulate a function:
- either I produce functions in different source files, that then I save as programs. So I have:
function1 <prog>
function2 <prog>
main <prog>
Where main makes use of function1 and function2
- or I somehow type the function in the main program and the store it to use it as recalling a variable. Like

Code:


\<<
  10
  11
  0
  \->
  uFlocal1
  uFlocal2
  funcCF
  \<<
    \<<
      @ it would work even with declaring again local variables and \-> plus a subprogram
       CF
    \>>
    'funcCF' STO
    
    uFlocal1 SF
    uFlocal2 funcCF EVAL
    
    uFlocal1 FS?
    "local flag 1 set?"
    \->TAG

    uFlocal2 FS?
    "local flag 2 set?"
    \->TAG
  \>>
\>>

Are there better ways? So far I prefer the second way (unless the program is awfully long, like 2Kb or more comments excluded) because I can use functions as defined in the main program, and not floating around the memory and maintained separatedly. Nevertheless I do not know if there may be cases that a variable cannot hold a program.

I tried to search on this site but I get interesting but not useful discussions like this.

(note 1) yes I know, ideally I should move to sysRPL or hpGCC or maybe the lua interpreter built with hpgCC, but I did not finish exploring the RPL commands in the AUR)

[Han]

You do not need to store your functions; you can have the functions be arguments themselves:

Code:

\<<
  1 2 4 \<< your program \>>
  \->
  var1 var2 var3 myfunc
  \<<
    main function
  \>>
\>>

[pier4r]

True. That would help ordering the code better. Any other tip?

[Vtile]

You can use if error (IFERR) as a some form of escape structure.

[pier4r]

(03-29-2017 12:43 PM)Vtile Wrote:  You can use if error (IFERR) as a some form of escape structure.

Yes. I knew this and recently I stumbled over a discussion that quickly moved from "how to simulate a break" to "how to avoid it and why".

Anyway my request for additional tips was mostly about "any other best practice how to code and use functions that are needed mainly by one main program?".

[DavidM]

(03-29-2017 12:51 PM)pier4r Wrote:  Anyway my request for additional tips was mostly about "any other best practice how to code and use functions that are needed mainly by one main program?".

I believe you've already found what is likely the best way to create and use embedded functions and subroutines for UserRPL -- create them as local vars and activate with local EVAL. This method keeps the source code together as a single object and is efficient with memory resources. The only downside that comes to mind for something like this might be performance, though only in situations where the function/subroutine is called many times. You're not likely to notice any performance issues for functions that are only used a few times.

As you've already pointed out, storing programs/data into other user objects [aka globals] is a possibility. One additional advantage that this method brings is that you can use the object's location in your directory structure to control its scope. While this probably doesn't apply to what you originally intended, it's a worthy consideration for other situations, especially when different versions of the same function might apply to different scenarios.

I'd be remiss if I didn't mention a third possibility, though it's fair to say that it's probably the least applicable in this case. That would be creating a custom library to contain your programs and data in a single coherent package. The overhead required makes this less feasible for simple situations, but it brings some nice benefits to projects with greater complexity or when you want to start controlling the "exposure" of individual elements of the application.

[pier4r]

(03-29-2017 02:44 PM)DavidM Wrote:  -cut -

Nice input, thanks!

I did not thought about the solution with main program and subprograms in a subdirectory. Somehow I can do it with PHP, JAVA and so on and I think instead that userRPL is flat. I could use a local var to define the source path and that's it, well actually I never used absolute paths with directories on the 50g.

For libraries, yes it is a possibility but to me that is for fairly big programs or at least stable ones (and at that point I would try to go on hpgcc if I have to handle overhead).

[DavidM]

(03-29-2017 03:01 PM)pier4r Wrote:  I could use a local var to define the source path and that's it, well actually I never used absolute paths with directories on the 50g.

That's one way to approach it, but not exactly what I meant. Keep in mind that the default search path for objects on the 50g is "current directory or any parent directory of the current one". So you don't have to specify the full path if the item being referenced is located anywhere in that upward-looking default search path.

Objects in any directory are accessible to other objects in that same directory or any of its subdirectories without specifying the full path name. Multiple versions of the same object can be saved in different subdirectories, and the first one found on the search path will be used. This is why an item named 'FOO' stored in the HOME directory can be accessed by any other object (in any subdirectory) simply as 'FOO' (without a path). Objects in the HOME directory are always in the search path.

Note that this behavior can be a mixed blessing, and is quite often the cause of confusion when people have stored objects somewhere in a parent directory and their programs (or built-in functions) access them. Used properly, though, it can be quite powerful.

[pier4r]

(03-29-2017 03:37 PM)DavidM Wrote:  That's one way to approach it, but not exactly what I meant. Keep in mind that the default search path for objects on the 50g is "current directory or any parent directory of the current one". So you don't have to specify the full path if the item being referenced is located anywhere in that upward-looking default search path.

[...]Used properly, though, it can be quite powerful.

Yes, I agree that's quite powerful. I did not know this property of the interpreter. Is it defined in the manuals or is it something that the community discovered and was underdocumented?

Anyway I noticed a pretty useful usage of putting an additional nested program in a program. One can isolate code blocks to not execute them (in the case adding a "drop" after the nested program) or to debug them. That helps a lot.

Code:


\<<
  10
  11
  0
  \->
  uFlocal1
  uFlocal2
  funcCF
  \<<
    \<<
      @ it would work even with declaring again local variables and \-> plus a subprogram
       CF
    \>>
    'funcCF' STO
    
    uFlocal1 SF
    uFlocal2 funcCF EVAL
    
    uFlocal1 FS?
    "local flag 1 set?"
    \->TAG

    uFlocal2 FS?
    "local flag 2 set?"
    \->TAG
    
    
    \<<
      @pretty useful for toggling code inactive
      "code I'm not sure of, don't execute"
    \>>
    
    \<<
      @pretty useful to debug just portion of code
      "code I want to debug"
    \>>
    DEBUG
  \>>
\>>

[DavidM]

(03-29-2017 04:42 PM)pier4r Wrote:  Is it defined in the manuals or is it something that the community discovered and was underdocumented?

It's defined in the 50g Users Guide (English version) on page 21-4, and I believe in other documents as well.

Sometimes sample code can show how things work more clearly than lengthy descriptions:

Code:

%%HP: T(3)A(R)F(.);
DIR
  test
  \<< foobar "root" \->TAG \>>

  foo
  1

  bar
  5

  foobar
  \<< foo bar + \>>

  dir2
  DIR
    test
    \<< foobar "dir2" \->TAG \>>

    foo
    2

    dir3
    DIR
      test
      \<< foobar "dir3" \->TAG \>>

      bar
      100

    END
  END
END

Running "test" in each directory will give different results due to the variables "foo" and "bar" being redefined. Note that neither the function calls nor the variable references need paths -- the O/S simply looks for the named objects and executes the first one it finds with that name in the current search path.

This example shows another important concept to keep in mind: while "test" in dir2 and dir3 is actually running a program (foobar) that resides in a higher level directory, the search path that applies is whichever one was current when you started "test" -- not the path starting from the location of "foobar". The current path always starts at the current directory that the user sets, unless (of course) the program explicitly changes that.

[pier4r]

(03-29-2017 05:39 PM)DavidM Wrote:  This example shows another important concept to keep in mind: while "test" in dir2 and dir3 is actually running a program (foobar) that resides in a higher level directory, the search path that applies is whichever one was current when you started "test" -- not the path starting from the location of "foobar". The current path always starts at the current directory that the user sets, unless (of course) the program explicitly changes that.

Like in linux. Nice.

Another thing that is pretty neat is that I did not know I could code directly directories in an object. I do not know if that is a made up object or you can implement an entire directory in a so simple way. I'll test asap. It is exciting!

Compared to that my way of coding programs with functions is way more complicated (either because I have one lengthy program with inner blocks or because I need a multi tabbed editor to keep track of things).

Anyway I never read about the DIR in the user guide or AUR (wait AUR mention it, but quickly), but again, as I missed the point about visibility of saved globals in subdirectors in the user guide, I may have missed the part about "how to code an entire directory structure".

Coding directly a directory structure I believe could be even more "maintainable" than a program between "\<< \>>" that has multiple sub blocks inside it.

[pier4r]

About DIR ... END

Awesome, it works! I used your example (thanks a lot!) to infer the structure but I'm not sure how the structure should be within DIR ... END . If someone could point out more documentation it would be great.

For the moment I found a passing note in the AUR and only one other post on this site using DIR ... END

http://www.hpmuseum.org/cgi-sys/cgiwrap/...ead=138380
message number 8.

I'll search more but now I will think about converting the program that I was writing.

Side note: Gerson if you will ever read this thread. You are a very prolific writer about user RPL programs and mathematical solutions, but as a reader of your code I see that you heavily use the stack (that is not easy to read nor debug) and you put almost no comments in your programs. So one is left debugging them to understand what happens. Could you put more comments in them? Would be great! :love:

Update: I found some more usage of DIR END (especially compsystem) but no direct documentation about the format of the entries.

Updated2: so, a bit of satisfying entries

Equation library with DIR END by J.H. Meyers
DIR end structure comp.sys.hp48
DIR END structure, for SYSRPL I believe

- http://www.hpmuseum.org/forum/thread-4184.html

[pier4r]

So I would like to post the following code to help possible newbies like me (I'm no newcomer, I'm just noob).

I edited with notepad++ using "language ->N - Normal text" and then the chapter J of the AUR to help me with the translation of special chars that are not available in plain text.

The following code contains subprograms that can be easily disabled, for debugging purposes, avoiding to execute EVAL after them or after recalling them.

In the same way, if instead of EVAL, DBUG is used, then the user can DBUG exactly the wanted block and nothing else, simply evaluating the main program (The execution will stop once DBUG is reached, then one can proceed with the RUN & DEBUG menu). Speeding up the identification of problems. Once I discover this the debugging of quirks in the program was way faster than my previous experiences. It is something should be more advertised for newcomers, I wish I would known before.

Then I suppose the directory structure in one source file would be even better but it is something I'm going to use after this post for the first time.

Code:


%%HP: T(0)A(D)F(.);
@ You may edit the T(0)A(D)F(.) parts.
@ The earlier parts of the line are used by Debug4x.

@ in npp, just select encoding "normal" to get rid of the highlight.

@ Objective:
@ - We want to compare the expected performances of teams of a certain
@   average strength in some types of tournaments to determine
@   what is the one that determines the best team.
@   Assuming that the best team is the one is given higher strength
@   a priori. Of course the simulation of the tournaments
@   should be done some times to determine the percentage of winning.
@   1. round robin. Every team meet everyone else, at least twice.
@      (it could be extended with four times, six and so on)
@      Often used in long tournaments.
@      This is assumed as the best format and will be used as reference.
@   2. swiss tournament
@      Random pairings, and then teams with high score meet other teams
@      with high score, if possible avoiding pairings already done.
@      The minimum is that teams meet once.
@      Often used in chess, short but maybe effective.
@   3. knowckout tournaments. Random pairing at the start and then
@      the ones that wins proceed.
@      Often used in "show tournaments", short but maybe not so effective.
@   4. only one match against all the others (like half of a round robin)
@      Often used in show tournaments. Short but maybe not so effective.

@ Remarks: the comments try to give an idea, the values in the comments may
@ be different from the actual code though.
    
  
\<<
  'n*25+1200' 'n' 1 16 1 SEQ 
    @listTeams
    @ list of teams with a priori strength score
  0 @numTeams
  0 @tmpV to use for short time, value can be changed in other functions!
  0 @tmpV2
  0 @maxSumProbV
  0 @numProbV
  0 @mVarProb
  0 @curProbV
  1 @colSumProb
  2 @colProb
  3 @colVar
  0 @getVarFunc
  0 @matchResFunc
  10 @uFteamAwon
  30 @uFmatchingProbFound
  0 @rrFunc
  0 @teamAstrV
  0 @teamBstrV
  0 @teamAtmpV
  0 @teamBtmpV
  0 @rrResArr
  0 @rrResList (not sure what I'll use)
  0 @IncListElFunc
  1 @pointsForWin
  \->
  listTeams
  numTeams
  tmpV
  tmpV2
  maxSumProbV
  numProbV
  mVarProb
  curProbV
  colSumProb
  colProb
  colVar
  getVarFunc
  matchResFunc
  uFteamAwon
  uFmatchingProbFound
  rrFunc
  teamAstrV
  teamBstrV
  teamAtmpV
  teamBtmpV
  rrResArr
  rrResList
  IncListElFunc
  pointsForWin
  \<<
    listTeams SIZE 'numTeams' STO
  
    \<<
      @ creating the matrix containing the probability of the points oscillation
      @ between -400 points and +400 points
      
      @ every drop or increment of the base strength is made in 25 points.
      @ those points have a probability. So I assign "probability tokens" at every
      @ change. For example.
      @ -400  has 25 prob tokens. -375 has 50, -350 has 75 and so on, until the
      @ base value then goes back. +25 has 400 tokens, +50 has 375 and so on.
      @ so I want to model those tokens.
      'n' 'n' 25 400 25 SEQ
      425 +
        @ expanding the previous list with 425
      'n' 'n' 400 25 -25 SEQ
        @ Or REVLIST could have been used.
      + 'tmpV' STO
        @ storing the list
        @ the complete list now goes from 25 to 425 and back to 25.
      
      @ Now we want to create the sum of all this tokens,
      @ one value for each token, We can use STREAM but we need to recall
      @ objects from the tack. I do not like stack operations because
      @ they are unreadable but when they are a little it is ok.
      @ otherwise one should comment the actions.
      1 'tmpV2' STO
        @ counter, it needs to start from 1.
      tmpV 
      \<<
        @ having 25 50 75 100
        @ STREAM  25  2 Pick 25 + 25 STREAM 25 Pick 2 25 + 25  STREAM 25  Pick 2 25   + 25 
        @         50         50   75        75        75   75         75         75     75
        @                    25             75        75   150        150        150    150
        @                                             75              100        100    250
        @                                                                        150    
        2 PICK
        +
        1 'tmpV2' STO+
          @we need to count the objects that we leave on the stack. Plus 1 added at the start.
      \>>
      STREAM
        @now we have the list with all the sums
      @before making a vector out of it we save the last value that is the maximum value.  
      DUP 'maxSumProbV' STO
      @we continue      
      tmpV2
        @ the number of objects.
      \->ARRY    
        @ transformed in a vector
      
      tmpV
        @ the first list
      OBJ\->
        @ exploded
      @before saving it as vector I save the number of elements or
      @probility tokens (equals to variances)
      DUP 'numProbV' STO
      \->ARRY    
        @ transformed in a vector
        
      'n' 'n' -400 -25 25 SEQ
      0 +
      'n' 'n' 25 400 +25 SEQ
      + OBJ\->
        @ added and then exploded
      \->ARRY    
        @ transformed in a vector
      
      3 COL\-> 'mVarProb' STO
        @final matrix with columns: sum of probability tokens, probability tokens for variance, variance in points.
    \>>
    EVAL
      @compute the above program immediately

    \<<
      @program to extract the variance out of the built matrix
      
      @output, the variance of the strength points out of the matrix
      
      maxSumProbV RAND * 1 + IP 'curProbV' STO
        @ we get a random vnumber that has to be compared with the probability sums
      
      1 'tmpV' STO
        @with tmpV we will use it as a counter
      uFmatchingProbFound CF
      WHILE
        uFmatchingProbFound FC?
        tmpV numProbV \<=
        
        AND
      REPEAT
        IF
          curProbV 'mVarProb(tmpV, colSumProb)' EVAL \<=
            @accessing the matrix in algebraic mode, slower but more readable.
            @ than the messy RPN (RPN is not always less readable, but in some cases)
            @maintenance and debug use resources as well that often are more valuable.
        THEN
          @ found a probability sum bigger than the actual random value.
          uFmatchingProbFound SF
        ELSE
          1 'tmpV' STO+
        END
      END
      
      'mVarProb(tmpV, colVar)' EVAL
    \>>
    'getVarFunc' STO
      @get variance function.    
      
    \<<
      @program to compute the result of a match based on the variance and probability of it.
      @ should be used by all the tournaments.
      
      @In input are expected the strength of the two teams 
      @ and a user flag for the result
      @as for of variables already existing.
      @teamA
      @teamB
      @userFlagNumber
      
      @in output a flag is set
      @if teamA won, otherwise teamB
      
      uFteamAwon CF
      
      @ teamA streangth modified
      teamAstrV 
      getVarFunc EVAL
      + 'teamAtmpV' STO
      
      @ teamB streangth modified
      teamBstrV 
      getVarFunc EVAL
      + 'teamBtmpV' STO
      
      @there is no draw possible, at least for now.
      IF
        teamAtmpV teamBtmpV >
      THEN
        @teamA won.
        uFteamAwon SF
      ELSE
        @ teamA with lower or equal strength
        IF
          teamAtmpV teamBtmpV <
        THEN
          @teamA lost
          uFteamAwon CF
        ELSE
          @ same strength
          @ coin toss
          IF
            RAND 10 * IP
            5 <
          THEN
            @teamA won
            uFteamAwon SF
          ELSE
            @teamA lost
            uFteamAwon CF
          END
        END
      END
    \>>
    'matchResFunc' STO
    
    \<<
      @ program to increase the value of element in a list
      
      @ input on the stack see variables
      @ see the following, that if I keep adding variables on the main
      @ program it gets too unreadable.
      \->
      lList 
        @list
      lPosV 
        @position of the element
      lincV 
        @increase
      \<<
        lList lPosV
          @placing list and position on the stack
          @for storing, later.
        lList lPosV GET
        lincV +
          @getting the value and increasing it
        PUT
          @putting the increasing value back
      \>>
    \>>
    'IncListElFunc' STO
    
    \<<
       @program to compute a round robin tournament 
       
       @ given a list of teams with their strength and other
       @already named and set variables.
       
       @output, the list of teams with final points.
       
       '0' 'n' 1 numTeams 1
       SEQ 'rrResList' STO
         @saving the result list that at the start is just zeroes
       
       1 
       numTeams 1 -
       FOR teamPosA
         listTeams teamPosA GET 'teamAstrV' STO
           @get first team
         
         teamPosA 1 + 
         numTeams
         FOR teamPosB
           listTeams teamPosB GET 'teamBstrV' STO
             @get second team team
             
           @compute the result of a match. twice
           @as round robin requirement.
           1 2
           FOR counter
             matchResFunc EVAL
           
             IF
               uFteamAwon FS?
             THEN
               @update results
               rrResList teamPosA pointsForWin
               IncListElFunc EVAL
               'rrResList' STO
             ELSE
               @update results
               rrResList teamPosB pointsForWin
               IncListElFunc EVAL
               'rrResList' STO
             END
           NEXT
         NEXT
       NEXT
       
       rrResList
    \>>
    'rrFunc' STO
    
    rrFunc EVAL
  \>>
\>>


@ log {
@   12:05 29.03.2017{
@     Generating list of 16 teams between 1200 and 1600 strength points
@     'n*25+1200' 'n' 1 16 1 SEQ
@   }
@ }

[pier4r]

If I use a DIR ... END structure (see previous posts) is there a way to pass variables that are not globals, that AFAIK are pretty slow in userRPL, between subprograms in a smart way or I have to pass every time the variables leaving a copy on the stack as usual?

Update1: so far instead of passing long lists of local variables I just decided to use globals. Maintenance value > speed value (because with 'easier' code one gets correct results, with premature optimizations one gets necklaces of fails)

[Han]

Use \<-varname to create local variables that are visible between subprograms. I believe this is discussed in the Advanced User's Reference manual (for the HP48 at least).

[pier4r]

Do you mean the compiled local variables? I never used them but I'll have a look. Thanks.

[DavidM]

Regarding directory syntax:

In the context of RPL, directories are simply another type of object. They're actually conceptually similar to other compound objects such as lists, in that they encapsulate other objects into a single entity. So, like the syntax for lists ( { obj1 obj2 ... objN } ), the syntax for notating a directory object simply consists of a prefix (DIR), the contents (<whatever>*), then a suffix (END).

The syntax of notating a directory object's contents (<whatever>*) is an arbitrary sequence of 0 or more object id/definition pairs. So you could designate the syntax as follows:

Code:

DIR <obj1_ID> <obj1> <obj2_ID> <obj2> ... <objN_ID> <objN> END

Unlike lists, there's very little you can actually do with directory objects other than recalling them to the stack or storing them into variables. Their usefulness comes from the kernel knowing how to deal with them directly, which it exposes through the user interface, dedicated variables (such as HOME), and directory-specific commands and features (PATH, ORDER, CRDIR, PGDIR, etc.).

All of the IDs in a directory definition have to be valid RPL IDs, and all of the objects have to be valid single RPL objects. The objects themselves can be any valid RPL type that could normally be stored into a variable, including other directories. So, for example, all of the following are valid directory designations:

A directory containing three numeric objects:

Code:

DIR a 1 b 2 c 3 END

A directory containing two lists and an algebraic:

Code:

DIR a { 1 2 3 } b { 4 5 6 } c '(x+y)/z' END

A directory containing a single program named 'myprog':

Code:

DIR myprog \<< 1 + 5 / SQ \>> END

A directory containing a single directory with no objects:

Code:

DIR emptydir DIR END END

I've put all of the above on a single line to show the minimal syntax, but you can add newlines/indentation as desired for readability:

Code:

DIR
  a
    { 1 2 3}
    
  b
    { 4 5 6 }
    
  c
    { 7 8 9 10 11 12 }
    
  x
    12345
    
  myprog
    \<<
      1 +
      5 /
      SQ
    \>>
    
  emptydir
    DIR
    END
  
END

[pier4r]

Nice! A thousand thanks!

[David Hayden]

One other point that I didn't see here: writing to global variables is very expensive. Because the entire contents of the HOME directory is packed tightly together, changing the size of any object means you have to move every object that comes after it. And since you have to move objects, you also have to check the stack, return stack, local variables etc for any pointers to the objects that moved and adjust them accordingly. Thus writing to local variables is much faster.

[pier4r]

Oh, did not know that. Thanks for sharing! So now I understand why the more "garbage" I left in the Home, the more time some actions take.