Reverse Polish notation

Prefix notation

Infix notation

Postfix notation

Reverse Polish notation (or just RPN) by analogy with the related Polish notation, a prefix notation introduced in 1920 by the Polish mathematician Jan Łukasiewicz, is a mathematical notation wherein every operator follows all of its operands. It is also known as Postfix notation and is parenthesis-free as long as operator arities are fixed.

The Reverse Polish scheme was proposed in 1954 by Burks, Warren, and Wright^[1] and was independently reinvented by F. L. Bauer and E. W. Dijkstra in the early 1960s to reduce computer memory access and utilize the stack to evaluate expressions. The notation and algorithms for this scheme were extended by Australian philosopher and computer scientist Charles Hamblin in the mid-1950s.^[2][3]

During the 1970s and 1980s, RPN had some currency even among the general public, as it was widely used in desktop calculators of the time – for example, the HP-10C series and Sinclair Scientific calculators.

In computer science, postfix notation is often used in stack-based and concatenative programming languages. It is also common in dataflow and pipeline-based systems, including Unix pipelines.

Most of what follows is about binary operators. A unary operator for which the Reverse Polish notation is the general convention is the factorial.

Explanation

In Reverse Polish notation the operators follow their operands; for instance, to add three and four, one would write "3 4 +" rather than "3 + 4". If there are multiple operations, the operator is given immediately after its second operand; so the expression written "3 − 4 + 5" in conventional infix notation would be written "3 4 − 5 +" in RPN: first subtract 4 from 3, then add 5 to that. An advantage of RPN is that it obviates the need for parentheses that are required by infix. While "3 − 4 * 5" can also be written "3 − (4 * 5)", that means something quite different from "(3 − 4) * 5". In postfix, the former would be written "3 4 5 * −", which unambiguously means "3 (4 5 *) −" which of course reduces to "3 20 -".

Interpreters of Reverse Polish notation are often stack-based; that is, operands are pushed onto a stack, and when an operation is performed, its operands are popped from a stack and its result pushed back on. Stacks, and therefore RPN, have the advantage of being easy to implement and very fast.

Note that, despite the name, reverse Polish notation is not exactly the reverse of Polish notation, as the operands of non-commutative operations are still written in the conventional order (e.g. "/ 6 3" in Polish notation corresponds to "6 3 /" in reverse Polish, both evaluating to 2, whereas "3 6 /" would evaluate to 0.5).

Practical implications

This section is in a list format that may be better presented using prose. You can help by converting this section to prose, if appropriate. Editing help is available. (May 2009)

• Calculations occur as soon as an operator is specified. Thus, expressions are not entered wholesale from right to left but calculated one piece at a time, most efficiently from the center outwards. Some claim this results in fewer operator errors when performing complex calculations.^{[citation needed]}
• The automatic stack permits the automatic storage of intermediate results for use later: this key feature is what permits RPN calculators to easily evaluate expressions of arbitrary complexity: they do not have limits on the complexity of expression they can calculate, unlike algebraic calculators.
• Brackets and parentheses are unnecessary: the user simply performs calculations in the order that is required, letting the automatic stack store intermediate results on the fly for later use. Likewise, there is no requirement for the precedence rules required in infix notation.
• In RPN calculators, no equals key is required to force computation to occur.
• RPN calculators do, however, require an enter key to separate two adjacent numeric operands.
• The machine state is always a stack of values awaiting operation; it is impossible to enter an operator onto the stack. This makes use conceptually easy compared to more complex entry methods.
• Educationally, RPN calculators have the advantage that the user must understand the expression being calculated: it is not possible to simply copy the expression from paper into the machine and read off the answer without understanding. One must calculate from the middle of the expression, which is only meaningful if the user understands what they are doing.
• Reverse Polish notation also reflects the way calculations are done on pen and paper. One first writes the numbers down and then performs the calculation. Thus the concept is easy to teach.
• The widespread use of electronic calculators using infix in educational systems can make RPN impractical at times, not conforming to standard teaching methods. The fact that RPN has no use for parentheses means it is faster and easier to calculate expressions, particularly the more complex ones, than with an infix calculator, owing to fewer keystrokes and greater visibility of intermediate results. It is also easy for a computer to convert infix notation to postfix, most notably via Dijkstra's shunting-yard algorithm – see converting from infix notation below.
• Users must know the size of the stack, since practical implementations of RPN use different sizes for the stack. For example, the algebraic expression , if performed with a stack size of 4 and executed from left to right, would exhaust the stack. The answer might be given as an erroneous imaginary number instead of approximately 0.5 as a real number.
• When writing RPN on paper (something which even some users of RPN may not do) adjacent numbers need a separator between them. Using a space is not good practice because it requires clear handwriting to prevent confusion. For example, 12 34 + could look like 123 4 + but in a monospace font it is quite clear, while something like 12, 34 + is straightforward. The comma becomes a virtual Space key.
• RPN is very easy to write and makes practical sense when it is adopted. The "learning" process to adopt RPN in writing usually comes later than adopting RPN on a calculator so that one may communicate more easily with non-RPN users.

