|Re: HP48 RPL HELP. . .|
Message #5 Posted by James M. Prange on 11 Aug 2002, 11:03 p.m.,
in response to message #4 by Vieira, Luiz C. (Brazil)
First, my apologies for my gaffe of using your surname in my previous
You are right: I confused GROB for PICT. The sort of maneuver with PICT
is what I mentioned as confusing; PICT is a name, an object and you can
deal with the name as you deal with the object; if you recall its
contents to the stack, is becomes a Graphic lll X ccc; if you type in
PICT and press [ENTER], you place PICT in the stack, no ' surrounding
it; if you have a graphics object in level 1, you can type in PICT and
press [STO]. Sometimes I feel confused about what I am dealing with...
I think that the word GROB is, properly speaking, an object delimiter.
If you do LCD\->, then you'll see something like Graphic 131 x 64 on
level 1. If you EDIT this object, then your command line will start with
GROB (the beginning delimiter for the object), then 131 64 (the
dimensions of the object), and finally what looks like a very long
string of hexadecimal (even if the calc isn't in HEX mode) digits. No
trailing base indicator is needed because it's always displayed in hex
format, and no ending delimiter is needed because the length can be
computed from the dimensions.
Ah, yes. PICT is indeed a very strange word. In his "HP 48 Insights"
books, Bill Wickes refers to it as a "pseudo-name". It's actually a
built-in command (but with very strange syntax for an RPL command),
rather like the "symbolic constants" \pi, e, i, MAXR, and MINR are
actually built-in functions rather than reserved variables, regardless
of what you've read about them.
Quoting from "Insights":
"PICT is actually a command (type 19), but you can use it in two ways:"
"1. As a graphics object. PICT can be used as an argument for commands
that work with graphics objects: SIZE, SUB, GOR, GXOR, and REPL. For
the last three commands, PICT may only be used as the first (level 3)
argument. With that argument, the three commands return no result to
the stack--the result becomes the new picture screen. Furthermore,
there are operations on the PICT grob that are not provided for other
grobs: line, box, and arc drawing, and the ability to control and test
individual pixels in the grob."
"2. As a "variable." Using PICT like a quoted name allows you to treat
the picture screen like a variable containing a grob representing the
current picture. Specifically, grob PICT STO stores
grob into the picture screen, replacing the current
contents; PICT RCL returns the current contents of the picture screen to
the stack as a graphics object, and PICT PURGE deletes the picture
screen and recovers the associated memory. Note: you should not use ' '
quotes around PICT."
I thought that the listing posted by Tal was incomplete. I thought a
program was created within the main program, so the first << and
something else was missed. After your analysis, I realized I was trying
to see more than it was really shown. Checking for XXX existence is the
I think that it was indeed incomplete, and he was indeed making the
'XXX' variable within a larger program, with the beginning "to be
What I did not understand is the fact that the default condition is
overwriting existing variables.
A "design choice" I suppose. It seems "natural" to me, but I'm
accustomed to this behaviour all the way back to the 28S.
The SysRPL entry CREATE is sometimes a useful variation. It's much like
STO, except that even if a variable with the same name already exists in
the current directory, a new variable will be made. Since it's at the
beginning of the directory, it will be found quite quickly (as long as
you don't change directories). This has some of the advantages of local
variables, and can be used where a local variable won't work. But (like
a local name) you won't be able to use any other variable with that name
in the same directory as long as the new one exists, so you'll probably
want to be sure to PURGE the new one when you're finished with it.
I stumbled across a use of CREATE by the plotter by repeatedly pressing
ON-C to break out of some very slow plots, and finding two variables
named 'X' at the beginning of the current directory. Apparently, by
warmstarting, I didn't give the plotter time to "clean up" after itself.
A bit disconcerting, to say the least, but basically harmless.
One question: the 'XXX1' solution would be 'XXX.1' solution for
transferred files (flag -36 controls overwriting, as mentioned), but...
is there a SysRPL entry that allows the generation of a new file name,
like 'XXX.1', when the duplicated file comes from a program command?
An excellent question; I wish I knew! It seems to me that since this
works with Kermit transfers, there ought to be a SysRPL entry for it,
but perhaps it's an "unsupported" entry. It would be very useful indeed
to have a variation of STO that "renames" if the name matches an already
I did not get into SysRPL so far
I'm barely "into" it myself. UserRPL usually suffices for my purposes:
"ad hoc" programs used only by myself and not used all that many times,
so it's not really worth the time to "optimize" them, let alone use
SysRPL to write them and have a greater risk of a "Try To Recover
Memory?" when I need to get some "real work" done ASAP. But knowing a
bit about the "internals" does, I believe, help me to use UserRPL
better, and occasionally I do use a SYSEVAL in my programs. But as a
hobby, it's fun to optimize a program for size, speed, or memory use.
Maybe one of these days.
(I do not have a complete
documentation; any suggestion?), but knowing about it would be great!
I'm not sure that anyone, maybe not even HP, has "complete
documentation". For a start, I'd suggest
http://www.math.fu-berlin.de/~raut/, and of course,
http://www.hpcalc.org/. I consider RPLMAN.DOC from the old HP
Tools on Goodies Disk 4 (see
http://www.hpcalc.org/details.php?id=235) to be THE basic
reference for SysRPL, but I've read that it's available in other (PDF or
PostScript?) formats elsewhere on hpcalc.org.
Note that the SysRPL entries (especially the "unsupported" ones) for the
various models differ; be sure that you're using the correct entry table
for your calculator.
I wouldn't recommend that anyone jump right into trying to learn SysRPL
without first learning UserRPL, at least enough to feel reasonably
comfortable and confident programming in UserRPL.