Reverse Polish Notation

In My Humble Opinion
1

I’ve never used an HP calculator, so I’ve never used Reverse Polish Notation. In my job I write programs using a sequential language I’ve been using for a dozen years, so I’m quite used to the normal algebraic layout where the operator follows the operand and using parentheses where required (or not required, for clarity). I’ve heard that RPN is more ‘logical’ and less prone to error than the usual method.

Here’s an example.

1 + 2 x 3 = ?

By the order of operations, 2 and 3 would be multiplied and 1 added afterward. 2 x 3 = 6, plus 1 = 7. But what if the desired answer is 9? Add parentheses:

(1 + 2) x 3 = 9

I think most calculators know the order of operations, and so they would come up with 7 if you entered 1 + 2 x 3 [equals]. So if someone doesn’t know the OoO and assumes the equation is worked in written order they’ll get a ‘wrong’ answer. (i.e., they assume that 1 and 2 will be added first, and then multiplied by 3.)

AIUI — again, never having used it – to get 9 one would enter this in RPN:

3 [enter] 2 [enter] 1 + x

If you wanted the OoO answer of 7, one would enter:

1 [enter] 2 [enter] 3 x +

So to get the right answer per the OoO you enter the numbers sequentially (as in the first, possibly ambiguous, equation, and then enter the operators in reverse order. Is that correct? It seems much less intuitive to me, especially since I use parentheses to ensure that I’m doing things in the order I want to do them.

So RPN types: What is the appeal of RPN? Is it really useful, given that operational order can be specified simply by using parentheses? Is processing speed an issue? ISTM that the limiting factor is primarily how fast you can enter the numbers and symbols, rather than the speed of the processor. Is it a case of ‘It’s a geek thing. You wouldn’t understand.’? Can you give examples of why RPN is ‘better’ than the normal way?

2

What my teachers told us is that it requires less keystrokes. Since calculators would die from mechanical failure rather than from anything else, less mechanical wear’n’tear was important. I don’t know about you, but I have killed a lot more keyboards than computers.

The cost of my HP was equivalent to 3 weekends’ pocket money for my richest classmates; to 25% of my yearly discretionary budget (transportation, entertainment, class materials). You bet we wanted it to last.

And the way my calculator works to get 7 is
3 (enter) 2 * 1 +

To get 9,
2 (enter) 1 + 3 *

Your version has more keystrokes.

3

I find RPN much easier and faster to use, even for ordinary calculations (such as MPG, balancing a checkbook, computing students’ final grades.) I treasure my now ancient HP 11C, which has proven to be incredibly durable.

4

On my 28S, I also have the option of entering ‘1+2x3’ [EVAL] and end up with 7, or ‘(1+2)x3’ [EVAL] and end up with 9.

But yeah, I’ll second Knorf–RPN is easier and faster, and I generally find that it makes structuring the sequences of calculations go more smoothly.

5

From a programming perspective, implementing an RPN parser is a lot easier than making one for arbitrary expressions. You just push numbers onto a stack, and pop them off when you get an operator. There are whole programming languages organized around this idea, like Forth.

6

Am I the only one who actually participated in competitions between RPN and algebraic notation calculators back in college? (Note that these were informal things we did in a dorm room. What can I say? It was a geeky school.)

7

Programmer I am head visualize stack in and rules RPN <enter>

8

I’d like to learn more about RPN.

9

Oh, yes. The batteries are held in by tape now, but it’s still functioning after 22 years. Younger engineers scoff, but if they touch my HP, there will be Hell To Pay.

10

I am an engineer and I prefer RPN. It’s faster and more logical.

11

As I implied in the OP, I have no reason to use RPN. But it just sounds geeky, and therefore interesting.

So if I want to learn RPN, what would be a good calculator to do it on? An HP 35s? I looked at the $12-cheaper HP 33S, but it’s funny-looking. How about an HP 50g? I already have a TI, so I don’t really need a graphing calculator.

12

hp’s were absolutely the best calculators in the world… in 1982.
Back then, the most common calculators wereTexas Instruments, with tiny little buttons that barely moved when pressed. You couldn’t always tell by feel whether the key you just pressed had worked. The HP’s had big, bouncy keys with a clearly audible and “feelable” click, that felt good under your fingers.And when it cost $200 for a simple model, it was worth buying an HP.
But the Reverse notation thing is just stupid, man…
You have to think like Yoda:
“3.14159…12.5…multiply them, I will”

13

I can German speak.

14

yeah, but German is designed to be written with the verb in the wrong place.
Math formulas are written in a specific order, so why change it?
Me, I like to press buttons in the same order that I write …

15

Scientific calculators do; basic four-function calculators don’t.

16

You don’t need a calculator to learn RPN. It’s just a different way to organize the operators which doesn’t require brackets or priorities.

The notations you thought were RPN are, in fact, RPN; you already know RPN. Your notations simply weren’t the most efficient. How many numbers you can place in stacks before you start adding operators depends only on how many stacks your machine or program has, but it’s more efficient if you follow a sequence of “numbers I want to operate first, operator, next numbers, operators, third group of numbers…” It’s also a simpler logic and it works for very long operations without needing a huge number of stacks.

The reason the calculators had more than two stacks (both my HP15C and my brother’s I-think-HP17 have four) is in order to be able to manage things like:

{(a+b)*(c+d)}/(e+f)

Using your method (first all numbers, then all operators) wouldn’t work there.

17

From the perspective of someone who has never used an HP calculator, only used this in programming.

  1. Postfix notation removes a layer of computational complexity on the computer’s side. You don’t have to layer the parser by the order of operations if there is no such thing.

  2. Less keystrokes, you never type parenthesis (they count as two keystrokes on QWERTY typewriter SHIFT+0). Less keystrokes translates to less errors.

  3. No associative ambiguity. Think 1+2+3: Is it (1+2)+3 or 1+(2+3)? (This is important for examining intermediary results vs expected intermediary results.)

  4. It’s more mechanical, there is two simple evaluation rules (post-tokenization,stack based):
    a. If($token is number) push $token.
    b. If($token is operator) push eval(pop,pop,$token).

  5. A simple change to the second rule will allow you to see unambiguous intermediary results.
    If($token is operator)
    $result= eval(pop,pop,$token)
    display $result
    push $result

  6. Generally forces users to eschew infix/algebraic shorthand notations. 6(5+3) which can lead to errors or unexpected consequences to new users.

18

Sorry to be contrarian. This only requires one stack…

a b + c d + * e f + /

Your point however of all numbers then all operators still holds true though. To convert from infix to postfix requires you to list the evaluations in the order which you wish them to occur.

19

For me, it’s easier to learn things (especially things I don’t need to learn) if I can see the results, so I’d need a calculator.

How would your equation look in RPN?

EDIT: I see this has been answered.

20

Normal in-fix notation required more than 50% more keystrokes in many cases. If you were doing lots of calculations, it added up.

Furthermore, I found that it was harder to mis-key in RPN. Part of the problem with parentheses was that the first one in a sequence didn’t change the display. So you really couldn’t be sure if the keystroke had taken or not. If you had two or three layers of parens the odds of making a mistake increased. With RPN if you miskeyed something the intermediate result usually would give you a clue that you’d done something wrong.