# HP Forums

Full Version: Mach number - RPN vs. Algebraic
You're currently viewing a stripped down version of our content. View the full version with proper formatting.

r. d. bärtschiger posted:

"Whenever I buy another type of calculator I always use the following equation, from page 106 of the HP-67 Owner's Handbook, to test the useability of the new calculator. Using an HP calculator usually takes about 45 seconds to get the correct answer. Using an algebraic calculator usually takes much longer, twenty minutes or more, if it in fact can solve the problem at all."

With all due respect, and not to doubt your words but your quoted figure and comment "twenty minutes or more if it in fact can solve the problem at all" seems a bit misleading and a lot unfair. 20 *minutes* ? Are you serious ?

If you are, it seems to me to be a typical case of a "language" chauvinist, using ineptly a "language" he dislikes, then pointing out how bad and inefficient are the results he inefficiently produced. You'd have a similar case if someone profoundly disliking RPN were to solve this particular Mach number example using RPN: he would take ages to solve it, would do a lot of false restarts and unnecessary stack manipulations, then would complain how much RPN sucks. Simply preposterous.

"Even trying to enter this equation into an HP-48GX or 49G+ equation writer is a difficult task."

Maybe that's the case for those calculators, but this "difficult" evaluation is a piece of cake for my SHARP PC-1350. The formula is entered like this:

```Sqrt(5*(((((1+.2*(350/661.5)^2)^3.5-1)*(1-6.875E-6*25500)^-5.2656)+1)^.286-1))
```
where Sqrt is the "square root" symbol (a single keystroke). I timed myself entering this equation, exactly as written, and it took me 60 seconds flat (not "20 minutes"), the displayed result being 0.835724535, correct to all digits shown. If it actually took you 20 minutes, this only shows just how inefficient you are entering and evaluating algebraic expressions, or else just how bad your algebraic calculators are.

"If you really want to see how much easier RPN is, try to calculate the answer to this problem using an algebraic calculator. [ ... ] I think you will agree the HP is easier."

No, I don't agree at all, by the simple reason that it isn't true, and your example is actually flawed. Why do I state this ? Let's see:

• Why it isn't any easier with "HP" (i.e.: classical RPN) ?: it isn't easier with classical HP RPN because, being limited to 4 stack levels, you CAN'T begin to evaluate the expression from the left, but as the actual RPN solution shows clearly, you MUST decide on a strategy for where to begin the evaluation, having to scan the expression to locate the innermost set of parentheses, then begin there, least you would need to store some intermediate result in a register. On the other hand, you CAN enter the expression in the PC-1350 exactly as written, from left to right, no strategy needed, no intermediate results stored.

Also, there's the fact that RPN isn't particularly "efficient" for this particular example. RPN takes 66 keystrokes to evaluate this, starting from the innermost depths, then going outwards. In the PC-1350, it takes 75 keystrokes to enter the expression, left to right, no reordering necessary, and the ending parentheses could be ommitted as well. I don't think the difference in keystrokes to be groundbreaking at all, and certainly does not compensate for having to decide on the order of evaluation beforehand. The mere fact that you need to give a "proper keystroke sequence" as part of the solution is a real telltale that RPN isn't at its best in this example. The PC-1350 "proper keystroke sequence" is "as written".

• Why your example is flawed ? Because it's hopelessly *aged*. This example was fine, very fine at the time it was published. I remember trying it with my newly acquired HP-67 more than 20 years ago, and being awed at the power of RPN, because this example was well-nigh intractable with the primitive algebraic calculators of the time.

But using it nowadays, as an example against *modern* algebraic calculators ? Come on !! You must be joking, or you have a serious case of wishful thinking ! Not only modern algebraic calculators, but vintage ones, as the Sharp PC-1350, can take examples like this and bigger for breakfast, without even blinking. You can key in the full expression left to right, as written, you can see it in full in the 4-line display, you can check it and recall it at will after evaluating it, to edit it and change some parameter to play what-if, you can do anything ! Try that with your classical RPN calculator. Will LASTx do you any good if the final result seems absurd ? Or will you have to reenter all of it, perhaps chosing some other order of evaluation ?

HP used this example, very complex at the time, because algebraic calculators back then had very little memory for their intermediate operands and operators and most couldn't compute this example from left to right, as written, while in RPN you easily could by applying some ingenuity to the order of evaluation, ingenuity that most HP users at the time had in spades. Also, algebraic calculators back them could not display the whole expression at once, but only the number last keyed in, or an intermediate result, not even the operands would appear in the display. There was also no way to recall the whole expression in case of error.

But what was ok and amazing then, and a very proper example and demonstration of RPN power, cannot be used right now, 2003, to demonstrate RPN "superiority" against "algebraic systems", because RPN hasn't changed an iota (RPL is *far* too different to be considered "RPN", more like FORTH) while algebraic systems have improved exponentially, and modern algebraic machines do not have the pathetic memory and display limitations that vintage models had.

