In article ,
Gary Coffman wrote:
On Sun, 18 Apr 2004 08:39:04 -0700, "Robert Swinney" wrote:
Gary sez:
" As John noted, RPN works exactly the way you'd do the calculations with
pencil and paper, so it is a natural and familiar way to work for people
who
are comfortable with doing hand calculation. "

I will have to agree, as I often begin calculating in the middle of a
lengthy expression. Problem is, you have to record the interim results and
some care is required to maintain those results. I can do it, but it is so
much easier to begin at the beginning and enter things sequentially in AE.
Thanks Gary, I didn't realize RPN was a product of the 20s. It would seem
that for really lengthy calculations, RPN would be a labor saver.

It is a labor saver, and you don't need to record interim results, they simply
automatically get pushed on the stack as you continue to calculate, and
automatically pop off the stack when you're ready to use them. That's the
real power of postfix notation.

And I tend to start in the middle of the formula, the deepest
set of parens, and work outward as I go.

With an AE style calculator you have to be careful how you attack a problem.
There are many times when you get stuck, have to store an intermediate result
in memory, clear the calculator and start what is essentially a new calculation.
That virtually never happens with a RPN calculator. No matter the order in which
you tackle a problem, there's almost always a way to do it without storing
intermediate results in memory and restarting.

Agreed -- though it *is* possible to overflow the stack with a
poorly-chosen starting point. (And even more so with Algebraic
Notation.)

Of course for simple 2+2 stuff, RPN doesn't offer any real advantages. It is
when you start doing complex calculations that the labor savings, intermediate
results sanity checking (IMHO the most important feature), and the ability to
attack the problem in any order really starts to be of benefit. That's why RPN
calculators are such a favorite with older engineers who started out with pencil
and paper or slide rules. They're used to doing sanity checks as they progress
with a calculation. AE style calculators don't lend themselves to that.

And one of the important sanity checks is whether an
intermediate value in the denominator of a division is approaching zero
too closely -- which will blow up the computation. With RPN, you can
see that happen, and work around it by choosing a different sequence.
With Algebraic Notation, you wind up with the thing blowing up (if you
are lucky, and you still have to figure out where it happened and how to
work around it. If you are unlucky, you will wind up with values which
discard a lot of the possible precision, and never know that it
happened.

Of course nowadays people expect computers to hand them an answer without
any thought on their part. It is just plug in the numbers and wait for the result.
That's all well and good for canned solutions to known problems, but it is less
satisfactory for calculating answers to new or unique problems. You're depending
on the author of the software to have gotten it right. That's not always obvious.
For example, the early Windows calculator gave erroneous results because it
incorrectly rounded internal intermediate results. People didn't immediately
catch that because the AE style offers no way to do sanity checks on intermediate
results. They remain hidden from view.

And in really complex programs which are dependent on large
amounts of input data -- such as SPICE, the circuit emulation program --
you can wind up with divide-by-zero in a *lot* of places. Luckily, the
implementation of SPICE which I saw -- written to live under the BSD
flavor of unix -- was set up to trap the errors, and replace the results
with a maximum-positive or maximum-negative as appropriate. You really
can't see where these problems will hit, since you frequently don't know
how a device model is implemented, so you don't know what values of
components and currents/voltages/frequencies will cause that
divide-by-zero. This is made even more likely to be a problem by the
fact that the program is frequently used to sweep values through the
possible ranges, and crank out results for a large number of values.

Of course -- you're not going to be doing something as complex
as the SPICE calculations on a pocket HP -- though I have seen a tiny
implementation of a subset of SPICE for a HP-67 (one of the ones which
was programmable and had a card reader/writer to save and load programs.

Enjoy,
DoN.

--
Email: | Voice (all times): (703) 938-4564
(too) near Washington D.C. | http://www.d-and-d.com/dnichols/DoN.html
--- Black Holes are where God is dividing by zero ---