Isn't that the same number of keystrokes?
[3] [+] [4] [=]
[3] [Enter] [4] [+]
Both use four keystrokes.
[3] [+] [4] [=]
[3] [Enter] [4] [+]
Both use four keystrokes.
See here:
http://calculatorauthority.com/why-use-a-reverse-polish-nota...
>For example, we want to compute “(13+3)÷(4×2)” using a calculator of algebraic notation (not a scientific one) then we have to do many steps to reach the answer. Firstly, we have to compute “(13+3)” and then we will save the answer to the memory of the calculator. Then we have to compute the calculation in the denominator i.e. “(4×2)” and we have to save this answer too to the memory of the calculator. In the end, we will bring both the answers and will perform the last operation of division. This procedure has taken a reasonable amount of time. This thing can be avoided by using RPN calculator. In RPN calculator, we have to insert just a single line expression as “13 Enter 3 + 4 Enter 2 × ÷” and the answer will be computed instantly.
More generally the use of a stack (in the case of some calculators an actually visible stack) helps a lot with complex formulas.
[1 3 + 3 = ÷ 4 ÷ 2 =] is also 10 button presses, and how I would have entered it on an infix $10 TI-30XA during an exam. (At least, it's how I would have entered it if the figures weren't so small.) You could argue that it's cheating to "cook" the input beforehand so that the '4×2' divisor becomes two '4' and '2' divisors, but then you would have to ignore that RPN requires its own pre-cooked input (and that of the two, the RPN form is the one that relies on a more extensive cook).
There is no "cooking" in the RPN input, the way you input is a little more similar to how you do manually operations, and in the order numbers are written from left to right, but of course beauty is only in the eye of the beholder.
A (as well small) advantage is that on RPN you "see" that you are dividing 16 by 8, particularly - as hinted previously - when you have a RPN calculator that allows you to visualize the stack you can see better "partial" results.
Now be nice, and do (13+3)/(3x(SQR(4+2))).
[1 3 Enter 3 + 3 Enter 4 Enter 2 + SQR * /]
You do your pen and paper algebra in RPN?
The point of my "cooked" input comment wasn't to say that the mental overhead to convert to RPN is complicated or cannot come naturally after some time getting used to it; it was a defense of my swapping the division operation to multiply by the reciprocal. The idea is that if I hadn't pre-emptively addressed this in my first comment, I expected for someone to claim that I was cheating and feeding in "cooked" input for the infix case. My point is that if you recognize that converting to RPN is trivial and want to count that as a zero-cost operation when scoring the efficiency of RPN, then you have to recognize that converting the divisor to a reciprocal factor is just as trivial (moreso, really) and should be scored as a zero-cost operation, too.
Otherwise, what you have is an inconsistent standard where the infix conversion gets arbitrarily counted against the infix case, but the RPN conversion is somehow "free".
> Now be nice, and do (13+3)/(3x(SQR(4+2)))
I got 15 button presses, compared to your 14. I can live with that, given this is a calculator that can be picked up for $10. And that's the biggest savings, considering that the other things I had to worry about as a student were being gouged by mandatory meal plans and expensive, low-quality, on-campus housing.
FWIW, I actually like postfix notation.[1]
> At least, it's how I would have entered it if the figures weren't so small.