HP Forum Archive 12

[ Return to Index | Top of Index ]

Re: Newcomer has questions Message #1 Posted by James M. Prange on 11 Apr 2003, 12:47 a.m. Hi Ernie, you're missing my point. Maybe so. I do see your point that RPN and RPL are different, and I agree with that. But I think that RPL is easy to understand and well worth learning. "Classic RPN" has to run on hardware with relatively limited resources. The RPL calculators have, if I'm not mistaken, faster processors, and certainly more built-in memory (well, possibly excepting the 28C), so why shouldn't RPL take advantage of the improved hardware? Why, for example, would one want to restrict the stack to only four levels? Or to save only one last argument? I see RPL as an improved version of RPN. As I mentioned in an earlier post, I wrote the example programs off the top of my head without testing or optimization. Ok, it's a simple enough example that it doesn't really need any testing. Well, at least not the RPL program, which will obviously work; I'm not about to buy myself a 41 and learn to program it just to see if the 41 program works. But I glanced at your RPL example, and off the top of my head, I couldn't see any reason to go to the bother of using a local variable. Now that I've thought about it a bit, I see that using the local variable gives your version the advantage that it's a user defined function; that is, it can be used in an algebraic object. But about the only time that I use algebraic objects is when I'm copying a formula that's already been written down by someone else, and seldom even then. >why would you want fancy formatting when a program's on the stack? And that points to another design flaw. Programs are meant to be read by _people_, because they have to be understood by _people_ if they are to be modified, improved, or what-have-you. Removing the "fancy formatting" removes understandability and confuses the programmer. Good coding standards _require_ use of comments and indentation whenever possible. I think that you're missing *my* point here. My point is that if I wanted to peruse a program and perhaps edit it, I wouldn't be looking at it on the stack, but in the editor, where I could scroll through it and see the entire program, or I'd print it out, and with those methods it does have the indenting (although the indenting is what the decompiler applied; not necessarily what I would have used). Or better yet, if I wanted a really good look and I wrote it on the PC, I'd be looking at the source file, indented and commented as I saw fit (of course, that would require that I be at home so that I could use my PC). And yes, good programming practice requires the use of comments and indentation in the *source* code whenever possible. But for simple programs, someone familiar with the programming language can look at the code and see what it does even without indenting or comments. I do use indenting, and, when I write a program on the PC, some comments in the source code, but do you know of any compiler that retains the indenting and comments? Wouldn't that defeat much of the purpose of compiling? To be sure, there are languages that save the source code and interpret it at run time, but I have my doubts as to how feasible it would've been to use that method on a hand-held at the time that UserRPL was designed, or even now. >If I really wanted to keep the program from being compiled, I could embed it within a character string and even keep comments in it Come, now, who's making things more difficult than they have to be? 8^) Well, you complained that the RPL compiler discarded the programmer's formatting, so I demonstrated that you could make it retain the formatting if you really wanted to. I certainly don't recommend that anyone use that method; keeping the source code in its own file on the PC makes a lot more sense. >RPL is simple and straightforward. Debatable and subjective. It's equally possible to argue that RPL is complicated and convoluted. Certainly you can write complicated and convoluted programs in RPL if you choose to do so. I suppose that the same could be said of any language. How about the 41's version of RPN? Using GTOs, I suppose that you could make things *extremely* complicated and convoluted if you chose to do so. >As long as I use a variable name descriptive enough that I remember what the program was written for in the first place RPL variable names are, in practice, limited to 4 or 5 characters because more than that won't fit in a menu key label. Sometimes my HP-28C can't put more than 3 characters! One cannot be descriptive when limited to such short variable names. I should know -- I've been an RPG programmer for 20 years, and RPG II and RPG III program variables are limited to 6 characters. Yech! Haven't you ever noticed that in "PRG ENTRY" mode, pressing the menu key for a variable puts the whole name in the command line? There, if it's too long to fit in the 22 character standard display, you can scroll left or right to see the rest of it. The name can be up to 127 characters, which I suppose should allow one to be descriptive enough. The first few characters that you can see in a menu should be enough to give you a clue, and on any RPL calculator except the 28C, you can organize your variables into directories, which should give you more clues as to what a variable is for. >But I thought that the "RP" in both "RPN" and "RPL" stood for "Reverse Polish". Doesn't that mean arguments first, operator last? Notice how many of the arguments in your program come *after* the operators? Now that's what I call backwards. As mentioned above, programs are meant to be read by _people_. People use human speech (with a given language) to communicate ideas. When you say "store in register 01" you use a verb in the imperative tense ("store") and an object or "parameter" ("in register 01"). That's the _natural_ way to speak. Natural in English, which most often uses a "Subject Verb Object" word order, but perhaps not for various other languages. But doesn't "1 plus 2" sound more natural than RPN's "1 2 plus" to our English accustomed ears? Yet we (the folks on this forum, that is) prefer to use RPN. Like Yoda of the "Star Wars" saga, you can say "In register 01 store," but taking this backwardness as far as that doesn't clarify a program in the least. I wonder which word order he uses in foreign language versions of those movies. For that reason, I feel that RPL is more backwards than RPN. IMHO, HP took Lukasiewicz's invention just too far. But suppose that the "objects" for "verbs" such as STO, RCL, FOR, or flag commands are already on the stack, as a result of a previous operation? If I have to put the "objects" after the "verb", then I suppose that I'd have to push the "verb" onto the stack, and then rearrange the stack to get the "objects" to the bottom of the stack, or maybe write them down on a scratch pad and key them in again. That's the genius of the "Reverse Polish" way of doing things; it lets you easily use the results of previous operations. Why do things differently for certain commands just to conform to English language patterns? I'd rather that a programming language be self-consistent. Not that RPL is perfect of course. If it were up to me, then "IF" would be discarded as it's superfluous in RPL, and for some commands that require more than one argument, the order of the arguments seems "unnatural" to me. The REPL command comes to mind; I experimented the last time that I used it. Certainly I can imagine many additional commands that I'd like to have built-in, "Garbage collection" can take an awfully long time under certain conditions, and I could no doubt think of other things that I'd rather were different. But, as you yourself said, "stick with what you like." Certainly. I have RPL calculators and a 16C. In some ways I find the 16C inconsistent and rather limiting, but it's occasionally useful because, being a rather specialized calculator, it has some special capabilities that aren't built-in to the RPL models (though I suppose that I'd program them in myself if I used them very often). But having RPL models, I doubt that I'd ever really use other RPN models. What could I do on them easier than I could do it on an RPL model? Something that fits in a shirt pocket would be nice, but considering current prices, I'll put up with a Brand X algebraic input calculator when I want to compare prices in the grocery store. The RPN models are interesting and often admirable in design and quality, but for me, they'd end up being museum pieces, just left on a shelf or stored away somewhere. >And then add the lack of IR, crippled serial I/O, flakey keys, poor keyboard layout, lack of keyboard overlays, big ugly chunk of plastic over the display, hard to read lettering on the faceplate, numerous operating system bugs... You just gave a precise description of the HP-49G! 8^) Some steps forward, some steps back. The 49G is sometimes fun to play with, and has some new operations that are useful, but for "real work", I'll keep using the 48 series calculators. Regards, James

