# HP Forums

Full Version: RPN and students
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

I want to show the effectiveness of RPN to my student compare to their TI graphing calculator. Do you have an exemple of a simple arithmetic calculation but with lot of steps and () that i can compete with them?

Thanks

sqrt(5*((((0.2*(350/661.5)^2 + 1)^3.5 - 1)*(1 - 6.875*10^-6*25500)^-5.2656 + 1)^0.286 - 1)) = .8357...

This is not a good example, IMO, if you are trying to show the advantage of RPN over ALG. True, the number of keystrokes is less. But the complexity of the expression perhaps tilts the advantage toward ALG?

To quote this site, under Learning RPN,

"You can easily evaluate more complicated expressions than the one shown above. Just start with the innermost set of parentheses and work outwards as you would to solve the expression with a pencil and paper". [Emphasis added]

For a simple mind like mine, it's too easy to get lost in evaluating such an expression in RPN.

With ALG, I can just start at the left and go to the right. Of course, I have to type it correctly.

The one I use is:

Solve 300=2.45 e^(.025x) +35for x.

Using RPN you can solve it without writing anything down (just perform the inverse operations):

```300 ENTER
35 -
2.45 /
ln
.025 /
```

On an algebraic input calculator, you almost have to solve it on paper first (or do some mental gymnastics) in order to see exactly how to type it in:

ln((300-35)/2.45)/.025 =
which just looks atrocious.

CHUCK

Edited: 9 Dec 2010, 8:18 p.m.

Whatever you do, make sure you just show your students how RPN *can* be easier to work with, but don't try to convince them that RPN is the best system no-matter-what.

http://www.woz.org/letters/general/57.html

See the last "Comment from E-mail" on that page, and Steve Wozniak's response.

Note: I have been an RPN user for nearly 35 years now, and I wouldn't have it any other way -- but I'm not going to try to proselytize. (Same thing with my use of vi.) If I hear anyone complain about the tools they're using, *then* I may start to talk, but I'm not going to Preach The Word! :-)

How about the quadratic equation? It should be familiar to them.

To me, the key advantage is that you can evaluate an expression that appears in a textbook. If it's already written out on one line with the appropriate parentheses then ALG will be easier, but in textbook form, where the divisors and radicals and subscripts and superscripts all imply orders of operation, RPN reall shines.

For bonus points, show how easy it is to save the intermediate sqrt(b^2 -4ac) in RPN so you can evaluate the second root easily.

Dave

Quote:
The one I use is:

Solve 300=2.45 e^(.025x) +35for x.

Using RPN you can solve it without writing anything down (just perform the inverse operations):

```300 ENTER
35 -
2.45 /
ln
.025 /
```

On an algebraic input calculator, you almost have to solve it on paper first (or do some mental gymnastics) in order to see exactly how to type it in:

ln((300-35)/2.45)/.025 =
which just looks atrocious.

If the user of a TI-83+ wants to solve by generating the equation for x he does NOT have to derive the equation by using pencil and paper and then enter the derived equation into his machine. Rather, he uses the display as a scratchpad and uses the cursor keys and the insert function to generate the derived equation in the following manner

Place (300-35)/2.45 in the display

Realize he has to insert the ln function at the front. Slew to the left margin, press 2nd INS, press ln and see ln ( inserted at the front of the equation.

Slew to the end of the entered equation and press ) / .025 and see the derived equation in the display as

ln((300-350/2.45)/.025

and press ENTER to solve. It seem to me that the solution for x isn't atrocious. It is just what it is.

The user of the TI-83+ does NOT have to solve by entering the equation in that manner. Rather, he can solve the problem as follows::

300 - 35 ENTER

/ 2.45 ENTER

LN 2nd ANS ENTER

/ .025 ENTER

which yields the same intermediate displays as would be received with a typical RPN machine. The same sequence will work on any of the TI graphic machines. A similar sequence will work in algebraic mode on the HP-35s.

I agree, Palmer, there is nothing "atrocious" to me about just keying in the expression the same way you read the problem statement in any published source.

I do see that RPN has some advantages with some types of math problem solving, but I don't think I'll ever understand this seemingly fanatical devotion to it.

I think part of it stems from a feeling of remaining connected with the process of solving--of doing the maths rather than letting the machine do it. The formula entry approach is like "the chimp can go to space" whereas RPN is like Mr. Jaeger in the X-15 and the NF-104.

Quote:
To me, the key advantage is that you can evaluate an expression that appears in a textbook. If it's already written out on one line with the appropriate parentheses then ALG will be easier, but in textbook form, where the divisors and radicals and subscripts and superscripts all imply orders of operation, RPN reall shines.

That is interesting. And true. It really took the "textbook entry" approach before the "algebraic" entry became universally possible for any published equation. Interesting too that the 48G really didn't have a useable textbook sort of entry system until the Metakernel/Erable/ALG48 developments--the original equation editor is really really horrible.

However, many equations worked just fine even with that old infix arithmetic with postfix functions "algebraic" that was used in the Ti SR series, as described by Steve Wozniak.

Quote:
there is nothing "atrocious" to me about just keying in the expression the same way you read the problem statement in any published source.
I would reiterate however that that is not the way most engineering calculations in real life go. The steps are more commonly figured out in your head as you take a number, do something to it, (see the result), do something else to it, etc., which seldom happens in left-to-right order. (That's not to say it can't be done this way in ALG-- it's just not quite as slick.) If it's already figured out for you (or you've figured it out yourself before), it's probably already in a program waiting for inputs.

Quote:
I do see that RPN has some advantages with some types of math problem-solving, but I don't think I'll ever understand this seemingly fanatical devotion to it.
I could have gone either way (RPN or ALG), until I started using my 41cx in the late 1980's for equipment control and data acquisition and suddenly RPN came out way ahead. In computer programming languages, once I got into Forth (which is RPN), I never wanted to use an algebraic language again with its piles of parentheses and punctuation.

Quote:
I do see that RPN has some advantages with some types of math problem solving, but I don't think I'll ever understand this seemingly fanatical devotion to it.

Devotion to their mechanization isn't unique to rpners. Back in the 1980's I was the editor of a newsletter for TI machines. We were a least as dismissive of RPN as the rpners are of algebraic. One source of humor was the nomenclature "reverse Polish". It was suggested that an idea like that could only have originated in that old children's book Inside Outside Upside Down.