The Museum of HP Calculators

HP Forum Archive 17

[ Return to Index | Top of Index ]

Seeking Some RPL Tutelage
Message #1 Posted by Les Wright on 13 June 2007, 12:26 p.m.

I have an interesting request for the Forum, which I know is somewhat OT given the mandate here, but I think it is still a well-posed question for this setting.

I find I learn the basics of a new language from examples, and indeed at first this is often more helpful than plowing through exhaustive treatises on syntax and whatnot in quest for my specific solution.

To this end, I was seeking some specific help with SysRPL. I was hoping that someone could offer an example of a simple UserRPL program and its SysRPL version. I am seeking to translate some of my UserRPL math programs to SysRPL, so program examples that use local variables, DO...UNTIL loops, and IF...THEN...ELSE branching with less-than, greater-than, or equality conditional tests are particularly relevant. Translation of UserRPL that uses stack manipulation (PICK, ROLL, OVER, etc.) is interesting to me, but I must admit that I find that style of UserRPL programming tougher to master so programs that track intermediate results in local variables rather than on the stack are more accessible to me. At this point I am not interested in funky graphics or symbolic manipulation or nifty input forms and windows. I am simply interested in routines that take numeric arguments (which can be complex) from the stack, work their magic on them in the SysRPL or UserRPL code, and return a numeric result (which again can be complex). Dealing with vectors, arrays and lists is the next step once I get a grasp of this.

I am hoping that someone has done this sort of work in the past and has some relevant examples they could share without a major investment of time, though if anyone wants to view this a sort of fun project that is great.

Please keep in mind that I am requesting this to supplement my personal efforts in review the copious didactic material out there on SysRPL programming, not merely replace or totally shortcut it. So calls to RTFM are not needed here. Don't worry, I am doing that too. I have learned how to access the MASD on the HP49G+ and the need for an extable (after discovering that a sample program wouldn't compile without one!), so I can readily compile the code I am presented with without needing much coaching on that.

many thx in advance,

Les

Edited: 13 June 2007, 3:28 p.m. after one or more responses were posted

      
Re: Seeking Some RPL Tutelage
Message #2 Posted by Giancarlo (Italy) on 13 June 2007, 12:46 p.m.,
in response to message #1 by Les Wright