Re: Newcomer has questions Message #2 Posted by Ernie Malaga (Miami) on 11 Apr 2003, 8:45 a.m., in response to message #1 by James M. Prange James: Thank you for your detailed and most interesting reply. After reading it, all I can say is, "Let's agree to disagree." It's obvious that RPN and RPL require different mindsets from their users. And perhaps I'm too old (47) to make the transition without trouble. -Ernie

Re: Newcomer has questions Message #3 Posted by James M. Prange on 12 Apr 2003, 4:17 a.m., in response to message #2 by Ernie Malaga (Miami) Ernie, Ok, I was a mere youngster still in my thirties when I became acquainted with RPL. I've had the 16C for less than a year. I'm pretty confident doing things "manually" on it, and I've worked through the Owner's Handbook and written a few very simple programs. Interesting, and it has some things in common with RPL models, but I'm sure that if I felt any "real work" need for any but the most rudimentary program, even with binary, octal, decimal, or hexadecimal integers, then I'd write it for an RPL model, even though the RPL calculators lack many built-in features that the 16C has for working with these objects. I don't think that it's so much a matter of age. I expect that you could learn to be a proficient RPL programmer, and I could learn to be a proficient RPN programmer, but what's probably lacking for both of us is motivation. Regards, James

May I? Message #4 Posted by Vieira, Luiz C. (Brazil) on 12 Apr 2003, 7:55 p.m., in response to message #3 by James M. Prange Hello Ernie, James, folks; a few days ago I received an e-mail from one of our contributors (recently injured by a thief) mentioning he noticed I deal with RPN and RPL as well, as he does the same. I read the posts from both of you and I must tell you I sometimes choose RPN or RPL style programming after trying them both in the same problem. And I consider programming and using in a different way. Let me put it in a different perspective. When I want to deal with numbers only (most of the time) I take any RPN calculator in hand, but I prefer a Voyager. They have "almost" everything you need already printed in the keyboard. I used the word "almost" mostly because of the HP15C, that requires some background to use Numerical Integration and SOLVE. How to use them is the only information not printed on its back label. If there is no Voyager at hands, or if I need any sort of ALPHA manipulation, like labeled messages or interactive input, I go for a 41 or a 42. In their case, function names and menus will probably slow operation a bit down, but there is no problem. The major problem is related to large database manipulation (large for a handheld calculator). If I want to observe statistical data to determine a tendency and define parameters and curve fitting I'll use the HP42S mostly because it allows using lists (matrices) as input data, and editing a matrix in an HP42S is relatively easy. In other cases, using X-Functions (HP41) may also be of help, and dealing with ASCII files in an HP41CX (ED) is, at least, fun. I consider using an HP48 for simple daily computations as fast as using an HP42S IF you keep your eyes in stack contents. In fact, I see as a major concern the stack contents clearing from time to time if you allow previous results to remain there and selective, cautious use of the conceptually correct LAST ARG instead of the also conceptually correct LAST X. I am not sure about the other guys, but I care much about T-contents replication when programming. If I am using a four-level deep, stack-based calculator (RPN), manipulation of stack contents is sometimes as easy as pressing [Rv] (roll-down) four times to review its contents, and I do not remember storing ALPHA data in any stack register other than in program execution. But I must admit manipulating data by keystroke sequences available at the RPL-based calculators is harder. Simply rotating stack-"level" contents demand the number of levels to be rotated to be firstly input prior to execute "ROLL" or "ROLLD". A third "ROT" function allows a faster three-level rotation. Picking a copy of any available "level" contents is a matter of specifying it and executing "PICK". A lot more names to remember, I know, but that's a price I was willing to pay at the time I learnt RPL concepts. I consider writing programs a very different issue. Using voyagers, HP41 or HP42 is a matter of internal resources and programmers' needs. But using RPL-based calculators go beyond this. I "think I need" RPL-based calculators to develop bold, audacious programs that allow you to access external devices easily and delve into mass-storage extensive data to find patterns... O.K., O.K., I know you can do it with a palm and use another functional- or imperative-paradigm language at your request, but how much will it all cost? Four, five, eight times what you expend with an HP48G+, SW and RPL-compiler included. And I feel RPL-based calculators programming as a fast procedure. I know other contributors do not feel like this, but for me RPL brought many features I used to dream of: no specific "environment" for specific data like programs, registers and APLHA; ability of entering program instructions/functions in an existing program; easily generation (or ability to easily generate) user functions (not programs) as internal existing features; easy, standard way to communicate with external devices (not available with the HP28, only in the HP48/49); math/algebraic tools and extended data manipulation (matrices, complex numbers, etc.). What surprised me was the ability of handling symbolic expressions with differential (derivative) and integration (with polynomial equivalent) as well. And as mentioned in some press advertisement, the HP28S was "the first portable equipment to offer symbolic algebraic manipulation based on resident system features (ROM)", i.e., symbolic manipulations features were recorded in ROM and did not need to be loaded as part of RAM-based software. All of this amused me. I like RPL and RPN as well, no matter what. No preferences, just a matter of demanding needs and available resources. I think easiness of using this or that system/resources also depends on operator acquaintance with the resource itself. Some users learn particular aspects faster than others: some prefer graphics, others prefer numbers, others symbolic manipulation. But all of them must prefer a pocket-size portable device to accomplish this all. My thoughts, though.