The postfix algorithm

The algorithm for evaluating any postfix expression is fairly straightforward:

• While there are input tokens left
  • Read the next token from input.
  • If the token is a value
    • Push it onto the stack.
  • Otherwise, the token is an operator.
    • It is known a priori that the operator takes n arguments.
    • If there are fewer than n values on the stack
      • (Error) The user has not input sufficient values in the expression.
    • Else, Pop the top n values from the stack.
    • Evaluate the operator, with the values as arguments.
    • Push the returned results, if any, back onto the stack.
• If there is only one value in the stack
  • That value is the result of the calculation.
• If there are more values in the stack
  • (Error) The user input has too many values.

Example

The infix expression "5 + ((1 + 2) * 4) − 3" can be written down like this in RPN:

5 1 2 + 4 * + 3 −

The expression is evaluated left-to-right, with the inputs interpreted as shown in the following table (the Stack is the list of values the algorithm is "keeping track of" after the Operation given in the middle column has taken place):

When a computation is finished, its result remains as the top (and only) value in the stack; in this case, 14.

The above example could be rewritten by following the "chain calculation" method described by HP for their series of RPN calculators:^[4]

As was demonstrated in the Algebraic mode, it is usually easier (fewer keystrokes) in working a problem like this to begin with the arithmetic operations inside the parentheses first.

1 2 + 4 * 5 + 3 −

Converting from infix notation

Edsger Dijkstra invented the Shunting-yard algorithm to convert infix expressions to postfix (RPN), so named because its operation resembles that of a railroad shunting yard.

There are other ways of producing postfix expressions from infix notation. Most Operator-precedence parsers can be modified to produce postfix expressions; in particular, once an abstract syntax tree has been constructed, the corresponding postfix expression is given by a simple post-order traversal of that tree.

Implementations

History of implementations

The first computers to implement architectures enabling RPN were the English Electric Company's KDF9 machine, which was announced in 1960 and delivered (i.e. made available commercially) in 1963, and the American Burroughs B5000, announced in 1961 and also delivered in 1963. One of the designers of the B5000, Robert S. Barton, later wrote that he developed RPN independently of Hamblin, sometime in 1958 while reading a textbook on symbolic logic, and before he was aware of Hamblin's work.

RPN in Hewlett-Packard

