For simple stuff, sure. Try -b±√(b²-4ac))/2a. Or anything complicated really. You end up counting parenthesis, writing down intermediate values, and just blowing it and starting over.

It's really nice to have something complicated, being able to sanity check intermediate values, and having a visible stack made things crazy easier.

I had friends in high school, for anything non trivial they would call out "anyone get 123.5 for the answer?". Look at me, and if they didn't get my answer they would try again.

So sure, postfix is easier for the simple stuff (which is easy either way), but postfix is MUCH easier for anything non-trivial.

> For simple stuff, sure. Try -b±√(b²-4ac))/2a. Or anything complicated really.

In anything complicated and long is where RPN shines the brightest!

If it's 2+2 I don't care whether I type 2+2 or 2 2 +. But for long complex equations, give me RPN every time. All my calculators are set to RPN mode (if it doesn't have RPN mode, I'm not using it).

I know it takes a bit of getting used to, but once you do it is a huge advantage. Particularly great for university tests where speed matters.

Indeed, great for speed and correctness.

It also makes awesome use of a multiline display, even an extra 3 lines to see the stack is a game changer. Without RPN I just use the extra area for graphing.

It's especially useful for unit conversions, since with prefix you never see the intermediate values.

It's definitely easier to parse programatically, but IMO it's a nightmare to read as a human. e.g. compare these expressions:

  (x+y)^2 = x^2 + 2xy + y^2
  x y + 2 ^ = x 2 ^ 2 x y * * y 2 ^ + +

I find it nearly impossible to parse this without actually maintaining the stack in my mind.

> I find it nearly impossible to parse this without actually maintaining the stack in my mind.

You don't write out RPN in a long sequence like that. I'm a devoted RPN advocate and seeing "x y + 2 ^ = x 2 ^ 2 x y * * y 2 ^ + +" is indeed difficult to parse. But that's not at all how you use RPN.

You compute the problem going from smaller units to larger units getting intermediate results as you go and combining them. You'd never write out the sequence as you did and try to follow it after the fact.

I'm convinced a large part of the benefit people see from RPN calculators is that you have to figure out the order of operations before you start. It forces a way of thinking about the equation which is less error-prone, you're more likely to notice mistakes as well.

Takes a little getting used to, but the interesting thing is that analyzing an equation for the proper order of operations on an RPN calculator is not at all an error-prone process. It's a careful process, and it forces an understanding of the equation itself which just churning through it on an infix calculator does not.

I went through EE using an HP 49G+ and continue to this day using RPN in Emacs calc-mode.

>> I find it nearly impossible to parse this without actually maintaining the stack in my mind.

> You compute the problem going from smaller units to larger units getting intermediate results as you go and combining them

That's totally it. I've tried doing infix/standard algebraic notation on a calculator and unless the screen is big enough to see all of your brackets you're almost certainly going to screw up one of the big terms in a fraction or something like that. I think a good different way of stating the "intermediate results" part is that instead of computing the solution from left to right you're computing the solution from the inside-out.

By far the most satisfying part of doing computation in RPN is that moment at the end when you've got a big stack full of intermediate results and you just do that "+ + + + +" to add them all up and bam! Answer!

Edit: I had two thoughts back-to-back after writing that.

First thought: I do actually struggle sometimes with doing math in Lisp because prefix notation isn't a way that I'm used to doing math. Which led to "Hmmm... what if you did Lisp but with postfix notation instead of prefix notation"

Second though: "Ohhh... that's Forth. And you don't need brackets at all..."

> Ohhh... that's Forth. And you don't need brackets at all...

You still need them if you want variadic functions. Symmetrically, you don't need parentheses in lisp if you don't want variadic functions, as long as you're willing to draw an explicit distinction between calling a function and referring to it.

You might as well just make that distinction by using the parentheses, though.

How would you write this algebraic identity?

You write equations in the usual algebraic form. You don't write RPN on paper (or screen), that's not a thing.

When you're going to compute a value on the calculator, that's where you use RPN starting from the innermost computations working outwards, because you have a stack to keep all the intermediate results handy.

Again for like 2+2 it doesn't make any difference, but if you have a long formula with lots of values and different operations, it is much easier to do correctly and fast with RPN.

But this was a super easy sequence.

Can you give an example how it should be written?

It's exactly how you would do the calculation if you ran it by hand, unlike the regular algebraic notation. I am flabbergasted that anyone uses the latter, especially as for most of the history of mathematics calculation was done by hand!

I don't "run" x 2 ^ by hand and I don't think anyone does. Some people find different notations more intuitive and that's fine but whether it's prefix postfix or infix, it's still an abstraction.

> I don't "run" x 2 ^ by hand and I don't think anyone does

Of course everyone evaluates expressions symbolically: in code review, when debugging, even when looking over an expression just after typing it to make sure it’s right.

Many languages have different verb order - English is notionally SVO (subject-verb-object), while Hindi is SOV.

That is probably much more related to why we use prefix/infix/postfix notation: because it maps to our native languages better.