Re: May I? Message #5 Posted by James M. Prange on 13 Apr 2003, 1:20 a.m., in response to message #4 by Vieira, Luiz C. (Brazil) (Regarding RPL) In fact, I see as a major concern the stack contents clearing from time to time if you allow previous results to remain there... At a first reading, I thought you meant that the stack contents were cleared without the user doing anything. They aren't, of course; objects are taken off the stack as operations use them as arguments. Of course, it's not a good idea to just leave objects on the stack indefinitely. If you want to save an object indefinitely, the stack isn't a good place to do so; it would be too easily lost. Store such objects in a global variable or in a port. Having more objects on the stack reduces the amount of memory available to work in and slows down garbage collection, and in the case of the 49G, seems to slow down everything. First, of course, don't put extra copies on the stack without any reason for doing so, and do some stack cleanup to get rid of things that you no longer want on the stack. I think that most users clear the stack either when finished with what they're doing, or before starting the next project. If you want to keep some objects on the stack, the "Interactive Stack" (VIEW up or down on a 28, CursorUp on a 48 or 49G, also HIST on a 49G) is perhaps the easiest way to "manually" clean up or rearrange the stack, especially when you're not sure about just what level objects are on. For someone who started with RPL, the RPN stack is a bit strange in that it can't really be "cleared" in the same sense that the RPL stack is; on my 16C, it seems that the closest I can come is having all four levels filled with zeros. So far as I've noticed, if I really wanted to set all levels to zeros, it's not a single operation (short of clearing *all* memory). LAST or LASTARG is perhaps most useful for error recovery, but can also (usually) be used for reusing the arguments in another operation. I am not sure about the other guys, but I care much about T-contents replication when programming. It is useful, but for an RPL user, it's a little disconcerting to find extra copies of an object. Regards, James