Hi Les.
Unfortunately I'm not entitled to give you any tutelage...
But have you already seen this:
James M. Prange's comparison
I found it extremely interesting (as always JMP's posts are).
Moreover, on the good ol' hpcalc.org you can find:
SysRPL Programming Examples
that is:

Quote:
Example programs from the second edition of the free on-line book "Programming in System RPL", a 640-page tutorial and reference for System RPL programmers. These examples are ready to be loaded onto your calculator. By Eduardo M. Kalinowski and Carsten Dominik

I do hope this helps a bit - but I'll be eagerly reading any further feedback on this topic.
Best regards.
Giancarlo
      
(deleted post)
Message #3 Posted by deleted on 13 June 2007, 12:47 p.m.,
in response to message #1 by Les Wright

This Message was deleted. This empty message preserves the threading when a post with followup(s) is deleted. If all followups have been removed, the original poster may delete this post again to make this placeholder disappear.

            
Re: Seeking Some RPL Tutelage
Message #4 Posted by Les Wright on 13 June 2007, 1:33 p.m.,
in response to message #3 by deleted

Thanks. James's comparative example should be more informative once I get it on the calculator and see what it actually does.

I have downloaded the Kalinowski/Dominik examples and will experiment with them. I have also begun to crack the Kalinowski/Dominik book, and so far I have one criticism--the practicalities of compiling a program on the calculator are relagated to an appendix, and it took some wading through lots of info before I appreciated the need for extables and different versions of SysRPL code. I was trying to compile the example first.s from the Kalinowski example and got no where until I stumbled across the stuff about extables. This basic stuff would've been helpful right at the front of the book.

Here is an interesting point--Kalinowski/Dominik claim that Libraries 256 and 257 are not attached by default. In both my 49G+ and in a fresh instance of Emu48, I find that indeed they are--I get to see proper softkey menus via 256 MENU and 257 MENU without having to explicitly attach the libraries first via 256 ATTACH and 257 ATTACH. Perhaps calling the menus attaches the libraries automatically? At any rate, I was tickled to find the compiler right where the manual said it was.

Les

Edited: 13 June 2007, 1:34 p.m.

                  
Re: Seeking Some RPL Tutelage
Message #5 Posted by Giancarlo (Italy) on 13 June 2007, 5:56 p.m.,
in response to message #4 by Les Wright

Les,
I myself am trying to do just the same - i.e. going through that forrest of information that is Dominik&Kalinowski's book.
Indeed, it would deserve much more effort, time and continuity than those I'm able to get in my little spare time :-(
However, I resound with you when you point out that some "basics" were not placed in the right "light" and in the right "place"
according to their importance...
As far as I can recall, libs 256 and 257 are auto-attached with the latest ROM version(s) for the 49G+/50G.
I do hope that some more knowledgeable people here around will have the patience and good-will
for sharing some insights.
All the best.
Giancarlo

                  
Re: Seeking Some RPL Tutelage
Message #6 Posted by James M. Prange (Michigan) on 13 June 2007, 6:25 p.m.,
in response to message #4 by Les Wright

Quote:
James's comparative example should be more informative once I get it on the calculator and see what it actually does.
Something that I think will be useful for anyone who writes UserRPL source code in his favourite text editor.

For those who don't want to mess around with compiling the SysRPL version, remember that the UserRPL version accomplishes the same thing.

But it's pretty simple step-by-step stuff. No tests or conditional execution, only one loop, a little stack manipulation, but no variables.

I'm definitely not an expert at either SysRPL or Saturn assembly language. Yes, I can use them, but I usually can't just sit down and write a program in them without some reference material at hand. Often I just want to check the spelling or which order the arguments should be in, but then I notice another command that might be better....

Quote:
I have downloaded the Kalinowski/Dominik examples and will experiment with them. I have also begun to crack the Kalinowski/Dominik book,

I take it that you mean Programming in System RPL, Second Edition, by Eduardo M Kalinowski and Carsten Dominik? I don't think that anything better than that for learning SysRPL is available.

Also see RPLMan (it should be available from hpcalc.org). It was written when the 48SX was the current model, so it's a bit out of date, but other than adding some new object types and commands and the entry points changing, the RPL language hasn't changed all that much. What's in there still applies, although of course it doesn't cover the newer additions.

For the development library (including compiler features and syntax), see "Masd Documentation".

Note that a lot of the additions in the 49 series (including the development library) came from the "Meta Kernel" (or "MetaKernel" or "MK"), originally developed for the 48 series, so any documentation for it might be helpful.

Debug4x may be useful to you, although other than the included emulators being very useful, I've never much cared for it. But many others think that it's great.

Also install the OT49Plus library (available from Wolfgang's site) on your 49g+ (or 50g); I think that it makes some of the development library tools easier to use. Wolfgang is another SysRPL expert; it's as if he could write excellent programs in his dreams. A criticism is that in his programs, almost everything else, other than actually working as intended, has a much lower priority than program size. Wolfgang has taken a break from his RPL programming hobby to work on his other interests, but his tools for the 49g+ should work on the 50g as well.

Look at and try to understand SysRPL programs that others have written. Okay, very often the source code, let alone any commenting, isn't published, but you can decompile an RPL program with the \->S2 command (or OT49's Sys~ command).

The Nosy library is a very useful tool. It lets you see the programs that make up the built-in commands and follow the logic of how the ROM is written (what calls what and under which condition). You might notice some cases where the ROM code could be "improved" (made faster or smaller) easily enough, but changing something might inadvertently move an entry point (thus breaking anything that uses it), and "don't fix what ain't broken" isn't such a bad policy.

For that matter, Nosy can also be used for investigating any other program.

Browse and search the comp.sys.hp48 usenet group. One problem is that some of the discussions are among experts, so beginners may well be baffled by those. But there are plenty of "beginner questions" (and answers) too.

Try setting flag -85. This lets you see the stack (well, however much of it is visible) decompiled to SysRPL syntax. Note that to make much sense of a lot of it, extable will have to be installed. That said, if you use anything else to view an object, you'll see it in UserRPL syntax.

Quote:
and so far I have one criticism--the practicalities of compiling a program on the calculator are relagated to an appendix, and it took some wading through lots of info before I appreciated the need for extables and different versions of SysRPL code. I was trying to compile the example first.s from the Kalinowski example and got no where until I stumbled across the stuff about extables. This basic stuff would've been helpful right at the front of the book.

I think that part of the problem is that the authors are real experts in SysRPL, and may find it rather difficult to remember that beginners don't necessarily know all of the essential "basic stuff".

First scan through the document quickly to get an idea of how it's organized and what information is available, then read it more thoroughly, but just scanning through the command and built-in ROM objects references, and finally use it as a reference for particular topics.

A problem with trying to explain SysRPL is that there are so very many commands, often combining what would typically be thought of as two or more commands into one, many of which accomplish almost the same thing. Basically, it seems that if the system developers found something to be useful for developing the operating systems, then they built it into the ROM, and if they thought it to be particularly useful to 3rd-party developers, then they made it a "supported" entry point. Sometimes a SysRPL command is poorly named, but once a name is assigned, it tends to stick; hey, it doesn't have to make sense to ordinary users, as long as the developers know what it does. Anyway, there are usually several perfectly good ways to accomplish something, and what's "best" is very subjective.

"Unsupported" entry points may well change with any ROM revision, so are best avoided. But Jean-Yves mentioned some ranges of entry points that won't move, and these are the "unsupported but stable" entry points that are probably okay to use. He isn't employed by HP any more, but they haven't moved yet. But if HP releases another series of RPL models, even the "supported" entry points may move.

There are also certain RAM locations that, although perhaps not "supported", still have the same purpose in the 50g as in the 48SX. I've found some of these useful for external I/O. By the way, I had to look at things written with the 48SX in mind to find out about some of these in the 49 series.

In trying to explain something to a real beginner, the difficult question is "where to start"; what basic stuff that "everybody knows" does he really need to know first? For trying to explain something to someone who seems basically competent in the subject, the questions become "what essential knowledge is he lacking for this topic", along with "what does he already know and doesn't need to be told".

You may have to slowly and painfully accumulate knowledge until it reaches a "critical mass" for you and the learning curve suddenly starts to level off and it becomes much easier to learn more.

Quote:
Here is an interesting point--Kalinowski/Dominik claim that Libraries 256 and 257 are not attached by default. In both my 49G+ and in a fresh instance of Emu48, I find that indeed they are--I get to see proper softkey menus via 256 MENU and 257 MENU without having to explicitly attach the libraries first via 256 ATTACH and 257 ATTACH. Perhaps calling the menus attaches the libraries automatically? At any rate, I was tickled to find the compiler right where the manual said it was.
That's a good point. These built-in ROM libraries aren't attached by default, and executing 256 MENU and 257 MENU doesn't attach them, but you can use the menu keys for operations even if the libraries aren't attached; to use them for commands, the libraries have to be attached. That is, if, with them detached, you press a menu key, it works just fine, but if you use it to get the source code into a program, you'll find that it's compiled as a name instead of as a command. But if you compile a program with the commands (with the libraries attached), the program still works even with the libraries detached (as long as the program isn't decompiled and recompiled from source code). To experiment with this difference, just use 256 DETACH and 256 ATTACH.

But my guess is that you installed an extable library (which happens to be a self-attaching library), which automatically attaches libraries 256 and 257 as well. The same holds true for OT49 and perhaps some others. If you find "Development Library" in the list when you press the APPS key, then it's attached.

By the way, the library 257 commands are called by the library 256 commands. The usual recommendation is that you use the library 256 commands instead of using the library 257 commands directly.

Regards,
James

Edited: 13 June 2007, 6:37 p.m.

                        
Re: Seeking Some RPL Tutelage
Message #7 Posted by Giancarlo (Italy) on 13 June 2007, 6:52 p.m.,
in response to message #6 by James M. Prange (Michigan)

Hi James.
Thanks for your attitude towards the beginners :-)
Besides all the references you mention, I also had a look to some of the many patents that concern(ed) the HP calculators logic and architecture
(they can be found at: Eric Smith's HP Patents Repository
I found especially interesting the no. 4868745 (1.1 Mb .pdf file):

Quote:
Data processing system and method for the direct and indirect execution of uniformly structured object types

Of course that was not intended with knowledge dissemination in mind - it's a strictly technical paper
but it may help to grasp some logic behind SysRPL mechanisms (for example: environment stacking or inner loop).
Or, maybe, I just chose another original way of self-punishment ;-)
Best regards.
Giancarlo
                              
Re: Seeking Some RPL Tutelage
Message #8 Posted by James M. Prange (Michigan) on 13 June 2007, 10:32 p.m.,
in response to message #7 by Giancarlo (Italy)

Thanks, that is indeed a "good pointer". I think that I'll have to print the patent out to fully grasp it (and perhaps not even then), but it does explain the basic structure of RPL objects, why they're structured the way they are, and how they're executed.

As a "companion piece" for it, I suggest RPLMan, say, oh, 2.2 through 2.5.

I don't think that the patent information is really "must know" information for an RPL programmer, but it is very basic to RPL, and I like to understand some of the "magic" that the system is doing behind its "smoke and mirrors".

But it seems to me that sooner or later a serious SysRPL programmer is probably going to want to embed some assembly language code within a SysRPL program, and this information seems very relevant for assembly language programming on the RPL models.

Quoting Section 2. of RPLMan:

       2.  RPL Principles

(The following material was excerpted from "RPL: A Mathematical Control Language", by W. C. Wickes, published in "Programming Environments", Institute for Applied Forth Research, Inc., 1988)

That's a document that I'd really like to read.

Regards,
James

                                    
Re: Seeking Some RPL Tutelage
Message #9 Posted by Giancarlo (Italy) on 14 June 2007, 2:22 a.m.,
in response to message #8 by James M. Prange (Michigan)

James,
quoting your quote:

Quote:
Quoting Section 2. of RPLMan: 2. RPL Principles

(The following material was excerpted from "RPL: A Mathematical Control Language", by W. C. Wickes, published in "Programming Environments", Institute for Applied Forth Research, Inc., 1988)

That's a document that I'd really like to read.



I also was very curious about that document and googled a lot, but with no luck :-(
Maybe somebody can provide a good pointer to that...
Best regards.
Giancarlo
                        
Re: Seeking Some RPL Tutelage
Message #10 Posted by Les Wright on 14 June 2007, 10:37 p.m.,
in response to message #6 by James M. Prange (Michigan)

Thanks, James, as always for a rich and informative reply.

I am learning that one can "decompile" a UserRPL program object to a string in SysRPL syntax, where all of the UserRPL commands and symbols are prefixed by x to indicate that a UserRPL command is being invoked. I believe that as I learn more about SysRPL commands and syntax it will be a matter of converting as many of these "x" commands to their native SysRPL equivalents, where they exist, as well as converting the rest of the code to proper SysRPL syntax throughout so it recompiles not as a UserRPL object but a SysRPL object.

I am learning that there are some commands I need that don't seem to have SysRPL versions so I am obliged to use the x version. For example, the UserRPL sequence 'del' STO* would be rendered in SysRPL as ' LAM del xSTO*. Similarly, if I want to call the MTH menu special function Psi, which I use, I have to invoke it with xPsi--there seems to be no SysRPL specific alternative.

But here is a question I have--does using these "x" commands slow things down? Does a program that uses them effectively become a UserRPL program anyway? Would I be better off writing my first example as LAM del %* ' LAM del STO?

Apart from these curiosities, I think it should be feasible for me to write SysRPL versions of some of my little programs. I will let you know how I do.

Les

                              
Re: Seeking Some RPL Tutelage
Message #11 Posted by James M. Prange (Michigan) on 15 June 2007, 1:39 a.m.,
in response to message #10 by Les Wright

Quote:
Thanks, James, as always for a rich and informative reply.
You're welcome.
Quote:
I am learning that one can "decompile" a UserRPL program object to a string in SysRPL syntax, where all of the UserRPL commands and symbols are prefixed by x to indicate that a UserRPL command is being invoked. I believe that as I learn more about SysRPL commands and syntax it will be a matter of converting as many of these "x" commands to their native SysRPL equivalents, where they exist, as well as converting the rest of the code to proper SysRPL syntax throughout so it recompiles not as a UserRPL object but a SysRPL object.
Yes, as I've mentioned before, the UserRPL commands are "special cases" of SysRPL commands. The UserRPL command programs have built-in names for use by the UserRPL compiler, "mark" the stack for the sake of error handling, check for the required arguments, and "dispatch" to the entry point appropriate for the arguments (or cause an error if acceptable arguments aren't on the stack). In SysRPL source code, the UserRPL command names always start with "x", but I've noticed a few non-UserRPL commands that also start with "x"; I'm not sure, but I think that the beginning "x" may mean that the command has the argument checking and so on built-in.
Quote:
I am learning that there are some commands I need that don't seem to have SysRPL versions so I am obliged to use the x version. For example, the UserRPL sequence 'del' STO* would be rendered in SysRPL as ' LAM del xSTO*.
The LAM del indicates that 'del' is a local name (from LAMbda variable). If 'del' were a global name, then it would decompile to ID del.

Yes, the UserRPL command STO* doesn't seem to have any SysRPL equivalent without the "check and dispatch' code built-in. Using Nosy, I find that STO* requires two arguments and, depending on the argument types, dispatches (on my 49g+) to the routine PTR 2F2AF, PTR 2F2B0, PTR 2F30C, PTR 2F2B4, or PTR 2F30D. Now, since the entry points show up as pointers instead of SysRPL command names, they aren't in my extable library (I think Carsten's extable2), so are "unsupported" entry points. You could use a tool like Nosy to find the entry points in your ROM and use whichever one is appropriate for your arguments, but if it's unsupported, then there's a risk that it could be different in a different ROM revision.

