Can we have RPN back?

[John R. Graham]

(03-29-2014 05:00 AM)orcinus Wrote:  Ah, sorry, wasn't paying attention, i autoassumed you meant 2 ENTER ENTER *
Are you saying that 2 gets DUP'd one stack level up automatically if another parameter isn't provided?

If so, how is that good? What guarantee do you have something wasn't left on the stack from a previous calculation?

It has to do with lack of an entry line. Entry occurs directly into X. So, as you start entering a new value, X is automatically lifted up the stack to make room for the entry. The behavior of the [Enter] key is even more nuanced. It does these three distinct things:

1. Terminates data entry of the number into X.
2. DUPs X into Y (and, of course, first, Z into T and Y into Z).
3. Disables automatic stack lift for the next entry. Any functional operator will operate on the stack and re-enable automatic stack lift.

So, if I want to multiply 2 by 3, when I start with "2 [Enter]", both X and Y contain 2, but when I continue, typing "3", now X contains 3 but Y still contains 2. Finally, typing "x" (multiply) will consume X and Y, leaving the product in X and re-enabling automatic stack lift so that, when I operate further on the product, it won't be lost. The HP-35 and HP-41C manuals (and others, I'm sure) describe this behavoir in some detail and show the types of keystroke shortcuts that result.

Regarding something being left on the stack from prior calculations, that's never a problem on the legacy RPN calculators. Previous results are never mixed unless you explicitly mix them. Furthermore, since the stack is fixed in size, it never gets cluttered with (too many) old, unwanted results, something that can be a problem with the RPL family.

Now, all that said, I think the RPL family implementation of RPN is more straightforward, and I'm quite used to it. However, if the old automatic lift functionality had been present as an option on the RPL family (enabled, say, by a flag), I might've enabled it. Who knows?

Tim, please, if you're even remotely considering this, don't bring along the concept of a fixed 4-level stack with auto-copy of T (or else make that a separately-controllable option). Legacy stack lift behavior plus infinite typed stack seems sweet.

- John