Can we have RPN back?

[Tugdual]

Coming from the HP15C, i Just can't use that HP Prime version of RPN (not mentionning all the compatibility issues, just basic talking about calculations).

Before we had X,Y,Z,T registers and X was the screen. Now it looks like Row 1 became X and there is an undetermined use of the input row that would often requires ENTER to push it into R1 so that something happens. Still, sometime, the Prime assumes that the input screen can be used...

As a result "2 ENTER 3 +" produces the same result as "2 ENTER 3 ENTER +"
But don't assume that the screen is X because you'll have other blockers rapidly. This is just confusing.

I recently found the "swap" key which emulates the X<>Y key on HP 15C. For those who like me missed it, on the prime it is the tiny cryptic symbol next to the comma ','.
Do 2 ENTER 3 ENTER and SWAP would indeed swap R1 and R2
Now do 2 ENTER 3 SWAP and you end up iwth "3," on the input row whyle R1 remains 2.
Then you have no option but delete the mess manually.

Same if you enter : Shit ESC (clear) 5 *
It tells you that the number of arguments is incorrect. On the 15C you would never get such error because the registers are rotating and never empty; this being said, I accept it may not be the expected result providing you may not know what Y was... Now back on prime, the Input row now says "5 *". Great. Why do I need to see a '*' on the input row? Again I have to clear it manually now.

The beauty of RPN is that it is an extension of the mind, think about the calculation and the calculator takes care of the maths details. With this Prime version, I have lost all the benefit of RPN and find myself switching back to the book entry and just typing things as they come. So what is the message? Is RPN dead? Do we have a fake RPN implementation to please grumpy old gits? This is supposed to be a calculator, not a pocket computer, doing quick and dirty calculations is a must otherwise I just use Excel.

What I would like to see is the restoration of something closer to X,Y,Z,T. It was proven that the human brain cannot be conscious of more than a very limited number of things (like less than 5) at the same time. No need for infinite number of registers, this is just plain useless. I would like to see the real mechanism back that allows you to roll UP and DOWN the stack with all the copy mechanism (very Sadly the R^ or Rv keys are missing but well, we do have a touch screen for a mitigation, don't we? We could have buttons or use the finger to drag the stack up and/or down, just being creative, not sure that would be super efficient). Swap shall swap X<->Y like it did before. This doesn't seem too difficult to emulate, is it?
In the meantime, chances are that the Prime will take the dust while my new 15C LE will remain active.

Edit: just found the "Legacy RPN" idea here http://www.hpmuseum.org/forum/thread-173...hlight=RPN.
I think that is a pretty good one though I remain convinced that the non legacy is actually useless...

[Cristian Arezzini]

Haha, to each his own I suppose.
I totally agree with you about the SWAP issue - SWAP should be immediate without requiring an ENTER.
But concerning RPN, I find this way (as it is on the Prime, 48/50, and to a lesser extent the 30b) much (*much*) more natural. Classic RPN is exactly the reason why I ultimately stopped using the WP34s and 15c as day-to-day calculators, replacing them with the 50g first and the Prime later. I find *that* really confusing and inconsistent, at least with my particular needs at work. And I'm oh-so-glad that HP chose to keep it like this on the Prime!

I wouldn't object to having "Classic RPN" as an option, but if it was the only RPN option, I'd probably have to switch to Algebraic, at least at work.

Cristian

[Thomas Radtke]

Stack lift on swap *does* work on e.g. the 48G, so I consider this to be a bug in the Prime, not its intended behaviour.

[Tugdual]

I don't own the 48 so I played with the Droid48sx Emulator.
- when you enter 5 * on the 48 it pushes 5 into R1 and then cleans up the entry line while on the Prime you're left with "5 *" to clean up manually. Also you will notice that after having cleaned the entry row, the "Backspace" key doesn't cleanup the 5 value in R1. The 48 does.
- The Swap key does work on the 48 and would treat the entry line the same as if you had pressed ENTER before (i.e. it pushes entry into R1 then SWAP)

I quite like the 48 which I found more natural. In a sense R1 and entry line are equivalent on the 48, which at the end of the day is equivalent to the 15C since X is the screen, which is equivalent to R1 and entry line are the same.

Problem is that the Prime doesn't behave the same as the 48. Also with infinite stack, I understand that the register rotation keys disappeared; question is what was the use of those keys? I guess to check values in the registry most of the time which is no longer necessary with large screens.

So I would be find with the same RPN behavior as 48 (and 15C) on the prime.

[Cristian Arezzini]

(01-26-2014 05:42 PM)Thomas Radtke Wrote:  Stack lift on swap *does* work on e.g. the 48G, so I consider this to be a bug in the Prime, not its intended behaviour.

I think what's happening is that the swap key is "seen" as a SWAP only if there isn't any active editing going on, otherwise it's interpreted simply as the "default" comma key.
I'm wondering, is the comma ever needed in immediate calculations? I.e. if a future firmware will make SWAP act immediately even while editing, will this break something?

[Craig Thomas]

Original poster, you aren't the only one who feels this way.

For whatever reason, it doesn't look like HP is receptive to this though.

Hope I'm incorrect.

[Cristian Arezzini]

(01-26-2014 06:23 PM)Craig Thomas Wrote:  For whatever reason, it doesn't look like HP is receptive to this though.

It would be interesting to know, outside of this forum (which admittedly is a "museum", with its users focused mainly on older technology) how many people prefer the "older-style" RPN versus the new. We both are definitely dwarfed by Algebraic people, but still, it would be interesting.

[Tugdual]

Christian, the 15c and 48 are not fundamentally different apart from the stack size.
I think the problem is circumvented to a Prime issue.

[Cristian Arezzini]

(01-26-2014 07:02 PM)Tugdual Wrote:  Christian, the 15c and 48 are not fundamentally different apart from the stack size.

Well, there is the one single item that makes classic RPN awkward to me: the "Dup on ENTER".
With the workflow I have at work, sometimes I find X duplicated into Y without wanting it, and since there's a single line display, not only I have to drop X: I also have to *know* that I have to drop X, otherwise my calculation gets all wrong... I got used to pushing "swap" all the time just to check if X had been duplicated. :/
The 48, 50, and 30B don't have it, and so are much more usable to me (even the 30b which doesn't have the infinite stack).
And speaking of stack, always due to my work, 4 levels aren't enough. I don't need an infinite number, 6 would do. That's why for a while the wp34s was my main calculator!