Quote:
Similarly, if I want to call the MTH menu special function Psi, which I use, I have to invoke it with xPsi--there seems to be no SysRPL specific alternative.
Using Nosy, this seems to be a case similar to STO*, except using one argument and dispatching to FPTR 7 133, FPTR 7 135, or FPTR 7 11F. However, searching progsysrpl.pdf for "Psi", I also find ^SYMPSI, ^SYMPSIN, and ^%%PSI. I see that Psi is a digamma function, and searching for "digamma" finds these same three entries, one of which might be appropriate for your use.

Starting the name with "^" is a convention indicating that the entry is a "flashpointer", and to use it, you have to prefix the name with FPTR2, for example, FPTR2 ^SYMPSIN. Another convention is that "rompointer" entries start with "~", and to use one you have to prefix it with ROMPTR.

Quote:
But here is a question I have--does using these "x" commands slow things down?
Yes, using them means that for each such "x" command, its "check and dispatch" code will be used, which does take a little time.
Quote:
Does a program that uses them effectively become a UserRPL program anyway?
Yes, if your SysRPL program uses only these "x" commands. In most cases, decompiling them to the command line editor will show the UserRPL command names.
Quote:
Would I be better off writing my first example as LAM del %* ' LAM del STO?
Maybe; that would increase the program size, but it might run a little faster, which may be important if, for example, it were within a loop or a frequently used subroutine. I suggest trying it both ways to find out whether one method has any significant advantage.
Quote:
Apart from these curiosities, I think it should be feasible for me to write SysRPL versions of some of my little programs. I will let you know how I do.
I wish you the best of luck with this.

