[Date Index]
[Thread Index]
[Author Index]
Re: Functional programming? (RPN -v- Algebraic)
*To*: mathgroup at smc.vnet.net
*Subject*: [mg92101] Re: Functional programming? (RPN -v- Algebraic)
*From*: AES <siegman at stanford.edu>
*Date*: Sat, 20 Sep 2008 04:57:52 -0400 (EDT)
*Organization*: Stanford University
*References*: <gat9oj$eie$1@smc.vnet.net> <gavqlj$en8$1@smc.vnet.net>
In article <gavqlj$en8$1 at smc.vnet.net>,
Joseph Gwinn <joegwinn at comcast.net> wrote:
> > Debating which is better (functional programing or procedural
> > programing) is analogous to debates of early calculators
> > comparing HP's RPN style to TI's algebraic style. Either could
> > get the task done. And it was possible to find example problems
> > that were more efficiently done by one than by the other.
> Actually, this question was answered many years ago, and RPN required
> significantly less work to solve non-toy programs.
> How was this determined? By comparing the number of keystrokes needed
> to solve various standard programs, like interest-rate calculations in
> the financial world.
>
> The bottom line was that it took RPN about two thirds the keystrokes
> that algebraic took for the same problem.
This is no doubt a fact. To use this fact as an argument that RPN is
"better" than algebraic in any meaningful way -- particularly for real
life scientific or engineering calculations, or for calculations that
vary from problem to problem, rather than a small number of routine
"canned" or memorized "standard procedures" -- would, however, be very
debatable. (I'd bet the study referred to above was probably carried
out by hp marketing people, not hp engineers.)
I've used hp RPN scientific calculators steadily for widely varied
"calculator-level" engineering and scientific calculations since the day
they came out (in fact I'm shopping right now for an RPN replacement for
one that recently went astray). I enjoyed, as an intellectual exercise,
learning at the start something about what RPN was and where it came
from, and gaining some intuitive understanding of how it functioned.
But the purpose of calculators is to do calculations, and get answers
(correct answers!). And to do this it's vital that the user be able to
have a clear understanding and mental picture of what's going on in the
calculation steps, so he or she can structure them and enter them
correctly.
The _number_ of keystrokes involved in this -- especially when that
number apparently only differs by less than +/- 20% between the two
modes -- is as irrelevant to meaningful efficiency in problem solving as
is the much hyped speed distinction between functional and procedural
programming in Mathematica.
Efficiency in calculating of any kind is being able to obtain the
desired answer, correctly, the first time through, and with minimal risk
of making a coding error or erroneous entry or encountering a glitch
along the way. When a problem is simple enough to be a
"calculator-level" problem, RPN may in fact be better for this purpose
than algebraic -- I'd suspect it is.
As the formulaic complexity or the number of cascaded steps in a
calculation goes up, however, I'd suggest that the difficulties of
structuring the steps and entering them properly goes up very rapidly in
RPN -- maybe more rapidly than in algebraic, maybe not -- and the real
difficulty lies in understanding what you (and the calculator) are
doing, not the number of times you have to hit the keypad.
Which is why, in that situation, I fire up Mathematica in the laptop
rather than reaching for the calculator, and start writing functional
rather than procedural code. (I trust you all appreciate the double
entendre here: functional programming is the functional way to solve
problems and get answers).
Prev by Date:
**Re: Re: Apparent error integrating product of DiracDelta's**
Next by Date:
**Re: FindFit and NormFunction (to find a best fit by medians)**
Previous by thread:
**Re: Functional programming? (RPN -v- Algebraic)**
Next by thread:
**Re: Functional programming? (RPN -v- Algebraic)**
| |