Post Reply 
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 ;-).
Find all posts by this user
Quote this message in a reply
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)

https://groups.google.com/forum/#!topic/...hD4M5M0wrU

If that doesn't show up for you for some reason, here are several relevant quotes by several people.

Quote:> It turns out (at least on this early emulator) that the x^y key actually executes y^x! So 3 ENTER 2 x^y yields 9 not 8. Is it just me, or does this seem illogical?

Just thinking out loud here...

You are making a false assumption, namely, that the first input is always called "Y", and the second input is always called "X". But that's not true in Prime, and in fact hasn't been true for a long time for most of HP's calculators. Stack levels are only named X, Y, Z and T in 4-level RPN, which all the old HP's had. But in RPL, since there are an indefinite number of stack levels, they are numbered, not named. And in algebraic logic, you can call anything whatever you want. For example, have you noticed the Nth root button? (Shift x^y). Not Xth root; Nth root. Why? Because that's what everybody else calls it, and that's how it's taught.

Therefore, calling the power key x^y, y^x, or just [^] (as some calculators do) makes no difference, since the name no longer represents the order of the inputs. You'll notice that almost all algebraic calculators out there call it x^y, not y^x, and nobody complains that they do it backwards. Even the entire HP 38/39/40 series has called it x^y since 1995.

Bottom line (formerly known as X): I'm rather sure that they chose x^y for Prime for the same reason that everybody else does: That's how it's taught. That's a powerfully compelling reason, when the calculator is primarily intended for education. On the other hand, there is no reason whatsoever to call it y^x, other than human inertia.

-Joe-

Quote:> It turns out (at least on this early emulator) that the x^y key actually executes y^x! So 3 ENTER 2 x^y yields 9 not 8. Is it just me, or does this seem illogical?

The x^y & y^x on old HP's was related to input order because they used a stack with registers called X, Y, etc.

The Prime is first an algebraic calculator. On all algebraics, it has been convention that x^y means (first number)^(second number), and logically x=first number & y=second number.

Even on the 50G, y^x doesn't make sense but was kept because "people were used to it", but its stack levels has numbers and not X, Y etc.

Note that the "first" forerunner of the 50G, the 28C, has the power operator simply as "^" (shifted function above the multiply key).

[BartdB]

Quote:Just to add on to what Joe said, I am the one ultimately responsible for the exact key text and positioning since I delivered the final artwork for the printing (Prime, 10bII+, 39gII, 30b).

That doesn't mean I am ultimately the decider on what all the keys do - that goes through many revisions based on feedback and adjustments as we develop a calculator and learn what should go where to best support its operation, but I *have* been the one with the most critical eye on things like consistent capitalization, fonts, x/y centering and so on.

I can't claim color choice though unfortunately... :-(

x^y was used in previous HP calculators as was said and doesn't have anything to do with the old XYZT stack. It is just a pure power operator. As has been discovered, it calculates just like on the 50g. True, it could have just been labeled ^ but personally I think that is kind of ugly and less clear to both the math experienced and the math inept.

One consideration that has not been discussed though is that y^x would not fit well on the key without messing up the vertical alignment. The 50g doesn't have "classic HP style" sloped fronts on the keys - nor does it try to fit everything onto the same key. With the sloped front key, you can't print over the boundary there for many reasons. The "tail" of the y would require either reducing the y height, shifting the whole assembly upwards, reducing the size or something like that in order to avoid encroaching into the sloped front of the key.


Summing up, the *only* group of people that have any confusion with x^y are those trying to bring the old 4 level stack naming forward when it hasn't been in use since the 28 series, and no new users (the primary target market for Prime) would benefit from y^x.

To be clear, the buttons function exactly like the 48 series did and no order of arguments has changed. I'm perfectly happy to discuss this again if desired and hope eventually this becomes the only or last issue of contention. :-)

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
Find all posts by this user
Quote this message in a reply
02-05-2014, 06:28 AM
Post: #23
RE: Can we have RPN back?
(02-04-2014 11:28 PM)rlinden12 Wrote:  Even the HP35 has an "x^y" key [...]
It actually works like this, unlike later models which consequently had the label renamed.
Find all posts by this user
Quote this message in a reply
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-
Visit this user's website Find all posts by this user
Quote this message in a reply
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.
Find all posts by this user
Quote this message in a reply
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.
Visit this user's website Find all posts by this user
Quote this message in a reply
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...
Find all posts by this user
Quote this message in a reply
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
Find all posts by this user
Quote this message in a reply
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."
Visit this user's website Find all posts by this user
Quote this message in a reply
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
RPL is the name of the language used to program the HP48 and
HP-28 series calculators. RPL stands for "Reverse Polish Lisp".
It's interesting to note that an HP Journal article incorrectly
described RPL as "ROM-based Procedural Language".

From Bill Wickes:

RPL stands for Reverse Polish Lisp. In the early days of RPL
development, we got tired of calling the unnamed system "the new
system," and one of the development team came up with "RPL,"
both as a play on "RPN" which has been the loved/hated hallmark
of HP calcs forever, and as an accurate indication of the
derivation of the language from Forth and Lisp.

RPL was never particularly intended to be a public term; at the
time of the HP Journal article (August 1987) on the HP 28C there
was an attempt to create a less whimsical name--hence "ROM-based
procedural language," which preserved the initials but had a
more dignified sound. The development team never calls it
anything but (the initials) RPL. You can choose either of the
two full-word versions that you prefer. Or how about 'Rich
People's Language?'

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
Find all posts by this user
Quote this message in a reply
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. Wink

- John
Find all posts by this user
Quote this message in a reply
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. Wink

- John

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
Find all posts by this user
Quote this message in a reply
02-10-2014, 08:47 PM
Post: #33
RE: Can we have RPN back?
Thanks. I think I stand (mostly) corrected.

- John
Find all posts by this user
Quote this message in a reply
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.
Visit this user's website Find all posts by this user
Quote this message in a reply
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
Find all posts by this user
Quote this message in a reply
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.
Find all posts by this user
Quote this message in a reply
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
Find all posts by this user
Quote this message in a reply
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.
Find all posts by this user
Quote this message in a reply
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
Find all posts by this user
Quote this message in a reply
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....
2. How would it behave in places like an input form or dialog where you have no stack?
3. How would algebraic objects be used?
4. How specifically would it work for all possible object types (numbers, complex, vector, matrix, list, string, algebraics,etc)?

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
Find all posts by this user
Quote this message in a reply
Post Reply 




User(s) browsing this thread: 4 Guest(s)