Regards,
James

Edited: 15 June 2007, 2:08 a.m.

                                    
Re: Seeking Some RPL Tutelage
Message #12 Posted by Les Wright on 15 June 2007, 3:39 a.m.,
in response to message #11 by James M. Prange (Michigan)

Thanks James.

I really want to do some work in SysRPL with the extended real type so that when my results are converted back to the real type and returned to the stack they are more likely to be fully accurate since the guard digits absorbed rounding error.

But I think I will have to approach the question of convergence differently. In my UserRPL numeric programs, I can cavalierly specify exact equality of a final and penultimate result as a stopping criterion, since results are rounded from 15 to 12 digits when returned to the stack BEFORE comparison so rounding error and "wiggle" in the least significant digits occurs internally in the guard digits. But if I work with extended reals internally, I think that could be an unrealistic goal--the 15 digits you work with are IT. I am guessing that 5E-15 a good epsilon to work with for the extended real type. Does anyone have much programming working with the extended real type within SysRPL programs?

Les

                                    
I did it!
Message #13 Posted by Les Wright on 15 June 2007, 4:45 a.m.,
in response to message #11 by James M. Prange (Michigan)

Quote:

I wish you the best of luck with this.


I have an admittedly not complex routine that computed the incomplete gamma function using the modified Lentz algorithm on the continued fraction. Indeed, the UserRPL routine is ported straight out of the Numerical Recipes in C version.

I managed to port the entire thing to SysRPL, using just a few key concepts--LAM local variables, a BEGIN..UNTIL loop, and a couple of IT conditional tests. I conducted all of the internal math in extended reals, which probably slows things a tiny bit. But, it works fine, and in comparison a few results with Maple, all 12 digits always seems to match, while the original UserRPL version is often off one or two ULP. And it seems perceptibly faster too, though this is hard to tell since the UserRPL version isn't so slow.

My next tasks are to go over it to see if I can make it more concise (user RPL has quite a few compound commands that I could capitalize on), and to add input checking in case I try to run it on anything that will make the calc crash.

But so far, when it comes to using SysRPL to write quick accurate numerical algorithms on the 49G+/50G, I think I have become a believer. Good for me!

Les

Edited: 15 June 2007, 4:46 a.m.

                                          
Re: I did it!
Message #14 Posted by Les Wright on 15 June 2007, 10:36 a.m.,
in response to message #13 by Les Wright

Quote:
My next tasks are to go over it to see if I can make it more concise (user RPL has quite a few compound commands that I could capitalize on), and to add input checking in case I try to run it on anything that will make the calc crash.

In particular, if the calc is not in Approx mode, both arguments need to be entered as approximate numbers (including a decimal point even if integers) otherwise the thing just hangs! I am sure there is a SysRPL command to check for that....

So much to learn, but I am positively tickled that I have written a working SysRPL program that is perceptibly superior to its UserRPL equivalent. Being able to tap into the extended reals is a great find for me--I am interested more in numerical work than symbolic work, so getting full 12-digit accuracy in the final results is very exciting indeed.

If anyone is interested in this sort of math programming, I can post what I have turned out once I reformat the source code file to make it more readable.

Les

Edited: 15 June 2007, 10:39 a.m.

                                                
Re: I did it!
Message #15 Posted by James M. Prange (Michigan) on 16 June 2007, 8:21 p.m.,
in response to message #14 by Les Wright

Congratulations! I'm glad to read that.

Quote:
In my UserRPL numeric programs, I can cavalierly specify exact equality of a final and penultimate result as a stopping criterion, since results are rounded from 15 to 12 digits when returned to the stack BEFORE comparison so rounding error and "wiggle" in the least significant digits occurs internally in the guard digits. But if I work with extended reals internally, I think that could be an unrealistic goal--the 15 digits you work with are IT.
Even in UserRPL, equality wouldn't be such a good stopping criterion, because changing the input may well result in a larger change in the result, so the smallest possible input change may result in a change of sign in the result with a difference of zero not being achievable.

To get really fussy about it, several consecutive numbers may result in a difference of zero, so perhaps if a zero is achieved, one could check on both sides of the input value for the smallest and largest inputs that results in zero, and average them.

