Re: Functional programming? (RPN -v- Algebraic)
- To: mathgroup at smc.vnet.net
- Subject: [mg92174] Re: Functional programming? (RPN -v- Algebraic)
- From: Joseph Gwinn <joegwinn at comcast.net>
- Date: Mon, 22 Sep 2008 05:27:57 -0400 (EDT)
- Organization: Gwinn Instruments
- References: <gat9oj$eie$1@smc.vnet.net> <gavqlj$en8$1@smc.vnet.net> <gb2dur$bgb$1@smc.vnet.net>
In article <gb2dur$bgb$1 at smc.vnet.net>, AES <siegman at stanford.edu> wrote: > 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. 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