HP Forum Archive 08

[ Return to Index | Top of Index ]

HP48 RPL HELP. . . Message #1 Posted by Tal on 11 Aug 2002, 1:29 a.m. 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

Re: HP48 RPL HELP. . . Message #2 Posted by Vieira, Luiz C. (Brazil) on 11 Aug 2002, 11:38 a.m., in response to message #1 by Tal 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.

Re: HP48 RPL HELP. . . Message #3 Posted by James M. Prange on 11 Aug 2002, 2:55 p.m., in response to message #2 by Vieira, Luiz C. (Brazil) 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

Re: HP48 RPL HELP. . . Message #4 Posted by Vieira, Luiz C. (Brazil) on 11 Aug 2002, 7:14 p.m., in response to message #3 by James M. Prange 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.

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) 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

Re: HP48 RPL HELP. . . Message #6 Posted by Vieira, Luiz C. (Brazil) on 12 Aug 2002, 12:39 a.m., in response to message #5 by James M. Prange 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!

Re: HP48 RPL HELP. . . Message #7 Posted by James M. Prange on 12 Aug 2002, 4:06 a.m., in response to message #6 by Vieira, Luiz C. (Brazil) 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

[ Return to Index | Top of Index ]

Go back to the main exhibit hall