Quote:
I am guessing that 5E-15 a good epsilon to work with for the extended real type.
Ah, determining an appropriate epsilon (what's "close enough") is a very interesting question.

It seems to me that epsilon ought to be related to the magnitude of the value.

If you're converting the result from an extended real to a real, then I'd base epsilon on the real.

Maybe (for a real) make epsilon 10 to the power of (exponent-11)? I'm referring to the exponent of the smaller of two successive values. UserRPL has the built-in EXPN command (%EXPONENT in SysRPL). There doesn't seem to be any RPL command for getting the exponent of an extended real though.

I'll think about this, and perhaps post more on it later.

Quote:
I conducted all of the internal math in extended reals, which probably slows things a tiny bit.
I don't know for certain, but I'd expect operations with extended reals to be slower because they use two Saturn registers instead of only one, so it may take more cycles to process them. Other than that, the body of a real is 16 nibbles (the size of a register), but the body of an extended real is 21 nibbles, and of course I/O between memory and the processor is one nibble at a time (the bus is 4 bits wide), so it makes sense that the 5 extra nibbles would take more time. Of course the 3 extra digits in the mantissa and 2 extra digits in the exponent result in a finer resolution and increased range, so may well be worth it.
Quote:
And it seems perceptibly faster too, though this is hard to tell since the UserRPL version isn't so slow.
For comparing the execution time of different programs, on the 49 series, you can use the UserRPL command TEVAL (Timed EVALuation). Note that if you execute an object by name, the time to find and retrieve the variable will be included in the timing, so I recommend putting the object itself on the stack and then running the timing command.

In earlier ROMs, TEVAL had a bug in that it used the current wordsize, which, if too small, caused an erroneous result, but that's been fixed in the current ROM. Strangely enough, TEVAL now temporarily forces a wordsize of 60. I don't know how this particular value was chosen; the system time is 52 bits, so a wordsize of 52 would've been large enough, and going all the way to the maximum wordsize of 64 would've worked just as well, but 60 does work.

TEVAL still has a relatively minor flaw in that it doesn't compensate for the time required to get the system times or the time to store the initial system time, so it slightly overestimates the execution time of the object, but that doesn't affect finding the difference in execution time of different objects.

For a UserRPL timing program that uses a compensation time (but you have to determine it for the particular calculator yourself and edit it into the program), see my EVAL TIMER package, which also works on the 48 series, and includes versions for the 28 series.

Bill Wickes's timing program in Insights, which was the original basis of my programs, checks the type of an argument, and if it's a name, then recalls the object to the stack before starting the timing, thus eliminating the time to resolve the name and recall the object to the stack. The way I see it, one might want to include that time, so I eliminated that code for my program; I can alway put the object on the stack myself.

Repeated timings usually show very slightly different results, so you may want to repeat the timing a few times and average the results.

Quote:
My next tasks are to go over it to see if I can make it more concise (user RPL has quite a few compound commands that I could capitalize on),
Yes, programs can often be optimized. The usual goals are some combination of smaller size and faster execution, which often (but don't always) go hand-in-hand. This often makes a program more difficult to read and understand though; you may well want to save the source code with comments as a PC file, while it's still fresh in your mind (if you didn't write it on the PC in the first place).
Quote:
and to add input checking in case I try to run it on anything that will make the calc crash.
Yes, unless you're certain that you'll never run a SysRPL program without the proper arguments, using the "check and dispatch" code at the beginning of the program is essential
Quote:
In particular, if the calc is not in Approx mode, both arguments need to be entered as approximate numbers (including a decimal point even if integers) otherwise the thing just hangs! I am sure there is a SysRPL command to check for that....
I'm sure that there is, or to convert an exact to a real, for that matter, but this can be taken care of in the check and dispatch code. CK&DISPATCH0 looks for argument permutations and causes an error if valid arguments aren't available, but with CK&DISPATCH1, if valid arguments aren't found, then it strips all tags from the arguments and converts exact to reals, and then checks again.
Quote:
Being able to tap into the extended reals is a great find for me--I am interested more in numerical work than symbolic work, so getting full 12-digit accuracy in the final results is very exciting indeed.
Good point! I usually neglect to mention this, but the extended reals (and extended complex numbers) are indeed an important advantage to writing your own SysRPL programs.

If you really want to, you can leave the result on the stack as an extended real, and set flag -85 to read it.

Regards,
James

                                                      
Re: I did it!
Message #16 Posted by Les Wright on 17 June 2007, 12:22 a.m.,
in response to message #15 by James M. Prange (Michigan)

Quote:
(and extended complex numbers)

Funny you should mention this!

I have been chagrined to learn that in HP49 SysRPL there seem to be no commands to do basic complex arithmetic on extended complex numbers. Indeed, there don't seem to be ones to do basic arithmetic on even regular complex numbers! I have checked both the 2nd edition of Kalinowski and Dominik and the most recent version of the HP49G Entry Reference. No luck.

In a recent thread in comp.sys.hp48 I have raised this very issue. Raymond del Tondo replied to indicate that there are indeed such commands (C%C+C, C%%C/C, C%%*C, C%C-, etc.) for HP48 SysRPL. They are listed in the first edition of Kalinowski and Dominik as unsupported entry points, but I can find no mention of them in any stuff on HP49 SysRPL.

So I am at a loss at how to do basic arithmetic with regular complex numbers, never mind extended ones! For regular complex numbers, I guess one resorts to the UserRPL arithmetic functions x+, x*, x-, x/, but as for extended complex numbers--well, I guess I just have to write code that adds or subtracts the real and imaginary parts separately and performs multiplication, division, and exponents and the like on the polar versions of my numbers.

There must be a better way! How do other people program extended complex numbers in HP49 SysRPL?

Les

                                                            
Re: I did it!
Message #17 Posted by James M. Prange (Michigan) on 18 June 2007, 8:24 p.m.,
in response to message #16 by Les Wright

Quote:
Quote:
(and extended complex numbers)
Funny you should mention this!

I have been chagrined to learn that in HP49 SysRPL there seem to be no commands to do basic complex arithmetic on extended complex numbers. Indeed, there don't seem to be ones to do basic arithmetic on even regular complex numbers! I have checked both the 2nd edition of Kalinowski and Dominik and the most recent version of the HP49G Entry Reference. No luck.


It seems that I should've checked on what's actually available before posting!

Okay, also try searching for "C%%" or "C%" in progsysrpl.pdf (2nd edition), and in Carsten's entry points table for the 49 series.

There seem to be very few commands for extended complex numbers, and even some that would seem rather basic for complex numbers don't seem to be available (for complex numbers only).

Note that the extable libraries also provide the GETNAMES and GETNEAR library commands, but GETNEAR will also find "POPC%%" and "PUSHC%%", which are routines intended for use in Saturn assembly language, not for use in SysRPL.

As I mentioned before, the use of some SysRPL commands may be an exercise for the student, possibly including experimentation. Of course, this may result in memory corruption, so having a recent back-up is essential.

Try to remember that much of the documentation of SysRPL, particularly for the 49 series, is due to the efforts of unpaid volunteers. Of course, if they didn't have much knowledge of a particular topic, then they didn't provide much information about it.

Quote:
In a recent thread in comp.sys.hp48 I have raised this very issue. Raymond del Tondo replied to indicate that there are indeed such commands (C%C+C, C%%C/C, C%%*C, C%C-, etc.) for HP48 SysRPL. They are listed in the first edition of Kalinowski and Dominik as unsupported entry points, but I can find no mention of them in any stuff on HP49 SysRPL.
Well, Raymond seems to be sticking to the 48 series, so probably assumed that SysRPL commands available in the 48 series are still available in the 49 series. Actually, I expect that these unsupported 48 series entry points still have (perhaps moved) unsupported entry points in the 49 series, but no one has bothered to publish names for them.

Of course, the 48 series has been discontinued, so we can be confident that even "unsupported" entry points aren't going to change in some future 48 series ROM version (although they may have moved in existing ROM versions), but for the 49 series, even if an unsupported entry point hasn't already moved, it may indeed change in any future 49 series ROM revision.

Quote:
So I am at a loss at how to do basic arithmetic with regular complex numbers, never mind extended ones! For regular complex numbers, I guess one resorts to the UserRPL arithmetic functions x+, x*, x-, x/,
If one wants the program to be portable to other ROM revisions, that indeed seems the best method. The disadvantage is that for these UserRPL entry points, at least part of their check and dispatch code will be executed, taking some time.

Other than that, you can use Nosy to see what these commands dispatch to for a pair of complex numbers (probably an unsupported entry point) and use that, but it may not work with a different ROM revision.

Quote:
but as for extended complex numbers--well, I guess I just have to write code that adds or subtracts the real and imaginary parts separately and performs multiplication, division, and exponents and the like on the polar versions of my numbers.
Although you might be able to use Nosy to find commands that convert complex numbers to extended complex numbers and then find entry points that use the extended complex numbers, I guess that converting to extended reals and dealing with the real and imaginary parts separately would probably be the best method.
Quote:
There must be a better way! How do other people program extended complex numbers in HP49 SysRPL?
I don't know; most of the programs that I've seen don't use complex numbers at all, and I don't think that I've ever seen one that uses extended complex numbers. My guess is by converting them to pairs of extended real numbers.

Try to remember the purposes of SysRPL. First and foremost, to make it easier for HP's own developers to write firmware for new calculator models without writing in assembly or machine language so much. Second (and seemingly as an after-thought), for 3rd-party developers to write relatively small and fast external applications for RPL-based calculators. With the 49 series, HP advertises the (more or less) built-in SysRPL and assembly language capabilities of these models, but note that these are really intended for "advanced users" ("developers"), HP doesn't provide much (if any) documentation for them, and (as you've found) using them isn't always easy.

Regards,
James

Edited: 19 June 2007, 3:24 p.m.

                                                                  
Re: I did it!
Message #18 Posted by Les Wright on 19 June 2007, 10:21 p.m.,
in response to message #17 by James M. Prange (Michigan)

Quote:

I don't know; most of the programs that I've seen don't use complex numbers at all, and I don't think that I've ever seen one that uses extended complex numbers. My guess is by converting them to pairs of extended real numbers.


Well, looks like I have myself a fun little project then!

JM Baillard's HP41 code for cosine and sine integrals by complex continued fraction moves back and forth between rectangular and polar mode, since complex numbers are readily added in rectangular form but multiplied, divided, and raised to powers in polar form.

I love math. Could be fun.

Les

P.S. I am getting better at optimizing my little SysRPL programs. Right now in some code I have gotten rid of named local variables and have used NULLLAMs--the speed gain is remarkable. My next step is to rely even less on local variables and try to keep what I need on the stack as much as possible. The most artful UserRPL programs I have seen don't use local variables at all, and I would gather their SysRPL translations are quite fast.

                                                                        
Re: I did it!
Message #19 Posted by Les Wright on 21 June 2007, 1:37 a.m.,
in response to message #18 by Les Wright

Quote:

JM Baillard's HP41 code for cosine and sine integrals by complex continued fraction moves back and forth between rectangular and polar mode, since complex numbers are readily added in rectangular form but multiplied, divided, and raised to powers in polar form.


This turns out to be fairly easily implemented in SysRPL after all.

At first I thought I would need to also produce from scratch an extended precision way of computing the arctangent function, which of course is required in computing the argument of the polar form of the complex argument from its cartesian form. There are no extended precision versions of the inverse trig functions in HP49 SysRPL, at least not that I can find.

BUT, even better, there ARE extended precision polar-rectangular conversions! %%R>P and %%P>R are there, and in testing some simple inputs the functions seem to work quite well. (Of course, this means that there is indeed an extended arctan function present, but only indirectly. arctan(x) is simply the second piece of the output of R>P acting on rectangular coordinates (1,x) or some multiple of these.)

So this is going to be not so hard after all. When adding two full precision complex numbers, I simply add the real and imaginary parts. When multiplying (or dividing) them, I do the conversion to polar form via %%R>P, carry out the binary operation using the usual rules (multiply moduli together and add the arguments) and convert back to rectangular form as required via %R>P. Powers, square roots and inverses can all be handled by De Moivre's rule acting on the polar form.

So it can be done, and not so onerously at that. May not be perfectly swift, but at least it is feasible, and the innards are not so horrid to contemplate after all, especially with those extended precsion rectangular polar conversions. And even though extended precision inverse trigs are not there, %%SIN and %%COS, which I need, are very much alive and well and living at stable addresses in the HP49.

I will let you know how far I get. If programming basic arithmetic on extended precision complex numbers is not commonplace for the 48 or 49 series, this could be a new little adventure!

Les

Edited: 21 June 2007, 7:52 p.m. after one or more responses were posted

                                                                              
Re: I did it!
Message #20 Posted by James M. Prange (Michigan) on 21 June 2007, 7:08 p.m.,
in response to message #19 by Les Wright

Quote:
Right now in some code I have gotten rid of named local variables and have used NULLLAMs
I expect that Les has already discovered at least most of this, so the following is mostly for the benefit of anyone else who's curious.

Of course all local variables do have names (otherwise they wouldn't be variables), but they can have the "null local name".

A lam (local name) object consists of the 5-nibble prologue address, followed by a 2-nibble character count, followed by 2 nibbles for each character in the name, thus a lam's size (in bytes) is 3.5 plus the number of characters in the name.

We can have a valid lam with a character count of zero (and no nibbles following), which would take 3.5 bytes, and such an object is already built in to ROM, and the built-in object can be accessed by a 2.5 byte pointer.

An interesting point is that we can have as many local variables with the same name (even in the same local environment) as we choose, however, if we use a name to access a local variable, then we can access only the most recently created local variable with that particular name.

So how can we access other local variables with the same name? Well, in SysRPL, several commands for binding null lams to objects (thus creating null-named local variables) and for accessing local variable by position are provided, with the most recently bound having the position 1.

Quote:
--the speed gain is remarkable.
And the (compiled) code size is reduced too. Of course the disadvantage is that the programmer has to keep track of the current positions of his local variables, similar to the chore of keeping track of stack levels.
Quote:
My next step is to rely even less on local variables and try to keep what I need on the stack as much as possible. The most artful UserRPL programs I have seen don't use local variables at all, and I would gather their SysRPL translations are quite fast.
In general, keeping objects on the stack is faster than using ordinary named local variables (assuming efficient stack manipulation), but I expect that this is largely due to the time required to handle the names, particularly searching local environments for particular names. I don't know how much (if at all) faster using the stack instead of null-named local variables would be; maybe try it and compare execution times.

Note that the built-in commands use them quite often, so it seems that the HP developers didn't think that they were too bad.

Quote:
This turns out to be fairly easily implemented in SysRPL after all.
Well, I'm glad that you found some extended real functions that are very useful for your purposes. Maybe searching the documentation for "%%" would find more?

Just speculating, but maybe their existence helps explain why the developers apparently didn't feel a pressing need to include very many supported extended complex functions?

Of course, you may find it useful to make sub-routines for frequently used sequences.

Quote:
At first I thought I would need to also produce from scratch an extended precision way of computing the arctangent function, which of course is required in computing the argument of the polar form of the complex argument from its cartesian form. There are no extended precision versions of the inverse trig functions in HP49 SysRPL, at least not that I can find.

BUT, even better, there ARE extended precision polar-rectangular conversions! %%R>P and %%P>R are there, and in testing some simple inputs the functions seem to work quite well. (Of course, this means that there is indeed an extended arctan function present, but only indirectly. arctan(x) is simple the second piece of the output of R>P acting on rectangular coordinates (1,x) or some multiple of these.)


Hmm, using Nosy on "%%R>P", I find:
::
  PTR 10594
  3UNROLL
  %%ANGLE
;
Following PTR 10594, I find:
::
  2DUP
  PTR 0FF94
  %%SQRT
;
Following PTR 0FF94, I find:
::
  DUP
  %%*SWAP
  DUP
  %%*
  %%+
;
Of course, following %%*SWAP, I find:
::
  %%*
  SWAP
;
So, in 100% supported SysRPL, %%R>P could be replaced by:
[pre]
::
  ::
    2DUP
    ::
      DUP
      ::
        %%*
        SWAP
      ;
      DUP
      %%*
      %%+
    ;
    %%SQRT
  ;
  3UNROLL
  %%ANGLE
;
Of course there's no need for nesting the secondaries in the above, so we could use:
::
  2DUP          (copy both arguments)
  DUP           (square copy of 2nd argument)
  %%*
  SWAP          (move copy of 1st argument down)
  DUP           (square copy of 1st argument)
  %%*
  %%+           (add the squares)
  %%SQRT        (square root of sum of squares)
  3UNROLL       (move original argument pair down)
  %%ANGLE       (ATAN of level 1 divided by level 2?)
;
Does that make sense? I'm guessing that the arguments are x on level 2 and y on level 1, but perhaps they're reversed from that. Anyway, I think that %%ANGLE (but taking 2 arguments as the denominator and numerator of a rational number) is the substitute for the desired %%ATAN (taking 1 argument as a decimal rational number).

But what does the result of %%ANGLE represent? An angle, but in radians, degrees, or grads? Of course you can (and should) experiment, but I also see %%ANGLERAD and %%ANGLEDEG, and my guess is that maybe it represents the angle in the current mode.

Quote:
I will let you know how far I get.
When you get programs that you're proud of, please consider submitting them to hpcalc.org. Preferably include the source code, and even better, commented source code.
Quote:
If programming basic arithmetic on extended precision complex numbers is not commonplace for the 48 or 49 series, this could be a new little adventure!
I really don't know how commonplace it is; maybe search at hpcalc.org.

Regards,
James

Edited: 21 June 2007, 7:37 p.m.

                                                                                    
Re: I did it!
Message #21 Posted by Les Wright on 21 June 2007, 7:49 p.m.,
in response to message #20 by James M. Prange (Michigan)

James, it will take me a little time to fully digest your post, but I did stumble across %%ANGLE and, indeed, it's existence really does make redundant need for an extended precision %%ATAN. As you have intuited, if x is on level 2 and y is on level 1, %%ANGLE returns arctan(y/x) in the angle mode of the calculator. For example, the code :: 2%>%% %%ANGLE ; when compiled and acting on input 3 ENTER 4, will return %% 9.27295218001615E-1 radian, which is almost exactly the correct 15-digit result for arctan (4/3) (the last digit should be a 2). In normal precision computing on the actual calculator, 4 ENTER 3 / lShift ATAN returns .927295218, whereas the proper 12-digit answer should be .927295218002. I haven't experimented yet with %%ANGLEDEG and %%ANGLERAD, but I gather they force the specified mode in the output irrespective of the calculator's angular mode.

Using null lams in non-nested code is pretty straightforward. In nested code, keeping track of the numbering when binding new null lams without unbinding old ones can be tricky. If I have to go this route I will make sure that internal subroutines that use null lams close with ABND where possible to ensure there isn't numbering conflict with the main code.

I didn't search hpcalc.org too closely for SysRPL routines that compute with extended precision complex numbers. I guess I was really looking to do the programming myself.

Thanks as always for your detailed and astute contributions.

Les

Edited: 21 June 2007, 7:50 p.m.

                                                                                          
Re: I did it!
Message #22 Posted by Paul Dale on 21 June 2007, 8:28 p.m.,
in response to message #21 by Les Wright

Not complex and not hpcalc.org but I did do a little with extended precision reals (log to any base and harmonic mean from memory) back on comp.sys.handhelds probably fifteen years ago.

- Pauli

                                                                                          
Re: I did it!
Message #23 Posted by Les Wright on 21 June 2007, 9:42 p.m.,
in response to message #21 by Les Wright

Quote:
In normal precision computing on the actual calculator, 4 ENTER 3 / lShift ATAN returns .927295218, whereas the proper 12-digit answer should be .927295218002.

I should emphasize of course that this is NOT a bug in the calculator. .927295218000 radian is indeed the correct 12 digit approximation to the arctangent of 1.33333333333, which of course is not exactly 4/3. Alas, applying ->NUM in exact mode to ATAN(4/3) seems to reduce 4/3 to the 12 digit decimal approximation first, then takes the arctangent, so you get the arctangent of the approximation, not the original exact fraction. To get the exact arctan of 4/3 without a SysRPL program, (3,4) ARG returns the correct 12 digit result. Indeed, in situations where high accuracy is desired, this is probably the way to do it.

I have long been interested in maximizing accuracy in floating point calculation on calculators, even though this is not necessary in the real world usually. Free42 Decimal, with its 25-digit internal digits always accessible to the user, has been one way to do this. Now, extended reals in SysRPL is another, only this time on a "real" calculator and not a simulator. Neat....

Les

                                                                                    
Re: I did it!
Message #24 Posted by James M. Prange (Michigan) on 21 June 2007, 8:19 p.m.,
in response to message #20 by James M. Prange (Michigan)

PS:

Progsysrpl.pdf gives us some stack diagrams, for example:

30767 %%ANGLERAD ( %% -> %%' )
3073A %%ANGLE ( %%x %%y -> %%ang )
30757 %%ANGLEDEG ( %%x %%y -> %%deg )
30E83 %%R>P ( %%x %%y -> %%radius %%angle )
30EB0 %%P>R ( %%r %%ang -> %%x %%y )
30693 %%TANRAD ( %%rad -> %%tan )
It isn't obvious to me what %%ANGLERAD and %%TANRAD are for.

Regards,
James

                                                                                          
Re: I did it!
Message #25 Posted by James M. Prange (Michigan) on 21 June 2007, 8:30 p.m.,
in response to message #24 by James M. Prange (Michigan)

PPS:

Given an angle in radians (regardless of the current mode) as an extended real, %%TANRAD seems to return the tangent of that angle as an extended real.

Regards,
James

Edited: 21 June 2007, 8:32 p.m.

                                                                                                
Re: I did it!
Message #26 Posted by James M. Prange (Michigan) on 21 June 2007, 8:42 p.m.,
in response to message #25 by James M. Prange (Michigan)

PPPS:

And it seems that regardless of the current mode, %%ANGLERAD converts the value of an angle in degrees to its value in radians. Both as extended reals, of course.

Wow, as I use my calculators for trigonometry a lot, I suppose that I should've known all of this already. But the UserRPL results are usually plenty close enough for my purposes.

Regards,
James

Edited: 21 June 2007, 8:46 p.m.

                                                                                                      
Re: I did it!
Message #27 Posted by Les Wright on 21 June 2007, 9:45 p.m.,
in response to message #26 by James M. Prange (Michigan)

Quote:
PPPS:

And it seems that regardless of the current mode, %%ANGLERAD converts the value of an angle in degrees to its value in radians. Both as extended reals, of course.

Wow, as I use my calculators for trigonometry a lot, I suppose that I should've known all of this already. But the UserRPL results are usually plenty close enough for my purposes.

Regards,
James


James, the Kalinowski and Dominik opus, along with its companion listing of HP49 Entry Points, provides only scanty info on the use of so many functions. One has to often infer it from the stack diagrams. As you have seen, this most of the time seems not to be too abstruse. Les

                                    
Re: Seeking Some RPL Tutelage
Message #28 Posted by James M. Prange (Michigan) on 19 June 2007, 9:04 p.m.,
in response to message #11 by James M. Prange (Michigan)

I wrote:

Quote:
Carsten's extable2
A correction: Thomas Rast should get the credit for extable2.

Regards,
James

                        
Re: Seeking Some RPL Tutelage
Message #29 Posted by James M. Prange (Michigan) on 19 June 2007, 8:58 p.m.,
in response to message #6 by James M. Prange (Michigan)

I wrote:

Quote:
"Unsupported" entry points may well change with any ROM revision, so are best avoided. But Jean-Yves mentioned some ranges of entry points that won't move, and these are the "unsupported but stable" entry points that are probably okay to use. He isn't employed by HP any more, but they haven't moved yet. But if HP releases another series of RPL models, even the "supported" entry points may move.

Reviewing the comp.sys.hp48 post, I find that his wording wasn't so strong as "won't move", but I believe that those ranges are what the "unsupported but stable" entry points for the 49 series are based on.

Of course there may turn out to be other unsupported entry points that always stay at the same address (stable), but even if they haven't moved yet, there's no guarantee that they won't in some future ROM revision.

Regards,
James

      
Re: Seeking Some RPL Tutelage
Message #30 Posted by Kiyoshi Akima on 14 June 2007, 1:13 p.m.,
in response to message #1 by Les Wright

You can find some of my attempts at SysRPL at

http://kiyoshiakima.tripod.com/funprogs/index.html

One of those (bifurcation diagrams) starts with a UserRPL program and then develops six different SysRPL programs, adding (mis)features.

Note corrected link. My bad...

Edited: 15 June 2007, 1:10 p.m. after one or more responses were posted

            
Re: Seeking Some RPL Tutelage
Message #31 Posted by Giancarlo (Italy) on 14 June 2007, 4:00 p.m.,
in response to message #30 by Kiyoshi Akima

Hi Kiyoshi.
Would you please be so kind to check the link you provided, as it seems ureachable....
Thanks in advance.
Best regards.
Giancarlo


[ Return to Index | Top of Index ]

Go back to the main exhibit hall