HP48 RPL HELP. . .

[tal]

Hi, All!

I have a program that gives at the end a "GROB".

This "GROB" displayed on the screen and saved in
"XXX" variable(for other time display).

I used a temporary ("TEMP") variable.

I am wondering if it is must using this temperary
variable:
.
.
. @ here is the GROB
'TEMP' STO
\<< TEMP \->LCD 3 FREEZE \>> 'XXX' STO
XXX
\>>

Best regards,
Tal

[Vieira, Luiz C. (Brazil)]

Hello, Tal

Let me see if I get it: your program lists like this (as is in your post):

GROB 'TEMP' STO

<< TEMP 

->LCD

3 FREEZE

>>

'XXX' STO

XXX 

>>

The last >> seems to have no counterpart. Is there something else in your program?

When the calcualtor finds GROB in a program, it places GROB in stack level-1. GROB is a special name, and sometimes I feel confused about how to use it. What did you expect being stored at 'XXX' at the end of the procedure?

If you want to send me the program listing, be my guest.

Best regards.

[James M. Prange (Michigan)]

Hi Vieira,

"GROB" is RPL jargon for "GRaphics OBject". Presumably, an earlier part of the same program left the GROB in level 1.

Tal,

Just let the program that makes the GROB end with the GROB on level 1. Now start writing the 'XXX' program in the command line, but instead of using the variable TEMP as the first object, press LeftShift EDIT, then the \|^STK menu key to get into the "interactive stack", and with the arrow on level 1, press ECHO to get a copy of the GROB itself into your command line, and then press CANCEL (or ATTN on the 48S series) to get out of the interactive stack.

My explanation sounds a bit complicated, but once you learn the technique, it's really very easy.

Regards,

James

[Vieira, Luiz C. (Brazil)]

Hi, James. Thanks for the information.

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 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 best solution.

What I did not understand is the fact that the default condition is overwriting existing variables. 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? I did not get into SysRPL so far (I do not have a complete documentation; any suggestion?), but knowing about it would be great!

Best regards.

[James M. Prange (Michigan)]

Hi Luiz,

First, my apologies for my gaffe of using your surname in my previous
post.

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
best solution.

I think that it was indeed incomplete, and he was indeed making the
'XXX' variable within a larger program, with the beginning "to be
understood".

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
existing variable.

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://membres.lycos.fr/ekalin/, maybe
http://www.engr.uvic.ca/~aschoorl/, or
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.

Regards,

James

[Vieira, Luiz C. (Brazil)]

Hello, James;

first of all, I was not even known it is a gaffe when one uses the surname to refer to someone else's name. In Brazil we normally use both in the same way; sometimes, the surname comes after a Mr. (or Ms.), but it is not unpolite omitting the Mr. I feel glad for your apologies, and I would accept them as well, but... we're home, my friend (may I?). I was not aware of it.

Well, what to say! Thank you very much for the explanation. The HP48 is really a box of surprises. I have both HP48 Insights, and it is a very good, easy reading (thanks to Bill Wickes), but I did not find the time reading them till the last page. And they are not the kind of books to read in a flash: they MUST be taken word by word, slowly, digesting... We're lucky they were very, very well written.

I bought my HP28S when I was in still an engineer student. It took me so many days reading (and understanding) its manuals that I thought nothing else would be hidden inside it. I was known about Synthetic Programming on the HP41 (Wickes strikes again...) and I could read it only after buying the HP28S. Some years later, I could get my HP48SX and then I thought a lot more would be hidden in there.

I have some stuff about SysRPL, but it demands time, time, and more time to devote and experiment. I'm about to find some for now, but I believe most of the hidden secrets are already known by many users. I think I can take a ride and save time to be spent in development. Do you agree?

I am a lot curious about many HP48 related things. I'll search for info following the addresses you posted here.

Again, my pleasure reading your post.

Thank you a lot!

[James M. Prange (Michigan)]

Hi Luiz,

Customs vary with time, place, and circumstance. When I was a child,
adults (at least in this neighborhood) were addressed (by both children
and other adults) as Mr., Mrs., or Miss plus their surname, with the
exception of family and those who were childhood companions (even then,
on "business" matters, the formal Mr., Mrs., or Miss and surname was
used). These days, Mr., Mrs., Miss, or Ms. and surname would seem too
formal for most situations; we use the informal first name in most
cases. In some cases the surname alone may be used in an informal
manner, particularly when that distinguishes which person is meant when
the first name could refer to more than one person, but more often it
would be considered somewhat rude.

And yes, I would be honoured to be considered your friend.

Bill Wickes's books are indeed very well written, I'm glad that you have
them. Perhaps others will also benefit from the excerpts that I quoted.
Except for things that are obviously new with the 49G and SysRPL
matters, or when I know exactly where else to find the answer, the
"Insights" books are still the first place that I look when I have a
question about these calculators. But even in the "Insights" books, I
occasionally find an error; if you really want to know for sure, there's
nothing quite as good as experimenting.

These calculators still have some surprises, at least for me. I don't
think that the documentation was ever really complete, and the quality
and completeness of the documentation seems to go down with each new
model. It's as if they expect that the only ones who might read the
"Guides" (Whatever happened to "Manuals"?) are those who are already
familiar with the previous model and those who don't care to make the
effort to learn "in-depth" how the calculators work.

But there is indeed a wealth of information available; it's mostly a
matter of finding it and finding the time to study it, and it's
worthwhile looking into what others have already discovered, but do have
a bit of skepticism about anything that you read.

By the way, let's not overlook the Museum CDs as a source of information
on RPL.

As for learning SysRPL, it's something that I keep promising myself I'll
do someday. But experiment with it only when you have your calculator
backed up and a "Memory Clear" won't be too terribly inconvenient.
Mistakes that you'd discover by an error when working with UserRPL may
well be discovered by a TTRM when using SysRPL.

Note that backing up to a port is a lot faster than backing up to a PC,
and, especially if you write-protect the card (on a 48 series) or use
the flash memory (on a 49G), it's almost completely secure. But for
"worst-case" scenarios, I still recommend having a reasonably recent
back-up on another device, whether you're experimenting with the
"internal" languages or not.

Regards,

James