[Tutor] Simple RPN calculator

[Max Noel]

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?"