That being so, your example is just too ridiculous an "exhibit" to rest your case, and can only succeed with the most fanatic, blinded RPN addicts. Any serious RPN or algebraic user will simply be ashamed of your pathetic argument.

The point is: don't get me wrong. I've been using RPN for the past 20 years, like it very much, and, honestly, there's very few people in this forum or out that can do any calculation or program more efficiently in RPN than I can, even if it isn't proper I would say so myself. But just the same, and for that same reason, I can't suffer seeing RPN being "defended" with such pathetic arguments and such flawed, obsolete, no-longer-valid examples, much less seeing a lot of people being mislead by them into a false feeling of superiority which isn't exactly justified by examples like yours.

Just you try to use this Mach number example to demonstrate the "superiority" of RPN in your HP to someone having a decent algebraic calculator (even if it is as old as the Sharp PC-1350) and you'll only succeed in making a fool of yourself, and proving the other person just how pathetic those "RPN nerds" are. It goes without saying that this is no good to the RPN cause, at all.

Long live RPN !

Best regards from V.

Edited: 5 Oct 2003, 2:39 a.m.

Well, given your arguments, I will (tomorrow sometime; I'm so tired, have to teach Sunday School tomorrow morning, and don't what the heck I'm doing up on this forum [it's 2:30 AM in NYC]) give it a try on my Casio fx-4200p just to see if it is hard or easy.

But that wasn't really why I am posting: I was able after seeing a correct display of the equation, to do the calculation on a one-line, four-stack machine, the HP-34C, without having to commit the first innermost term to a memory register. It wasn't necessary. Even with so many nested parentheses, it appears four stack levels is most often enough.

Incidentally, you do make some very good points and I generally agree with you. But I still think that I'll take the five or six steps I saved with RPN entry any day... for that reason, as the smallest economy in finger presses is worth it to me.

I entered your listing of the equation exactly as you wrote it above into a ti-92+, is that modern enough of a calculator for you? Upon pressing enter, it returned 'error syntax'.

rdb.

rd,

I wrote an expression parser in C# and it gave me a Nan result, because it tripped over the part "*(1-6.875e-6*25500)^-5.2656)" ... when I wrote it as "/(1-6.875e-6*25500)^5.2656)" I got the answer instantly.

Namir

Singularly unimpressive, Valentin. I just grabbed my trusty Jeppesen-Sandersen CR-5 "whizz wheel", place the Calibrated Air Speed opposite the Pressure Altitude, move the cursor to the correct Indicated Temperature, and read the Mach Number off the Mach Number scale.

No keystrokes, no messy programming and the whole process takes about three or four seconds.

Sometimes, the old ways are the best ways. . . <g>

Best,