Cristian

[Tim Wessman]

(01-26-2014 05:42 PM)Thomas Radtke Wrote:  Stack lift on swap *does* work on e.g. the 48G, so I consider this to be a bug in the Prime, not its intended behaviour.

It doesn't on the 49 and later where it is mapped to the right arrow.

Quote:I'm wondering, is the comma ever needed in immediate calculations? I.e. if a future firmware will make SWAP act immediately even while editing, will this break something?

Separation of items in a list, matrix, and complex (a,b) form are some that immediately jump to mind. Adding rows to matrices in 2d input, new lines in piecewise, etc.

[Tim Wessman]

So before I'd ever start working on a "classic RPN", I'd need to get answers that completely satisfy the questions about how it would work. These questions seem to center around.

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


As far as I can tell, 4 level RPN with DUP on enter went away as soon as you started being able to get a large number of different inputs/objects in use and places where input might be needed.

I am not against it (definitely lower priority in my mind then getting RPN working to the point I'd like consistently everywhere for example), but I don't know if there are any consistent clean answers that would allow it in a more capable/complex system. Please correct me if I'm wrong.

[Han]

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. While complex operations can be carried out with 4 levels of stack, why would you want to limit yourself to only 4 levels? In really complicated formulas, I would rather just do my computations and use however many levels I needed and not have to spend any time thinking about which innermost calculation has to be performed first so that I don't lose data due to a limited stack.

DUP on ENTER, while it may be useful, makes very little sense if you think of the X register as an actual stack level. Instead, the X register is essentially shared with the command line -- so that you really only have 3 true levels. This is really the only way to explain the DUP on ENTER effect -- that the X register and the command line are one and the same, and that ENTER was really just DUP. In RPL, the command line is separate from the stack.

Quote:

Quote:Stack lift on swap *does* work on e.g. the 48G, so I consider this to be a bug in the Prime, not its intended behaviour.

It doesn't on the 49 and later where it is mapped to the right arrow.

SWAP was mapped to the right arrow on the HP48 as well. In order to actually swap the current contents of the command line with level 1 of the stack, you actually had to execute the SWAP command by pressing [LeftShift][RightArrow] on the HP48. On the other hand, you could not do a swap by pressing the [RightArrow] (no shift) because this was a keyboard shortcut (as opposed to executing the SWAP command) unless the command line was cleared. The behavior of the [,] key on the HP Prime mimics the [RightArrow] key back on the HP48 (and later) models. The HP49 and HP50G no longer had a separate SWAP command shortcut like the HP48 -- all they had was the keyboard shortcut limited to [RightArrow] key.

Also, on the HP48 series, the command line was parsed and executed any time the user presses a key sequence corresponding to an RPL command. Thus, 2 3 + would automatically end the command line input after +. This is why 2 ENTER 3 + and 2 ENTER 3 ENTER + work the same way. Likewise, 2 3 [LeftShift][RightArrow] produces the same result as 3 ENTER 2 ENTER.

[Craig Thomas]

The reason I'm not using my Prime as an engineering calculator is simple.

x to the y key

and

nth root of x key

Currently, in Prime RPN, these require entry backwards compared to my other 5 HP calculators and it's way too easy for me to make errors because of this. I'm happy to clarify this if anyone want's it.

The transition between all my older HP's and the HP48 (my last new HP) was seamless for me so I'm perfectly happy with a limitless stack and I rarely program; I'm not sure why talking about RPN is tied to a 4 level stack only, in comments here, and is suggested as a reason to not 'do' RPN in a 'classic' way.

Perhaps I'll trip over other inconsistencies but having set my Prime aside for now, I'm not finding them.

Anybody who has an 'old' HP (up to the HP48 series) would be pleased to consider the Prime as an update except for the error generating keys I mention above...and the keyboard colors.

This might make it clearer:

If I could buy an HP-21 with a backlit screen and lithium ion battery, I'd buy 4...up to $75 apiece or so.

[Mark Hardman]

(01-26-2014 11:53 PM)Craig Thomas Wrote:  The reason I'm not using my Prime as an engineering calculator is simple.

x to the y key

and

nth root of x key

Currently, in Prime RPN, these require entry backwards compared to my other 5 HP calculators

Ummm...

No it doesn't.

2 Enter 10 x^y

Gives a result of 1024 and not 100 as you claim it would.

Tim has eloquently defended the labeling (mis-labeling?) of these functions in previous posts.

Mark Hardman

[Joe Horn]

(01-26-2014 06:27 PM)Cristian Arezzini Wrote:  It would be interesting to know, outside of this forum (which admittedly is a "museum", with its users focused mainly on older technology) how many people prefer the "older-style" RPN versus the new.

Here's a sobering thought. Infinite-stack command-line RPN was introduced in 1987. That's 27 years ago, almost twice as long as the period when only 4-level X-entry RPN reigned supreme in handheld calculators. How old can something get and still be called new?

I vote for NEITHER old-style or new-style RPN. I want a brand-new HYBRID entry method which uses RPN logic for input, has an infinite stack (why limit yourself when it isn't necessary to do so?), and displays all the intermediate results like RPN does, but also accumulates each operation into an algebraic expression and shows that too. In other words, RPN input with algebraic history on an infinite stack. That would be perfect for teaching RPN to kids, since they could see the entire history of what they've done in a single glance. It would be good for us too, since you'd have instant verifiability of what you did, unlike current RPN in which you just have to blindly hope you didn't press any wrong keys along the way... or use a printer in "trace mode", which is expensive, slow, and nowhere near as readable as a single algebraic representation would be.

That's my dream.

[Thomas Radtke]

(01-27-2014 03:58 AM)Joe Horn Wrote:  [...]also accumulates each operation into an algebraic expression and shows that too.

Nice idea. If I'm not missing something, there's one inconvenience: The calculator will never know when an expression is 'finished'. You'd either have to clear the accumulator by hand or have a stack of expressions, which grows faster than the RPN stack.

[Craig Thomas]

(01-27-2014 01:03 AM)Mark Hardman Wrote:  

(01-26-2014 11:53 PM)Craig Thomas Wrote:  The reason I'm not using my Prime as an engineering calculator is simple.

x to the y key

and

nth root of x key

Currently, in Prime RPN, these require entry backwards compared to my other 5 HP calculators

Ummm...

No it doesn't.

2 Enter 10 x^y

Gives a result of 1024 and not 100 as you claim it would.

Tim has eloquently defended the labeling (mis-labeling?) of these functions in previous posts.

Mark Hardman

Laughing.....what?

I hope you're joking.

[Joe Horn]

(01-27-2014 06:32 AM)Thomas Radtke Wrote:  

(01-27-2014 03:58 AM)Joe Horn Wrote:  [...]also accumulates each operation into an algebraic expression and shows that too.

Nice idea. If I'm not missing something, there's one inconvenience: The calculator will never know when an expression is 'finished'. You'd either have to clear the accumulator by hand or have a stack of expressions, which grows faster than the RPN stack.

Yes, running out of memory due to huge expressions or too many expressions is a very real consideration. However, a similar problem exists with ordinary infinite stack RPN. Such a stack (e.g. on the HP 50g) could conceivably grow and grow as calculation results are dumped onto the stack and abandoned there, until the machine starts to run out of memory and slow to a crawl. But when using it as a calculator, people don't do that; they instinctively clear the stack before each new set of problems. Those who don't clear it, quickly learn that they should, because a slow machine is annoying.

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. If they don't tidy up, Prime would bog down as it runs low on memory, just like real computers do. No need for artificial limits on stack size (although Prime already has that, unfortunately), or on expression size. The annoyance factor will cause users to work within reasonable limits.

Any ideas for other solutions?

[Tugdual]

(01-27-2014 06:45 AM)Craig Thomas Wrote:  

(01-27-2014 01:03 AM)Mark Hardman Wrote:  Ummm...

No it doesn't.

2 Enter 10 x^y

Gives a result of 1024 and not 100 as you claim it would.

Tim has eloquently defended the labeling (mis-labeling?) of these functions in previous posts.

Mark Hardman

Laughing.....what?

I hope you're joking.

Actually if I put me back into my teenager shoes (ahem quite a long time ago ...) I remember struggling with that kind of things when I discovered RPN. It even took me some effort to understand in what sense a simple division shall be entered...
So I think the argument is quite valid.

[Tim Wessman]

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