How much has RPN/RPL spoiled you?

[Les Bell]

I've posted a few times recently in discussions about RPN, particularly about the use of RPN to evaluate algebraic expressions from left to right.

I take the view that the RPN user's knowledge of the problem domain guides his approach to the problem and essentially avoids many ambiguities or pitfalls that seem to occur, and I've cooked up a very simple example to demonstrate.

If asked to calculate the surface area of a cylinder of 4m diameter (2m radius) and height 6m, I suspect many students - since this is the topic they are studying at the time - will have an algebraic equation in front of them and may already have reduced it to this form:

\[
A = 2 \pi r ( r + h)
\]
I suppose some RPN novices might plod from left to right along this: 2 PI * 2 * 2 ENTER^ 8 + *. The experienced RPN user will solve this from the inside out, with the keystrokes 2 ENTER^ ENTER^ 6 + * PI * 2 * (noticing that two copies of r (2) are required on the stack). This saves double-entering the radius

However, that's the mathematical approach to the problem.

The classic engineering RPN user will solve it by reasoning thusly:

"First I need the area of the end cap - that's \(\pi r^2\), so I enter 2 ENTER^ * PI *, and there's two of those, so 2 *. Now I need the area of the vertical wall, which will be the circumference times the height, so that's 4 ENTER^ PI * 6 *. And I need to add that to the area of the ends, which is already on the stack, so +."

All up, you get: 2 ENTER^ * PI * 2 * 4 ENTER^ PI * 6 * +. It's 4 more keystrokes than the mathematical approach, but it's done entirely on the fly, with no paper-and-pencil work or reference to formulas, other than the most basic.

RPN is great for supporting that kind of reasoning - you work towards the answer via a series of intermediate steps, which are retained on the stack as you go.

(06-05-2015 11:54 PM)Thomas Klemm Wrote:  Whether your code is maintainable has little to do with the programming language you use.
It is more related to how the code is organized.
Using subroutines or local variables is a way to give meaningful names. This helps to understand and thus maintain the code.

RPL programming is a bit like that, as Thomas's post shows; it seems to me that you're meant build up a complete RPL program by composing it from lower-level functions. It would be easy enough to do an RPL version of my example by writing RPL functions for the area of a circle, etc. and composing them into an RPL program.