--- Les Bell [http://www.lesbell.com.au]

If I have read your post correctly, it looks like you have replaced a single _*_ by _/_. When I do this, I get a result of .325625586602 instead of .835724535179

What's the problem with doing this on the HP48? Just put a 'tick' mark at the beginning and then type it in just as Valentin has it, with the "Sqrt" replaced with the square root symbol found on the keyboard. The 48 deletes one set of unnecessary parentheses, and evaluates the result as .835724535179

This is "algebraic" mode on the HP48, and it works quite nicely.

Quote:
give it a try on my Casio fx-4200p just to see if it is hard or easy
I needed three trials on this calc because, using RPN calcs for years, I've forgot a gold rule of algebraics: "open parens after sq root"

I'm sure that if I was using this Casio dayly, or if I was using the ALG entry in my 48GX everyday, I had got the answer at first attempt, as I did with RPN and with the MetaKernel Equation editor.
Matter of taste, matter of use.

But... I prefer RPN.

Raul

Looking over Namir Shammas's post more carefully, I see that I overlooked the minus sign in front of the 5.2656

Well, I normally use an RPN (actually, RPL) sequence, but when I'm
working with an algebraic formula that's already written out on paper
for me, I find it easier to just enter it into the 48 as an algebraic
object. I've never cared for the equation writer for entering
algebraics, although I do like it for viewing them. But my first try
didn't work, so I copied it onto paper and inserted the '*' operator for
the implied multiplications and added parentheses to make the order of
operations explicit.

In the following, "\v/" stands for the square root symbol, "\<<" and
"\>>" for the program delimiters, "NEG" is the +/- key, and "^" is keyed
in by pressing the yx key.

Here's the object with flag -53 set (Show all parens):

```%%HP: T(3)A(D)F(.);
@ Checksum: 68BAh
@ Bytes: 162
'\v/(5*(((((((1+(.2*((350/661.5)^2)))^3.5)-1)*((1-((6.875*(10^(-6)))*25500))^(-5.2656)))+1)^.286)-1))'
```
The same object with flag -53 clear (No extra parens):
```%%HP: T(3)A(D)F(.);
@ Checksum: 68BAh
@ Bytes: 162
'\v/(5*((((1+.2*(350/661.5)^2)^3.5-1)*(1-6.875*10^-6*25500)^-5.2656+1)^.286-1))'
```
The above look right in the equation writer and when evaluated, result
in the answer which others have said is correct: .835724535179

Having what I know is the correct algebraic object, with implied
multiplications changed to explicit, the RPL key sequence is pretty
straightforward. The sequence also gives the same answer. I've enclosed
it within program delimiters below:

```%%HP: T(3)A(D)F(.);
@ Checksum: CD8Ah
@ Bytes: 172
\<< 5 1 .2 350 661.5 / 2 ^ * + 3.5 ^ 1 - 1 6.875 10 6 NEG ^ * 25500 * - 5.2656 NEG ^ * 1 + .286 ^ 1 - * \v/ \>>
```
Actual evaluation time of either the algebraic object or the program is
about a tenth of a second.

Regards,
James

Edited: 5 Oct 2003, 7:37 a.m.

PS:

Actually, leaving out the redundant spaces in the RPL sequence:

```5 1 .2 350 661.5/2^*+3.5^1-1 6.875 10 6NEG^*25500*-5.2656NEG^*1+.286^1-*\v/
```
Press either the SPC or ENTER key where a space occurs in the above.

Again, the "^" is entered by the yx key, "NEG" by the +/-
key, and "\v/" represents the square root key. If I count correctly, that's
69 keypresses.

Regards,
James

Edited: 5 Oct 2003, 8:54 a.m.

as a random spin off, i'd like to air some related gripes.

so far, no distinction has been made between aos and formula style
entry. i am happy using either rpn or aos. formula calculators are
the ones you have to press sqrt then 5, rather than the other way
round. some even want brackets round the 5 or else they shout "syntax
error" at you. for a long time, i hated them.

more recently, ive been exposed to more and more formula calculators
because, pretty much, thats all you get nowdays. scarily, i've begun
to get more used to them and, in fact, for certain kinds of problem;
like evaluating a big formula, they are easier to work with. for a formula
written in front of you, its almost natural to press sin before x as written,
possibly because its a no brainer. indeed you have to do this on hp
solver models like the 19bii.

my gripes relate to the expression handling abilities and so far, ive
seen considerable variation in ability. some are very pedantic. eg "sin 1",
"2(3+1)" are syntax errors. personally, i would consider calculators that
rejected these as broken and give the whole formula style a bad name. also
ones that insist on the final close bracket. it means makers have missed
the point about it being a useful tool.

another of my pet hates, is the silly unary minus button on these
machines (ie "(-)"). how lame is that. so i have to press 1e-5 using the little
minus and not the binary one (or its a syntax error again). same for "2^-3".
theres no reason why the expression parser can't use the same "-" sign and get
it right. a few things are ambiguous, like "-2^3", but i can handle that.

im still waiting for a model that gets all these right.

Raul, I haven't used that Casio fx-4200p in MANY years. I'm just guessing that it's formula entry is like that of a Hp-32SII or HP-48G series calculator. If not, I'll have to wait even longer, as the only manual I have for it is on my computer's hard drive and I usually hate reading massive texts on the CRT.

Roger,

I removed the exponentiation to the negative number and replaced multiplication with division. This change remove the presence of the operatod ^- in this sequence, which can trip many interpreters (BASIC, and other runtime interpreter such as the one I used to evaluation the expression). Namir

I pretty much agree with everything. (Except some minor things, but what the hell)

You say that thats a flawed example.... could you give a good one?

I keyed Valentin's key sequence into my wife's lowly TI-30, and it spit out the correct answer after about 2 seconds. I also got the correct answer the first time on my TI-59, although I had to save the SQRT operation for last.

I think if this calculation were important to someone, then he would write down the intermediate answers anyway, since keystroke errors are very possible even on an RPN machine.

Yes, I realized that when I noticed that the minus sign had been removed. One could also use more parentheses to solve this problem. Those people who typed this expression into their HP71's had this problem, I noticed, but the HP48 in algebraic mode apparently has different precedence in this case.

rdb,

I just wanted to say that I liked your example very much, and thank you for posting it. Although, I confess that I had difficulty using it until Mark Hardman posted the scanned image from the book -- all those brackets and parentheses were hard to keep straight. But the book version was very easy to do with RPN. I just wanted you to know that some people appreciated the effort you (and Mark) made and agree with your reasons for doing it.

Sorry... I actually don't know the 4200p... If it helps, I will say that the 4000p and the famous 6300G have the same program "language", but I don't know if it is the same for the 4200p.

Raul

Thank You.

rdb.

The same solution to the

formula is provided in the HP-85 owner's manual:

**vp