Friden introduced RPN to the desktop calculator market with the EC-130 in June 1963. Hewlett-Packard (HP) engineers designed the 9100A Desktop Calculator in 1968 with RPN. This calculator popularized RPN among the scientific and engineering communities, even though early advertisements for the 9100A failed to mention RPN. The HP-35, the world's first handheld scientific calculator, used RPN in 1972. HP used RPN on every handheld calculator it sold, whether scientific, financial, or programmable, until it introduced an adding machine-style calculator, the HP-10A. HP introduced an LCD-based line of calculators in the early 1980s that used RPN, such as the HP-10C, HP-11C, HP-15C, HP-16C, and the famous financial calculator, the HP-12C. When Hewlett-Packard introduced a later business calculator, the HP-19B, without RPN, feedback from financiers and others used to the 12-C compelled them to release the HP-19BII, which gave users the option of using algebraic notation or RPN. From 1990 to 2003 HP manufactured the HP-48 series of graphing RPN calculators and in 2006 introduced the HP-50g with a 131x80 LCD and a 75 MHz ARM CPU that emulates the Saturn CPU of the HP-48 series.

RPN in Soviet Union

Soviet programmable calculators (MK-52, MK-61, B3-34 and earlier B3-21^[5] models) used RPN for both automatic mode and programming. Modern Russian calculators MK-161^[6] and MK-152^[7], designed and manufactured in Novosibirsk since 2007, are backward compatible with them. Their extended architecture is also based on Reverse Polish notation.

Current RPN implementations

Existing implementations using Reverse Polish notation include:

• Any Stack-oriented programming language, such as:
  • Forth
  • Factor
  • PostScript page description language
  • Ambi
  • Befunge
• RPN Scientific Calculator for Mac OS X
• RPN calculator for Microsoft Windows
• XCALC for Microsoft Windows
• Open Source RPN Calculator for Microsoft Windows
• RPN Alchemy Arbitrary Precision RPN Calculator for Microsoft Windows and Linux
• Microsoft PowerToy calculator for Microsoft Windows XP
• RPN calculator for cellular phones, in open source Java
• RPN calculator for Palm PDAs
• Mac OS X Calculator
• RPN calculator for Mac OS X and iPhone
• Some Hewlett-Packard science/engineering and business/finance calculators
• Unix system calculator program dc
• MAcalc for the iPhone
• Interactive JavaScript RPN calculator
• JavaScript RPN calculator with keyboard-based user interface, more like HP calculators
• Mouseless online RPN calculator
• Linux IpTables "Rope" programming language
• b:Ada Programming/Mathematical calculations (RPN calculator implemented in Ada)
• Emacs lisp library package: calc
• Sinclair calculators
• Open source GTK+ based galculator
• Infix to Postfix Conversion / Postfix Evaluator / Postfix to Infix Conversion [1]
• Simple XUL RPN Calculator
• A programmable JavaScript RPN calculator
• A Custom Function for FileMaker Pro Advance
• RPNParser class in Ruby
• The RPN/RPL Implementations web page, also posted as a USENET FAQ
• HC - Open Source calculator - Open Source calculator for almost any system (precompiled versions exist for *NIX and Windows) which supports both infix and postfix (RPN) notation

A Postfix evaluator implemented in Python

import operator
 
OPERATORS = {
    '+': operator.add,
    '-': operator.sub,
    '*': operator.mul,
    '/': operator.truediv,
    '^': operator.pow,
    '%': operator.mod,
}
 
def evaluate_rpn(expression, stack):
    try:
 
        for token in expression.split():
            try:
                result = float(token)
            except ValueError:
                result = OPERATORS[token](stack.pop(-2), stack.pop())
            stack.append(result)
 
    except KeyError:
        print "Invalid input", repr(token)
    except IndexError:
        print "The stack is too small to apply the operator", repr(token)
 
if __name__ == "__main__":
    print "RPN.py - Press Control-D to exit."
 
    stack = []
 
    try:
        while True:
            evaluate_rpn(raw_input('%s> ' % stack), stack)
    except (KeyboardInterrupt, EOFError):
        print

See also

References

External links

• RPN or DAL? A brief analysis of Reverse Polish Notation against Direct Algebraic Logic – By James Redin
• Postfix Notation Mini-Lecture – By Bob Brown
• Fith: An Alien Conlang With A LIFO Grammar – By Jeffrey Henning
• Good Ideas, Through the Looking Glass – by Niklaus Wirth
• Ambi browser-based extensible RPN calculator – By David Pratten