On Dec 5, 2004, at 05:31, Liam Clarke wrote:
RPN calculator, with operators and operands separate? Sounds counter-intuitive to me. What's the advantage I'm missing?
Well, the best way to explain is to take an example. Let's say you want to calculate ((2 + 5) * 3 - (4 / 6)) * ((8 - 2 * 3) / 9 + (10 - 1))
Using a conventional calculator, you'd input the entire expression as above. Considering you have a good calculator (i.e. the parens are not shifted), that's at least 34 keystrokes, you have to get the parens right, and the calculator, which is idling as you type the expression, requires some extra processing time as soon as you hit "enter" to turn it into something it can understand.
Now, with a RPN calculator, you input your expression as a tree, where the leaves are the operands and the nodes are the operators, in the order where they have to be processed. In other words, if you were using a HP48, here's what you'd be inputting:
2 5 + 3 * 4 6 / 8 2 3 * - 9 / 10 1 - + *
What happens, is that every time you enter an operand (in our case, a number), it's pushed in a stack (which is visible on the screen). And every time you enter an operator, it is applied to the last two operands you entered (they get popped out of the stack) and the result is pushed back in.
The economy in keystrokes (32 in that case, given that you have to hit enter after each operand, but operators can be set up so that you don't) is marginal. However:
1) You don't need parentheses any more. You don't have to worry about forgetting to close one, or closing one at the wrong place. In fact, you don't even need to remember the operator priorities.
2) The calculator is working as you type: when you enter an operator, it knows it can compute an operation, unambiguously -- so it does. As a result, RPN calculators often "feel" faster. And since your keystrokes are buffered, you don't even have to worry about slow elementary operations.
3) Not only does the calculator feel faster, it also is faster. Traditional calculators have to parse the algebraic expression to actually convert it to a RPN-like format that can then be evaluated. RPN calculators don't have to. Most RPN calculators also include an algebraic mode to allow you to see the difference; in the case of the HP48 series, using said algebraic mode immediately makes you feel the calculator's main weakness: its processor is ridiculously slow (4 MHz 4-bit Saturn CPU). But when using the calculator in RPN mode, it takes a TI-92 (which sports a 10 MHz 68000) to beat it. Not too bad for a machine that dates back to 1990.
All of this, combined to a powerful programming language (RPL -- Reverse Polish Lisp) and a few other interesting features (the most noticeable being almost out-of-the-box Assembly programming capabilities) gave the HP48 somewhat of a cult following, and an incredible game development community: by the time mine gave up the ghost about 6 years ago, there were perfect conversions of Lemmings and Civilization, Dune 2 was well on its way, artists were displaying pictures in 16-greyscale on a screen that has a depth of 1 bit, playing PCM sound on the shittiest buzzer in the world, and people were using the IR data capabilities of the 48 to turn it into a TV remote. But I digress ;)
In any case, it takes a while to get used to RPN, but once you get the hang of it, you feel frustrated when you come back to regular algebraic notation.
Although as far as pocket calculators are concerned, you don't have a choice anymore -- HP stopped producing calculators a few years ago, having basically done nothing in 15 years to improve the design of the 48/49 series. A shame, really. I call it the "Commodore effect".
P.S.
Nice Shodan quote Max ;)
Hehe... Thanks.
-- Max
maxnoel_fr at yahoo dot fr -- ICQ #85274019
"Look at you hacker... A pathetic creature of meat and bone, panting and sweating as you run through my corridors... How can you challenge a perfect, immortal machine?"
_______________________________________________ Tutor maillist - [EMAIL PROTECTED] http://mail.python.org/mailman/listinfo/tutor
