MathGroup Archive 2008

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

Search the Archive

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

  • To: mathgroup at
  • Subject: [mg92174] Re: Functional programming? (RPN -v- Algebraic)
  • From: Joseph Gwinn <joegwinn at>
  • Date: Mon, 22 Sep 2008 05:27:57 -0400 (EDT)
  • Organization: Gwinn Instruments
  • References: <gat9oj$eie$> <gavqlj$en8$> <gb2dur$bgb$>

In article <gb2dur$bgb$1 at>, AES <siegman at> 

> 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.  

Yes, and easily verified.

>  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.  

It's provably better in the stated dimension, number of keystrokes.  
Just count them.  No other claim was made.

>  (I'd bet the study referred to above was probably carried 
> out by hp marketing people, not hp engineers.)

Actually, no.  I read it on a newsgroup long ago.

Nor does it matter if the motives of the long-ago poster were pure.  
Just count the keystrokes, and ye shall know the truth.

> 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.

My first RPN calculator was a HP-45 bought in December 1973.  I still 
have 5 HP RPN calculators in service, scattered around so I always have 
one at hand, and have some backup in case one fails.  

I also have 2 or 3 retired HP RPN calculators that all still work.  The 
HP-45 is one.  I also have a HP-41, which I programmed once.  Too much 
trouble, once I got access to real computers (which cost at least the 
same as a nice Baltimore rowhouse back then).

> 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.  

I agree, but one can have adequate mental pictures of both kinds of 
calculator.  And with an algebraic, it takes so much longer to \key 
things in that one has the leisure time to form a better picture than 
those minimalist RPN nuts.

> 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.

In simple calculations, RPN and algebraic are about equal, except for 
one thing: With RPN, intermediate results are automatically retained (to 
the depth of the stack), and one can often add a chain calculation on at 
the last moment.

As for functional versus procedural programming, I use both approaches 
where appropriate.  As for which is "better" (in the universal sense), I 
plead the Fifth Amendment.

It's sort of a parallel to the distinction between object-oriented and 
procedural programming in C/C++.  Each has strengths and weaknesses, and 
each has some real lacunae.  For a relevant instance, many signal 
processing architectures are better handled with procedural code because 
one blindly performs a sequence of mathematical operations on the 
incoming data stream, and only very late in the processing does one 
threshold the results and declare objects (such as radar detections).  
While one can force this into a OO architecture, it's better to hold off 
until the objects have naturally appeared.  This leads to a radar 
architecture where the signal processor is largely procedural and runs 
in one set of computers, while subsequent processing is almost totally 
OO and runs in a different set of computers, both parts being 
implemented in C++.

I've also written C preprocessor programs to extract and format data for 
presentation to Mathematica.  Mathematica can be pretty awkward for 
handling oddball data types, although lather versions of Mathematica 
have been far better, and I have not been forced to resort to C-coded 
preprocessors in some years.

> 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.  

I'd guess that this is _not_ true, given the kinds of mistakes I most 
often make.  If one is familiar with the calculator, probably keying 
errors are the same (except that with RPN there are fewer keystrokes to 
botch).  But my usual error is to get confused and enter the wrong 
number, or use the wrong math function.  No calculator can stop me.

> 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.

Maybe I think inside out, but I do not find complex expressions 
difficult in RPN.  You just work from the innermost parentheses out in 
the math expression one is computing.

> 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).

Well, I do use Mathematica for things too complex for a calculator, or 
too repetitious.  I started with Mathematica version 1.2, being afraid 
to buy version 1.0 of anything that complex.

Joe Gwinn

  • Prev by Date: Re: weird NMaximize behaviour
  • Next by Date: Re: Integration in Mathematica
  • Previous by thread: Re: Functional programming? (RPN -v- Algebraic)
  • Next by thread: the graphic of a function