Seeking Some RPL Tutelage



#29

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


#30

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
#31

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.


#32

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.


#33

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

#34

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.


#35

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

#36

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


#37

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
#38

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


#39

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.


#40

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

#41

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.


#42

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.


#43

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


#44

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


#45

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.


#46

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.


#47

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


#48

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.


#49

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.


#50

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

#51

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

#52

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


#53

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.


#54

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.


#55

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

#56

I wrote:

Quote:
Carsten's extable2

A correction: Thomas Rast should get the credit for extable2.

Regards,
James

#57

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

#58

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


#59

Hi Kiyoshi.

Would you please be so kind to check the link you provided, as it seems ureachable....

Thanks in advance.

Best regards.

Giancarlo


Possibly Related Threads...
Thread Author Replies Views Last Post
  Writing RPL programs on OS X Sean Freeman 18 2,330 11-30-2013, 03:59 PM
Last Post: Sean Freeman
  48G vs 49G+ User RPL Speed Comparison John Colvin 7 1,069 11-16-2013, 10:07 PM
Last Post: Han
  RPL 32 David Hayden 4 884 11-11-2013, 11:34 AM
Last Post: David Hayden
  HHC / HP Museum Programming Contest for RPN and RPL machines Gene Wright 18 2,216 09-22-2013, 09:39 AM
Last Post: Miguel Toro
  Seeking DIY4X update David Griffith 10 1,274 11-15-2012, 12:41 AM
Last Post: Eric Smith
  RPL long vs. short names peacecalc 5 884 10-30-2012, 01:25 PM
Last Post: peacecalc
  Mini-challenge: HHC2012 RPL programming contest with larger input David Hayden 14 1,735 10-05-2012, 10:36 PM
Last Post: David Hayden
  HHC 2012 RPL Programming Contest Gene Wright 33 3,223 09-27-2012, 01:57 AM
Last Post: Werner
  HHC 2012 programming contests coming soon (RPN and RPL) Gene Wright 9 1,224 09-21-2012, 03:38 PM
Last Post: Paul Dale
  Seeking new resources for TI NSpire Programming Namir 6 996 07-29-2012, 03:57 AM
Last Post: fhub

Forum Jump: