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