Re: May I? Message #6 Posted by Vieira, Luiz C. (Brazil) on 13 Apr 2003, 3:24 a.m., in response to message #5 by James M. Prange Thank you, James; you are right; I'd rather write: In fact, I see as a major concern the need of clearing stack contents from time to time if you allow previous results to remain there... Long text, other language... You wrote: For someone who started with RPL, the RPN stack is a bit strange in that it can't really be "cleared" in the same sense that the RPL stack is; on my 16C, it seems that the closest I can come is having all four levels filled with zeros. So far as I've noticed, if I really wanted to set all levels to zeros, it's not a single operation (short of clearing *all* memory). I agree with you. That's why I always call stack registers clearing in an RPN-based calculator and stack (actualy) clearing in an RPL-based calculator. And the HP16C is the only Voyager that does not have a "stack registers clearing" command (or function). All other Voyagers have their stack registers cleared when CLEAR[Sigma] (statistic registers) is performed. The term clearing is not well used in some RPN-related literature, mostly because I feel as register clearing and register contents clearing as different actions. I cannot understand a register clearing procedure... Is it a fact or a misunderstanding of mine? I sometimes feel myself a bit confused about some terminology and I sort of create my own set of words to define some actions in a "better" way. At least in Portuguese I'm successful. Thank you again. Best regards. Luiz C. Vieira - Brazil

Re: clearing registers Message #7 Posted by Ellis Easley on 14 Apr 2003, 8:00 a.m., in response to message #6 by Vieira, Luiz C. (Brazil) As HP points out in the manuals, clearing a register is just storing zero in it. It is insignificant if next you are going to store, or ENTER data into it, but does matter if you are going to use STO+ or other register arithmetic. I guess I am talking about register contents clearing. If the comparison is between RPN and RPL calculators, then clearing the RPL stack destroys the objects on the stack - essentially clearing both the registers and the contents - while clearing the RPN stack just stores zero in all the levels. Then you have the 17BII in RPN mode, where clearing the stack destroys all but the first level of the stack, and stores zero in it.

Good point, Ellis Message #8 Posted by Vieira, Luiz C. (Brazil) on 14 Apr 2003, 11:07 a.m., in response to message #7 by Ellis Easley Hello, Ellis; you are right about HP17BII/19BII RPN implementation: in this case, clearing the stack means destroying Y-, Z- and T- registers. And as you may have noticed, pressing ENTER with a zero in the X-register will bring them back... with zeroes stored on them! Fascinating... About RPL stack: as different objects have their memory requests, I believe HP28/48/49 design team decided to call stack "registers" as stack "levels", because the term register is so much associated with a group of seven bytes (HP calculators terminology except for the HP16C) that I believe it might confuse some users. Best regards. Luzi C. Vieira - Brazil

Re: May I? Message #9 Posted by R Lion on 13 Apr 2003, 3:04 a.m., in response to message #4 by Vieira, Luiz C. (Brazil) I like RPL and RPN as well, no matter what. No preferences, just a matter of demanding needs and available resources. I agree. So my time is shared between a 15C and a 48GX. And I love both! Raśl

[ Return to Index | Top of Index ]

Go back to the main exhibit hall