Threaded Mode | Linear Mode

Tugdual · 06-19-2015, 05:41 AM

While I am convinced that calculators are not supposed to have large programs (or it means you didn't pick the right calculator) I wonder what a large RPL program would look like and how Hp thought we should approach that. With the absence of gosub equivalent, we are left with two options: deep nesting or fragmentation of code into multiple sub applications. Hp calls variables "objects" for the reason that you can store anything in a variable, including fragments of RPL code. Providing that a program is made of multiple objects, does this conceptually mean that the equivalent of a program is a directory? Is that the way we're expected to approach large programs structuration?

Paul Dale · 06-19-2015, 06:25 AM

I've written some largish RPL programs.

My HP 28S chess is one example. This is entirely written in RPL.

My hybrid HP 28S 3D adventure game is another. This one uses some system RPL and assembly code to render the graphics quickly, but the majority of it is RPL.

The latter requires a cleared 28S and fills memory, the former isn't quite so large.

- Pauli

HrastProgrammer · 06-19-2015, 06:31 AM

(06-19-2015 05:41 AM)Tugdual Wrote: Providing that a program is made of multiple objects, does this conceptually mean that the equivalent of a program is a directory?

Not exactly a program, but you can look at it as a program or application made of individual subprograms = objects. From the FORTH point of view those objects are words and the directory is a vocabulary, so it all make sense. Although I don't have anything against FORTH (and, in fact, I developed my own x86 FORTH back in the day) I was never overly excited with this approach on the calculator and I prefer the classic program/subprograms/procedures/functions "look and feel" ...

ttw · 06-19-2015, 06:55 AM

I have a large ant-colony program for the TSP on an HP50g. At one time I had a general purpose optimization program; it did an exploratory search with quasi-Monte Carlo then finished off with a grid search incorporating Golden Section increase in decrease of step length.

Tugdual · 06-19-2015, 09:50 AM

(06-19-2015 06:25 AM)Paul Dale Wrote: I've written some largish RPL programs.

My HP 28S chess is one example. This is entirely written in RPL.

My hybrid HP 28S 3D adventure game is another. This one uses some system RPL and assembly code to render the graphics quickly, but the majority of it is RPL.

The latter requires a cleared 28S and fills memory, the former isn't quite so large.

- Pauli

Very instructive. So the idea is really to split the code in as many variables as functions needed. This seems to confirm the idea that the program being a set of variables all in the same directory, the directory itself becomes the program...

Bruno · 06-19-2015, 09:59 AM

(06-19-2015 09:50 AM)Tugdual Wrote: Very instructive. So the idea is really to split the code in as many variables as functions needed. This seems to confirm the idea that the program being a set of variables all in the same directory, the directory itself becomes the program...

or the directory becomes a Library..
Library was designed for that purpose, and HP did the Tools for that (USRLIB)

Claudio L. · 06-19-2015, 01:02 PM

(06-19-2015 09:50 AM)Tugdual Wrote: Very instructive. So the idea is really to split the code in as many variables as functions needed. This seems to confirm the idea that the program being a set of variables all in the same directory, the directory itself becomes the program...

You are correct, a variable is also a function and a RPL command. Giving proper names to subroutines is extremely important for code readability, especially in RPL which is not so friendly to the eyes, so even for not-so-large projects it's a good idea to use several named variables/commands.
The way I always organize my code is one directory per program. The directory contains the source code in the form name.txt (as many as needed), which is then compiled into the 'name' variable. This way you get to keep the commented source code. When it's time for release, simply copy the directory, remove all .txt variables and make a library out of it.
And, using one directory per program is also helpful for easy backups. Just throw the following code inside a directory, and will recreate the directory on the SD card, with one file per variable (doesn't do recursive directories, though):

Code:

<< PATH TAIL "/" SWAP

ADD "/" + ∑LIST VARS ADD VARS 2.

<< RCL SWAP 3. →TAG DUP PURGE

STO 0. >>

DOLIST DROP

>>

I always use the same name for the backup program: SDBACK, and I make sure it never conflicts with the actual source code. The backup program gets backed up too, but that doesn't bother me.

Claudio

Claudio L. · 06-19-2015, 01:09 PM

(06-19-2015 05:41 AM)Tugdual Wrote: Providing that a program is made of multiple objects, does this conceptually mean that the equivalent of a program is a directory?

You could always create one single object with local variables containing all the code, like this:

Code:

<< 

<< ...SUBROUTINE1... >>

<< ...SUBROUTINE2... >>

→ NAME1 NAME2

<< ...MAIN_PROGRAM... >>

>>

You could see the above as some sort of 'function declaration'.
So a program doesn't *have* to be a directory, but my personal preference has always been to have separate source code files, so a directory is better in my opinion.

Tugdual · 06-19-2015, 01:36 PM

(06-19-2015 01:09 PM)Claudio L. Wrote:
(06-19-2015 05:41 AM)Tugdual Wrote: Providing that a program is made of multiple objects, does this conceptually mean that the equivalent of a program is a directory?

You could always create one single object with local variables containing all the code, like this:

Code:

<< << ...SUBROUTINE1... >> << ...SUBROUTINE2... >> → NAME1 NAME2 << ...MAIN_PROGRAM... >> >>

You could see the above as some sort of 'function declaration'.
So a program doesn't *have* to be a directory, but my personal preference has always been to have separate source code files, so a directory is better in my opinion.

Interesting concept! Thanks for sharing this.

Joe Horn · 06-20-2015, 02:58 AM

(06-19-2015 01:09 PM)Claudio L. Wrote: You could always create one single object with local variables containing all the code, like this:

Code:

<< << ...SUBROUTINE1... >> << ...SUBROUTINE2... >> → NAME1 NAME2 << ...MAIN_PROGRAM... >> >>

A real-world example of that method can be seen HERE, in an RPL version of the PDQ Algorithm. In both the System RPL version and the User RPL version, a "subroutine" is placed on the stack, stored in a local variable called 'tof' ("to fraction"), and then executed by name, twice, in the main body of the program. The ONLY reason I did it that way was to keep the whole thing as one program.

Thomas Klemm · 06-20-2015, 04:51 AM

(06-19-2015 01:09 PM)Claudio L. Wrote: You could always create one single object with local variables containing all the code, like this:

Compare this program to the 3rd program of this previous post which uses directories:

Code:

\<<

  \<< ROT ROT

  \>>  \-> UNROT

  \<<

    \<<

      UNROT EVAL OVER / -2 /

      UNROT EVAL /

    \>>

    \<<

      OVER SQ SWAP - \v/

    \>>

    \<<

      DUP2 -

      UNROT EVAL +

    \>>

    \-> TRANSFORM DISCRIMINANT PLUSMINUS

    \<<

      TRANSFORM EVAL

      DISCRIMINANT EVAL

      PLUSMINUS EVAL

    \>>

  \>>

\>>

Quote:Local names are evaluated differently from global names. When a global name is evaluated, the object stored in the corresponding variable is itself evaluated.
(…)
When a local name is evaluated, the object stored in the corresponding variable is returned to the stack but is not evaluated.

- HP 48G Series User's Guide p. 29-17

Thus EVAL is sprinkled all over the program. Moreover since UNROT is used in the other subroutines it has to be defined in a surrounding local variable structure.
But I doubt that anybody is going through this hassle to define a new word from only two commands when it needs two commands to execute and even uses more letters to type.
In this case I tend to develop the program using global variables in a separate directory and inline the code once it is stable.
You can still use comments to structure the program:

Code:

\<<

  @ transform ( a b c -- p q )

  ROT ROT OVER / -2 /

  ROT ROT /

  @ discriminant ( p q -- D )

  OVER SQ SWAP - \v/

  @ plusminus ( p D -- x1 x2 )

  DUP2 - 

  ROT ROT +

\>>

Cheers
Thomas

Gjermund Skailand · 06-23-2015, 10:16 AM

For on-calc programming, which I prefer:
keep the files small, one small task in each file only, prioritize standardization and re-usability, and give them self-explaining names as there tend to be many of them.
Keep source files and compiled files in separate directory

you build a library of the compiled files.
see e.g. http
http://www.hpcalc.org/hp49/math/misc/quat133.zip

for a huge example see:
http://www.hpcalc.org/hp49/math/numeric/lf393.zip

copy the files to a SD card and then to the calculator.
- preferably you switch from rpl to system rpl

Best regards
Gjermund

Claudio L. · 06-23-2015, 03:49 PM

(06-20-2015 04:51 AM)Thomas Klemm Wrote:
Quote:Local names are evaluated differently from global names. When a global name is evaluated, the object stored in the corresponding variable is itself evaluated.
(…)
When a local name is evaluated, the object stored in the corresponding variable is returned to the stack but is not evaluated.
- HP 48G Series User's Guide p. 29-17

Thus EVAL is sprinkled all over the program.

Ahhh, I had forgotten about the need to EVAL. Another reason not to do it this way. Last time I did it was on SysRPL, I don't think I ever used local functions in userRPL.

For whoever might be interested, this is one behavior I changed in newRPL, local variables are evaluated just the same as globals, except they are compiled into GETLAM's (actually more like a GETLAMEVAL of some sort), so this technique could actually make more sense as it would be much faster to execute, since the subroutine is not searched by name through a directory.

BruceH · 06-24-2015, 08:15 PM

(06-19-2015 09:59 AM)Bruno Wrote:
(06-19-2015 09:50 AM)Tugdual Wrote: Very instructive. So the idea is really to split the code in as many variables as functions needed. This seems to confirm the idea that the program being a set of variables all in the same directory, the directory itself becomes the program...

or the directory becomes a Library..
Library was designed for that purpose, and HP did the Tools for that (USRLIB)

Bruno has it exactly right here. Here is a link to an article I wrote for Datafile back in 2002 showing a program broken down into a series of very small subroutines -- deliberately so to demonstrate the point -- and then combined into a single library.

fyescas777 · 07-06-2015, 02:24 AM

Hello, I'm new to hp forum and found no better place to ask a question but on this thread. I'm a mechanical engineering student, I own a 50g and a 35s. For most of my projects I use matlab because I was taught to use it, however, my classes are becoming slightly more complicated in the sense thay the formulas are getting very long and most problems require the same basic formulas. How difficult is it to learn the programming language for one of these calculators? I only need to program equations and solve for any of the variables, considering that I can program using matlab, How much does it differ from programming an hp?

Tugdual · 07-06-2015, 10:29 AM

(07-06-2015 02:24 AM)fyescas777 Wrote: Hello, I'm new to hp forum and found no better place to ask a question but on this thread. I'm a mechanical engineering student, I own a 50g and a 35s. For most of my projects I use matlab because I was taught to use it, however, my classes are becoming slightly more complicated in the sense thay the formulas are getting very long and most problems require the same basic formulas. How difficult is it to learn the programming language for one of these calculators? I only need to program equations and solve for any of the variables, considering that I can program using matlab, How much does it differ from programming an hp?

I don't know MATLAB so I can only give partial answer.
I would definitely prefer the 50g to the 35s for the type of application you mentioned.
Learning the programming language is pretty straightforward since it remains close to RPN but the use of libraries imposes a reading of user manual as well as advanced user manual.
Now I wonder if you really need to go into coding. Have a look into MES (Multiple Equation Solver) which seems to correspond exactly to the problem you described. I cannot talk for the algorithm though.

Michael Lopez · 07-06-2015, 11:07 AM

Bruce,

Thanks for the excellent example article.

Cheers,

Michael

David Bengtson · 07-11-2015, 02:48 PM

(07-06-2015 02:24 AM)fyescas777 Wrote: Hello, I'm new to hp forum and found no better place to ask a question but on this thread. I'm a mechanical engineering student, I own a 50g and a 35s. For most of my projects I use matlab because I was taught to use it, however, my classes are becoming slightly more complicated in the sense thay the formulas are getting very long and most problems require the same basic formulas. How difficult is it to learn the programming language for one of these calculators? I only need to program equations and solve for any of the variables, considering that I can program using matlab, How much does it differ from programming an hp?

The easiest thing to do would be to use an equation library to manage them. I use PEQUM http://www.hpcalc.org/details.php?id=6306 myself, for a similar application. This is nice because you can add a note to each equation.

EQL+ http://www.hpcalc.org/details.php?id=6050 is also nice, you can add both a note and a GROB to each equation.

Thomas Klemm · 07-24-2015, 08:27 PM

(06-24-2015 08:15 PM)BruceH Wrote: showing a program broken down into a series of very small subroutines

Over the Shoulder: Text Preprocessing in Forth

This video shows the same approach with Forth.
You might be put off by its length, but I think it's worth it.

Cheers
Thomas

Hlib · (This post was last modified: 08-27-2016 08:44 AM by Hlib.)

(06-19-2015 05:41 AM)Tugdual Wrote: While I am convinced that calculators are not supposed to have large programs (or it means you didn't pick the right calculator) I wonder what a large RPL program would look like and how Hp thought we should approach that...

Ten years ago I wrote a chess for Casio FX-2.0. The program had about 20,000 steps, advanced graphics and several dozen modules. So I was interested too in the creating such a large project on the HP-50G. At the moment I have to improve and convert my old program. It all starts again from scratch. But I doubt in the possibility of creating a complete shell programme for chess engine on the HP-50G.