MathGroup Archive 2008

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: Functional programming? (RPN -v- Algebraic)

  • To: mathgroup at
  • Subject: [mg92101] Re: Functional programming? (RPN -v- Algebraic)
  • From: AES <siegman at>
  • Date: Sat, 20 Sep 2008 04:57:52 -0400 (EDT)
  • Organization: Stanford University
  • References: <gat9oj$eie$> <gavqlj$en8$>

In article <gavqlj$en8$1 at>,
 Joseph Gwinn <joegwinn at> 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 

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)