Can we have RPN back?
|
01-28-2014, 06:14 AM
Post: #21
|
|||
|
|||
RE: Can we have RPN back?
(01-27-2014 07:56 AM)Joe Horn Wrote: Therefore, one solution to the problem you mention is to just allow expressions to be as big as users need, knowing that they will keep them limited to real-world reasonable sizes, and clear them out between sets of problems.I was actually looking at an empty stack when switching on my 48G last night. Cleaning up the workbench seems to be not unusual ;-). |
|||
02-04-2014, 11:28 PM
Post: #22
|
|||
|
|||
RE: Can we have RPN back?
(01-27-2014 03:45 PM)Tim Wessman Wrote: I assume he is talking about this thread in comp.sys.hp48 (or one of 3-4 others) mmm I really don't see the issue here... Alphabetically, "x" comes before "y" (or at least it did last time I looked...) The first number entered is therefore "x" and the second is "y" therefore "x^y" seems perfectly logical to me... Even the HP35 has an "x^y" key and somehow over the last 40 odd years of HP use, I don't recall any instances of confusion! (In fact, I had to re-read these posts to even see "y^x"...) This whole "issue" seems to be rather silly... Rob |
|||
02-05-2014, 06:28 AM
Post: #23
|
|||
|
|||
RE: Can we have RPN back? | |||
02-05-2014, 10:01 PM
(This post was last modified: 02-05-2014 10:40 PM by Joe Horn.)
Post: #24
|
|||
|
|||
RE: Can we have RPN back?
(02-04-2014 11:28 PM)rlinden12 Wrote: mmm I really don't see the issue here... Alphabetically, "x" comes before "y" (or at least it did last time I looked...) The first number entered is therefore "x" and the second is "y" therefore "x^y" seems perfectly logical to me... The "issue" is that all the old HP 4-stack-level RPN calculators had a good reason for not doing it that way. When two values were entered, the first one was called Y and the second one was called X, because those were the names of the stack levels where they wound up. That's why some of us HP calculator old-timers find it hard to retrain our brains to stop referring to the bottom level of the stack as "X". Not all, but most of the folks here, are HP calculator old-timers, because this is a museum for old HP calculators, and old habits die hard. But don't worry...we're not too old to learn new tricks. <0|ɸ|0> -Joe- |
|||
02-06-2014, 12:31 AM
Post: #25
|
|||
|
|||
RE: Can we have RPN back?
My HP-48SX, my HP-48S,my HP48G, my other HP48G my HP32Sii, my HP15CLE, and my other HP15CLE all have keys that mean things and serve as an indicator as to which numbers are about to be used for calculation. This was all based on the really simple context of knowing that the first two registers in the stack were thought of as X and Y. Some have a four place stack and some have a limitless stack.
On these older models some have one function key that refers to X and y, and some have two. To those with my experience, on the Prime, we just have to remember that the two 2-argument keys are labeled backwards and all will be well. Which is a really good reason to not use it as a replacement for your favorite old engineering calculator since these keys don't work in the expected way...expected based on 30 years of use of "old" Hp's. I read what's on the keys, and enter data accordingly after automatically assigning X and Y to the first two registers...meaning I'll make mistakes trusting the Prime. Which is why I asked for a "legacy" RPN mode that would reverse the action of the two keys on the Prime for legacy RPN only. What I would like to find is that I could do this myself, so that if I enter the RPN mode the Prime offers now, it would automatically reverse the action of the keys. I don't see how to do it. The User Keyboard seems possible, but I'd prefer to redo the keys only in RPN mode. As for the gentleman who calls all this silly, I disagree. It's a small issue, but it's not silly. It's a 30 year habit for some of us. |
|||
02-06-2014, 01:40 AM
Post: #26
|
|||
|
|||
RE: Can we have RPN back?
I agree with Craig. It's a small issue, but it's not silly. It's a 30+ year habit for some of us.
In any event, regardless of how the key is labeled, at least it WORKS the same in RPN mode on the Prime as on any other HP calculator (other than the HP 35). I didn't realize the HP 35 was different in this respect. Oddly enough, although it is an algebraic calculator, my Sharp EL-W535X has its equivalent key labeled "y^x" like almost all HP models. |
|||
02-06-2014, 10:18 AM
Post: #27
|
|||
|
|||
RE: Can we have RPN back?
Shouldn't it be very easy to assign an user command to the offending keys, so that they are preceded by a swap? See this link here:
User keys That way, as long as the keyboard is in user mode, everyone should be happy... |
|||
02-09-2014, 02:50 PM
Post: #28
|
|||
|
|||
RE: Can we have RPN back?
(01-26-2014 08:57 PM)Han Wrote: RPN made sense only on hardware that was limited in resources. RPL makes more sense on a system with a larger display and much more memory. And as technology improves, RPL will be much more robust while RPN feels extremely limited.This view is a little inconsistent with the way HP has always (to my knowledge) documented their calculators. I don't believe that RPL has ever referred to the (admittedly) subtlely different RPN supported by calculators that support the RPL programming language. Quoting from the HP 49g+ Manual (my HP28 manual is at home, but I believe it says something similar): Quote:The hp 49g+ can be operated in two different calculating modes, the Reverse Polish Notation (RPN) mode and the Algebraic (ALG) mode (see page 1-11 in user’s guide for additional details).- John |
|||
02-09-2014, 11:43 PM
Post: #29
|
|||
|
|||
RE: Can we have RPN back?
I also cannot find a reference to RPL in the HP-28 and HP-48 series manuals, only RPN.
For reference; From the HP-28C Getting Started Manual, Chapter 1: "The style of calculation illustrated above, in which you enter numbers onto the stack before you perform mathematical operations, is called RPN (Reverse Polish Notation) or stack logic. The inputs required by a command, called its arguments, must be on the stack before the command is executed." From the HP-28C Getting Started Manual, Chapter 2: "There are two ways to do arithmetic on the HP-28C. You can do arithmetic using the stack, as you did in the previous chapter, or you can enter an expression representing the calculation." |
|||
02-10-2014, 01:53 AM
(This post was last modified: 02-10-2014 02:41 AM by Han.)
Post: #30
|
|||
|
|||
RE: Can we have RPN back?
They're all RPN, yes. But they can be distinguished by their programming "language."
Many of the calculators that have "immediate entry" (what a lot of folks call RPN -- see HP48 manual; I could not find a reference to RPN) rely on an RPL engine. I was specifically referring to the programming method. The older calculators had pgramming-by-keystroke only (what I am calling RPN machines) while the later models allowed the use of UserRPL (what I am calling RPL machines). They all, however, were running off of an RPL-based engine (running SysRPL, but only the later graphical models actually allowed users to type in commands as opposed to using keystrokes). The "RPN" calculators were limited to keystrokes and 4-level stacks. The "RPL" machines had a stack limited only by memory, and could be programed using RPL commands. The "RPL" machines no longer behaved like the "RPN" machines even at the keystroke level. DUP-on-ENTER was omitted; Stack Level X -- the equivalent of Stack Level 1, was no longer tied to the input/command line. However, there were still a number of similarities. That you may have never heard about the underlying layer is nothing out of the ordinary. It was never a regular term like RPN -- unless you did a lot of RPL programming. From the HP48 FAQ: Quote: RPL Even the HP42S has an RPL engine even though none of it was immediately available to the user. A quick disassembly will reveal a rudimentary version of RPL. I have not disassembled ALL Saturn-based calculators, but it would not surprise me the least if they all had some early form of RPL as the interface between user keystrokes and assembly code. Graph 3D | QPI | SolveSys |
|||
02-10-2014, 04:26 PM
(This post was last modified: 02-10-2014 04:31 PM by John R. Graham.)
Post: #31
|
|||
|
|||
RE: Can we have RPN back?
I think we mostly agree. But I think it's confusing to say RPL vs. RPN: it's apples vs. oranges. RPL has never been a term that described the data entry mode. If it doesn't start with « then it isn't (User) RPL.
- John |
|||
02-10-2014, 08:00 PM
(This post was last modified: 02-10-2014 08:29 PM by Han.)
Post: #32
|
|||
|
|||
RE: Can we have RPN back?
(02-10-2014 04:26 PM)John R. Graham Wrote: I think we mostly agree. But I think it's confusing to say RPL vs. RPN: it's apples vs. oranges. RPL has never been a term that described the data entry mode. If it doesn't start with « then it isn't (User) RPL. It's not apples and oranges -- if anything, it's a Washington apple vs a Granny Smith apple :-). I agree that RPL is not _commonly_ used to refer to data entry -- but only because RPL was never really used as a common term, period. Again, to quote Wickes: RPL was never particularly intended to be a public term. Here's a link showing Richard Nelson referring to RPL as if it were a new method of entry (first sentence). He later calls it "Entry RPN" http://h20331.www2.hp.com/hpsub/download...%20V5b.pdf From our very own museum, an article about the "versions" of RPN. http://www.hpmuseum.org/rpnvers.htm As for why I personally refer to them as RPL vs RPN, it's actually related to your comment about « and UserRPL. The suggestion that « is required in order to be called (User)RPL is incorrect. If you take an HP48 and press [RightShift] [Alpha] followed by 3 [SPC] 2 + 9 / -- that's RPL input. It's a program without the « delimiter -- all sitting in the command line waiting for you to press ENTER before executing. You can certainly do more complex "programs" than this. In fact, the command line itself is a program editor. The evolution from RPN to RPL was such that the command line was previously limited to a single entry (either a number or a single command via a key-press) in the "RPN" machines can now handle a full-blown program in the "RPL" machines. This had mainly to do with the fact that the "command line" was also the first level of the stack on the RPN machines. Granted, most users still only used RPL machines like they did RPN machines. That is, they would press 3 ENTER 2 + 9 / to get the same result. But that is very different from typing 3 2 + 9 / (also using only keystrokes) in the command line. But yes, I think we mostly agree. Graph 3D | QPI | SolveSys |
|||
02-10-2014, 08:47 PM
Post: #33
|
|||
|
|||
RE: Can we have RPN back?
Thanks. I think I stand (mostly) corrected.
- John |
|||
02-10-2014, 08:58 PM
Post: #34
|
|||
|
|||
RE: Can we have RPN back?
Thanks for all of the links and background information, Han. I had read the HP-28 and HP-48 "Insights" books and the forums over the years but had forgotten that "RPL" was not an official term used by HP in their manuals. I have been using "Entry RPN" and calling it RPL for so long (since 1988) that I had just fixed in my mind that HP called it RPL too. Searching through the HP-28 and HP-48 manuals again showed my assumption was wrong.
|
|||
02-10-2014, 09:51 PM
(This post was last modified: 02-10-2014 10:00 PM by John R. Graham.)
Post: #35
|
|||
|
|||
RE: Can we have RPN back?
(02-10-2014 08:58 PM)Steve Simpkin Wrote: ... forgotten that "RPL" was not an official term used by HP in their manuals.That stance seem to have changed at some point because the HP50g / HP49g+ / 48gII Advanced User's Reference Manual has a chapter entitled RPL Programming and later RPL Programming Examples. Although, to Han's point, even there the term isn't expanded on, just used as a chapter heading. The HP 49g+ User's Guide expands, calling User RPL, "the original programming language of the HP 28/48 calculators," so there are a few official uses of the term. - John |
|||
02-10-2014, 10:00 PM
(This post was last modified: 02-10-2014 10:02 PM by Tim Wessman.)
Post: #36
|
|||
|
|||
RE: Can we have RPN back?
Well, those documents were made primarily by longtime HP users rather then internal HP employees. Wouldn't surprise me if that is the root cause of the change.
TW Although I work for HP, the views and opinions I post here are my own. |
|||
02-10-2014, 10:14 PM
Post: #37
|
|||
|
|||
RE: Can we have RPN back?
That's interesting. The official HP 48gII / 49g+ / 50g user's guides and advanced reference documents were not authored by HP employees?
- John |
|||
02-10-2014, 10:23 PM
(This post was last modified: 02-10-2014 10:30 PM by Tim Wessman.)
Post: #38
|
|||
|
|||
RE: Can we have RPN back?
(02-10-2014 10:14 PM)John R. Graham Wrote: That's interesting. The official HP 48gII / 49g+ / 50g user's guides and advanced reference documents were not authored by HP employees? It was long before my time at HP, but Dr Urroz was contracted to make the user guides based on his books ( http://www.neng.usu.edu/cee/faculty/gurro/myBooks.htm ). That is why there are such similarities between them in so many parts. I believe a similar thing happened with the AUR. When you no longer have internal technical writers sitting next to the engineers building the products (which hasn't been that way since mid/early 90s I think), the common conventions used by customers will most likely end up creeping in and really wouldn't reflect internal policy shifts or anything like that. As far as I can tell, HP internally has considered anything to have "backwards" input as RPN since forever and the only people making a huge fuss over it are end users wanting to distinguish between 4 level, 4 level with command line, RPL, etc. TW Although I work for HP, the views and opinions I post here are my own. |
|||
02-11-2014, 10:53 PM
(This post was last modified: 02-11-2014 11:12 PM by John R. Graham.)
Post: #39
|
|||
|
|||
RE: Can we have RPN back?
Thanks for taking the time to explain. The first HP calculator I laid my fingers on was one of the 9100 series (3-level stack; it was my father's and I must've been about 10). I've since used the 35, 67, 97, 41 series, and 48 – 50 series.
Although I definitely took advantage of the shortcuts that automatic stack lift enabled (e.g., "number [ENTER] [x]" for \(x^2\)), I think the version of RPN as exemplified by the 28 – 50 series is definitely my favorite. (Han has convinced me that this should be called Entry RPN.) I've certainly been using it the longest. - John |
|||
03-27-2014, 02:31 PM
Post: #40
|
|||
|
|||
RE: Can we have RPN back?
(01-26-2014 07:47 PM)Tim Wessman Wrote: 1. How would a command line be treated since you can have multiple things together at a time (vs a single numerical only item)? If you are replacing the item in level 1 as you write it.... I'm a bit late to the party, but... The answer to all of these is simple - it *should* behave like it has since hp48. Namely - like RPL. 1. Entering << 1 1 + >> in a command line should yield 2. Entering 1 1 + should result in an error. Entering '1+1' should result in 2. 2. But there is a stack. There is *always* a stack, that's the whole point of RPN and RPL. You might not *see* the stack, but commands are always pushed on a stack and popped off it when executed - entering << 2 pi * sin >> should push 2 and pi on the stack *internally* then perform multiplication on levels 1 and 2, then perform sine on level 1. 3. See 1. Single quotes. 4. I don't understand the question. Like it always has. Objects are tokenized and recognized as such based on certain delimiters (various brackets) and then pushed on the stack. Like they always were |
|||
« Next Oldest | Next Newest »
|
User(s) browsing this thread: 2 Guest(s)