Talk:Reverse Polish notation

message: Since the information about the shunting yard algorithm is mainly intended for developers who wish to convert statements in infix notation to RPN notation I think that it would be a good idea to provide an example of the algorithm in C, I would do it myself however I am not good enough at C to implement one effectively. Or a least provide a link to an implementation of it.
: The majority of the code would be for the data structures. And if you have a data structures library, there isn't really any code to show. My (C++) implementation was just a direct transcription of the algorithm into STL data structures. I think the algorithmic description is all that's needed. -- BryanMWoods 19:23, 5 December 2005 (UTC)
thread_title:  Shunting Yard 

message: We need another example that uses operators that have order importance, like - and /. I'm trying to refresh myself on this and this example with only + and * is of no help.
We also need an example with a negative number.  — Preceding unsigned comment added by Cdunn2001 (talk • contribs) 18:30, 26 July 2011 (UTC)
thread_title:  New or additional Example 

message: It seems to me the the shunting yard algorithm is worthy of a separate article. The algorithm itself is not exclusivly tied to RPN as the same algorithm can be used to produce an abstract syntax tree. Further its presence here assumes that it's the only way to produce RPN from infix notation. --Salix alba (talk) 18:54, 13 August 2006 (UTC)
replies: text: I agree with making it a separate page. DFH 18:58, 23 August 2006 (UTC)

text: Operator-precedence parser has another, different exposition of this algorithm.  Split it off and refer to it on both pages.  Tom Duff 19:36, 23 August 2006 (UTC)
thread_title:  Split shunting yard to separate article 

message: 1) while there is an operator, o2, at the top of the stack, and either
            o1 is associative or left-associative and its precedence is less than or equal to that of o2, or
Which is correct? Perhaps rewording would make it more clear.
            o1 is (associative or left-associative) and its precedence is less than or equal to that of o2,
            or
            o1 is associative or (left-associative and its precedence is less than or equal to that of o2),
: The former i think, left associativity just refers to the order in wich you have to do the operations to have associativity property verified. It has nothing to do with precedence. Danilo Roascio 11:42, 13 September 2006 (UTC)
thread_title:  Vague Explanation of algorithm 

message: This article is about RPN, but the only algorithm I see is that of the shunting yard algorithm. I've added a formal description of the RPN evaluation algorithm; better check for any errors I may have dropped in.
And yes, I agree to split the shunting yard section. Jafet 09:40, 14 September 2006 (UTC)
thread_title:  RPN? 

message: I'm trying to remember correctly, but I believe that ThePalace's scripting Language Iptscrae uses RPN. I know that calculations are similar to this: "2 3 + var =" (sets var to 5)
--TJ09 03:14, 19 November 2006 (UTC)
thread_title:  ThePalace 

message: Why is Subject Verb Object in the See Also section of RPN?  Consider that in RPN, the operands come before the operator.  In my mindset (English is my native and only language, by the way), "operator" is approximately like "verb", sort of.  I therefore think that the RPN-ish syntaxes in natural languages are the Subject Object Verb syntax and the Object Subject Verb syntax.  Perhaps I'm missing something, but I just can't see any logical reason for Subject Verb Object to be in the ==See Also== section of Reverse Polish Notation.
Stuart Morrow 18:45, 30 January 2007 (UTC)
replies: text: You're absolutely correct.  Fixed. /blahedo (t) 23:42, 2 February 2007 (UTC)
thread_title:  Language typologies similar to RPN syntax 

message: I've removed this paragraph:
:One could reorder this expression, putting the operand directly after each pair of values such as, 4 7 + 3 *. The reordered form would be entered as "4", "Enter", "7", "+", "3", "*". Both expressions are equivalent, but the first requires more memory as all operands must be stored prior to the application of their respective operators. In the second expression the result of the addition of 4 and 7 would be stored on the stack as the variable 11 where the multiplication with 3 is calculated. In the first method 3, 4, and 7 must be stored before any calculations. The second method only requires two memory locations to be stored regardless of the expression's length or complexity. The first method's memory requirements depend directly on the number of operands in the equation.
First of all, the reordering as stated is a consequence of the commutative property, not a distinct "method" of using RPN.  If the operations were instead subtraction and division, that kind of reordering would change the result!
But that could be (and is) addressed with a swap operator.  The larger problem is that the second claim, that "the second method only requires two memory locations to be stored regardless of the expression's length or complexity" is not true.  If I have an expression like "(3 + 4) * (5 + 6)", I need to store more than two values in memory no matter how I reorder them.  (At least, within the context of arithmetic operations.  This issue is related to tail recursion and continuations, but in any case, is entirely independent of the notation used for the expression. /blahedo (t) 22:59, 2 February 2007 (UTC)
thread_title:  Reordering expressions 

message: This would bring it in line with Prefix notation and the template used on the page itself. --Islomaniac 973 22:21, 11 April 2007 (UTC)
replies: text: I don't agree. At present "postfix notation" redirects here, but we should rather split this into two articles, one about the theory and concepts of postfix notations in general, and another (this one) about "Reverse Polish Notation" (RPN) implementations as entry method (in calculators and likewise) specifically. There's quite a bit more on both topics which isn't currently covered by this combined article, and which cannot easily be added at present, as the structure of the combined article is a mess. This can be improved significantly by splitting the two topics covered here into separate articles. --Matthiaspaul (talk) 12:16, 25 August 2015 (UTC)
thread_title:  Move request to "Postfix notation" 

message: Okay, I find this: http://www.csc.liv.ac.uk/~peter/this-month/this-month-3-030303.html, but I remember reading Lukasiewicz and Tarski in school, and they had both the prefix and the postfix notation, as I recall. This seems to me to be an attempt to enhance Australian contributions to computing :) The stack was invented by Friedrich Bauer in Munich, not by Hamblin, IMHO. I think we need a computer historian here. --WiseWoman (talk) 14:10, 28 December 2007 (UTC)
replies: text: Also, reference #3 to Hamblin's work is a broken link.  --69.174.58.36 (talk) 19:50, 26 May 2010 (UTC)
thread_title:  Where does the Charles Hamblin come in? 

message: The advantages and disadvantages are apparently written by a proponent of RPN, as all disadvantages are  presented as unimportant, and claims are not verified. Meertn (talk) 14:00, 12 June 2008 (UTC)
replies: text: Sections of pros and cons are discouraged.  Much like a section titled "Criticism", a "Disadvantages" section will become a troll magnet.  It's probably wiser to integrate any facts in a "Disadvantages" or "Advantages" section into the rest of the article, properly cited, and let the reader decide.  --Ds13 (talk) 17:31, 12 June 2008 (UTC)

text: I think the pros and cons would be useful, because it would give readers a better idea of when to use RPN and when to use infix notation. Let me make an attempt. When calculating a formula on the fly, RPN requires fewer keystrokes to compute the same formula (or in simple cases, no more keystrokes) and allows for intermediate calculations. When writing a formula to be seen all at once, such as on a spreadsheet, infix notation is much easier to read. It all boils down to the right tool for the job. Bostoner (talk) 00:39, 8 January 2011 (UTC)
replies: text: Actually, in simple calculations (adding 3 numbers together for example) RPN requires more keystrokes. "1 enter 2 enter 3 + +" is 7 keystrokes. "1 + 2 + 3 =" is only 6. Besides which, what is and isn't simple is open to interpretation, and probably not usefull to base encyclopeadic 'fact' on anyway. MrZoolook (talk) 12:24, 14 April 2014 (UTC)
replies: text: That simple calculation can also be done with 6 keystrokes using RPN: "1 enter 2 + 3 +". Blutackey (talk) 04:12, 8 December 2014 (UTC)
thread_title:  Neutrality of pros and cons 

message: In 1988 i implememted a functioning RPN calculator in BASIC (on the tandy 100).
The RPN language might be correctly implemented by a LIFO stack as this example show.
  x PUSH y PUSH  POPA POPB c=b+a  PUSHC
             W V U T ...
   x  PUSH   x  W V U T ...
   y  PUSH   y  x  W V U T ...
   POPA      x  W V U T ...           a
   POPB      W  V U T ...            b,a
   c=b+a     W  V U T ...           c=b+a
   PUSHC     c  W V U T ...
   
  x PUSH POPA c=sin(a) PUSHC
The implementation uses a stack of registers that move up and down, including additional user friendly registers, like L.  In the implementation i used, the registers were placed in an array, of the form (A, L, X, Y, Z, T, K).  A and K were not directly accessable to the user: A is where all answers were returned, and K was used for a kind of recall arithmetic with registers of fixed value (eg Recall * pi)
The first example runs
     ( A, L, X, Y, Z, T)    [stack lift enabled]
  p  ( A, L, p, X, Y, Z)    T lost
  ~  ( A, L, p; p, X, Y)    stack lift disabled (;)
  q  ( A, L, q, p, X, Y)    stack lift enabled (,)
  +  (p+q,L, q, p, X, Y)    set flags LastX, StkD, MoveOk
     ( r ,L, q, p, X, Y)    r is resolved for display (MoveOk)
     ( r, q, r, p, X, Y)    flag LastX is now cleared
     ( r, q, r, X, Y, Y)    flag StkD is now cleared
The second example runs
     ( A, L, X, Y, Z, T)
  p  ( A, L, p, X, Y, Z)    stack lift enabled
 sin ( r, L, p, X, Y, Z)    r = sin(p), set LastX, MoveOk
     ( r, p, r, X, Y, Z)    flag LastX clears.
These examples use a fixed stack and an extra value A.  A is only moved to X when the function returns MoveOk.  One might clear MoveOk, eg on taking the square root of a negative number.
--Wendy.krieger (talk) 11:09, 23 August 2009 (UTC)
thread_title:  RPN language different from RPN operating system 

message: If there came to be a cultural references section, it should contain a reference to:
http://xkcd.com/645/
And I disagree with the cartoon.  I think the bread is the operator, so from left to right, it should read:
sausage  mustard (floating in space)  bread
121.73.5.66 (talk) 04:48, 6 October 2009 (UTC)
thread_title:  Cultural References 

message: National Semiconductor also had calculator models that used RPN in the 70's.Halconen (talk) 16:52, 11 November 2009 (UTC)
thread_title:  History of implementations 

message: I would like to find out where/how the modern Russian calculators Elektronika MK-152 and MK-161 can be purchased.--109.193.211.159 (talk) 21:25, 24 July 2011 (UTC)
thread_title:  Modern Russian calculators 

message: Add to the "Current implementations" section dc
Link Dc_(computer_program)
Example: 
dc -e "2 3 4 + * p"
which will output 14
The dc utility is very useful when there is a need to do arithmetic calculations in the shell scripts.
Larytet (talk) 08:30, 17 July 2012 (UTC)
thread_title:  DC arbitrary precision desk calculator 

message: The deadpan assertion that "people who speak English but not Polish find his family name intimidating and possibly unpronounceable" made me chuckle, but it clearly needs a ref. Is it meant as a joke? I see from the diff that it was added by an anonymous user a few months ago.--Lemuellio (talk) 13:36, 10 January 2015 (UTC)
replies: text: Sounds like a facetious edit to me, and I can't find any sources that indicate it is in any way true, so I've removed it and added a reference for the shortened statement. Trimethylxanthine (talk) 03:46, 14 February 2015 (UTC)
thread_title:  Intimidating and possibly unpronounceable? 

message: This Algorithm fails if an operator can take only one argument.  For example the boolean NOT, or inverse.  The Algorithm needs some massaging, but I don't feel qualified.  — Preceding unsigned comment added by 137.28.222.145 (talk) 19:15, 23 June 2015 (UTC)
replies: text: Here a number of operands of the particular operation is significant. 
RippleSax (talk) 22:33, 11 December 2015 (UTC)
thread_title:  Algorithm  -- If there is only one value in the stack?   

message: So reverse polish notation always used with second stack: for converting from arithmetic expression and for evaluating.
PPN describes relations between data and commands (as in computer architecture). With polish notation easier to search templates (if it is instruction set architecture) and for example decompile this templates because they are typical and they can be assumed to be known. For this operation stack also needed. Expressions which user inputs in editor for compilation/interpretation may be simplified this way: convert to rpn with stack, evaluate with stack but only partially in places where expression may be simplified (executing of the constant expressions and subexpressions on time of rpn stack conversion for reducing cost) 
RippleSax (talk) 22:33, 11 December 2015 (UTC)
thread_title:  Usage 

message: ::In this expression, (2 0 1 6 - - ^ 2 0 1 - ~ 6 ^ + *), which evaluates to 2016, a swap is required in order to allow 2 0 1 and 6 to appear in order. I've arbitrarily used ~ as the symbol for swap but is there a standard notation for that operator?  92.29.12.4 (talk) 15:59, 4 January 2016 (UTC)
thread_title:  Swapping the two top values 

message: Despite the name, reverse Polish notation is not exactly the reverse of Polish notation, for the operands of non-commutative operations are still written in the conventional order (e.g. "÷ 6 3" in Polish notation and "6 3 ÷" in reverse Polish both evaluate to 2, whereas "3 6 ÷" in reverse Polish notation would evaluate to ½). -- I'm not sure what this is supposed to mean, and I've got some claim on the title "mathematician". What would it mean if RPN was exactly the reverse of PN? Has someone claimed that RPN is exactly the reverse of PN? Is there some belief somewhere that if it were truly "reverse", that order of evaluation would also be reversed? Is there a claim that RPN should be a mirror image of PN? --jpgordon𝄢𝄆 𝄐𝄇  18:30, 17 December 2016 (UTC)
replies: text: I am confused. Of course, nobody claimed that reverse Polish notation is exactly the reverse of Polish notation. However, given the term "reverse Polish notation" I think it's absolutely natural to assume that this would be the case, and therefore I think it's really helpful to the reader to explicitly state that it is not the case. Anyway, I won't revert if you decide to remove that sentence again. Tea2min (talk) 19:52, 17 December 2016 (UTC)
replies: text: Is there so much as a single source anywhere suggesting that this natural assumption is anyone's but your own? Ten years ago, someone was wondering about the same thing (see Talk:Reverse Polish notation#Incomprehensible example.) --jpgordon𝄢𝄆 𝄐𝄇  22:59, 17 December 2016 (UTC)
replies: text: Ah, now I think I understand. For some reason my mind apparantly implicitely added the missing word "true" that the commenter from Talk:Reverse Polish notation#Incomprehensible example wanted added. And of course I do not have a source that a reader might understand the term "reverse Polish notation" to mean reversal of "Polish notation". So, I am going to remove that paragraph again. Tea2min (talk) 07:52, 18 December 2016 (UTC)
thread_title:  Odd sentence 

message: So 3 4 +  results in 7.
How does the computer know you don't want thirty-four ?   Is the market for these devices all four years old ?
The people who wrote this, probably grew up in the heyday of the HP calculators, the 1970's.    It may not be
obvious, there should be some explanation of how it actually works when not dealing with single-digit numbers.Lathamibird (talk) 07:22, 14 August 2017 (UTC)
replies: text: Suppose computers see the difference between "" and "". :) CiaPan (talk) 08:17, 14 August 2017 (UTC)
replies: text:  Lathamibird I must tell you, CiaPan is correct. Also, I grew up a decade AFTER what you describe as the heyday of HP calculators but that was in the 1980s not the 1970s. HP calculators were extraordinarily expensive in the 1970s. My father was a cardiologist. He paid over $US 450 for an HP calculator in the 1970s. At this time, he was able to buy a brand new Mercedes-Benz 450 SL for $US 18,000. My mother was furious that he spent $450 for what she considered a toy, I recall. By the time the HP-11C was available in the 1980s, followed by the HP-12C in the later 1980s, me and all my friends at engineering school and later, business school, loved these calculators and Reverse Polish Prefix notation. Masters of Business Administration i.e. MBAs in the USA and Europe and northeast and southeast Asia and India and South America and frankly, just about everywhere, used the HP-11C (succeeded by the HP-15C) for scientific calculations and the HP-12C for financial calculations. This persisted from the mid-1980s through at least the mid-1990s. The demand continued for many years after that. HP-15C calculators have remained in demand right up through a Christmas special offered by HP in 2017. Single digit, multiple digit, it does not matter, as RPN understands them all. All one merely needs to do is append the operator at the end. And nesting is wonderfully easy--FeralOink (talk) 17:44, 13 February 2018 (UTC)
replies: text:  Just adding a ping to Lathamibird. --CiaPan (talk) 07:36, 14 February 2018 (UTC)
thread_title:  Single digit numbers ? 

message: To me the argument that RPN is hard to learn is bogus. As far as I know every kid who is taught to add two numbers is taught to do it this way:
Jot down the first number, then align from right the second number under the first number, then add digit by digit remembering to add the carries.
Eg. RPN
Linkato1 (talk) 06:36, 11 October 2017 (UTC)
thread_title:  Ease to learn 

message: There seem to be a problem with the evaluation algorithm listed that reads from right->left. This code which implements the algorithm fails on execution of the example RPN.
    const   rpn = [15, 7, 1, 1, '+', '-', '/', 3, '*', 2, 1, 1, '+', '+', '-'];
    const   operator_Stack = [];
    const   operand_Stack = [];
    let     pending = false;
    for (i = rpn.length - 1; i >= 0; i--) {   // for each token in the reversed postfix expression:
        const   token = rpn[i];
        if (typeof token === "string") {      //   if token is an operator:
            operator_Stack.push(token);       //     push token onto the operator stack
            pending = false;                  //     pending_operand ← False
        } else {                              //   else if token is an operand:
            let operand = token;              //    operand ← token
            if (pending) {                               //    if pending_operand is True:
                while (operand_Stack.length > 0) {       //      while the operand stack is not empty:
                    let operand_1 = operand_Stack.pop(); //        operand_1 ← pop from the operand stack
                    let operator = operator_Stack.pop(); //        operator ← pop from the operator stack
                    let expr = operand_1 + " " + operator + " " + operand;
                    console.log(expr);
                    operand = eval(expr);                //        operand ← evaluate operator with operand_1 and operand
                }       
            }
            operand_Stack.push(operand);     //    push operand onto the operand stack
            pending = true;                  //    pending_operand ← True
        }
    }
    console.log("Expected result: 5")
    console.log("Actual result: " + operand_Stack.pop());   //result ← pop from the operand stack  — Preceding unsigned comment added by 77.218.241.131 (talk) 16:38, 18 January 2018 (UTC)
thread_title:  Problem with Right->Left evaluation algorithm 

message: We need a section of the page comparing this to the earlier Polish notation. What are the comparative benefits? Why did this become more popular?  — Preceding unsigned comment added by 131.78.3.130 (talk) 12:53, 5 April 2019 (UTC)
replies: text: We can not. I can tell you why this one is better or worse – but that would be only my opinion. Even if I base it on some facts, it would still be my 'original research', and Wikipedia may not present WP:OR. If you find WP:SOURCES, which are WP:RELIABLE and present such comparison, you can add (ar ask other editors to add) such section. --CiaPan (talk) 13:06, 5 April 2019 (UTC)
thread_title:  Compare with Polish Notation 

message: An editor has asked for a discussion to address the redirect Noitaton hsilop. Please participate in the redirect discussion if you wish to do so.  signed, Rosguill talk 18:51, 17 March 2020 (UTC)
thread_title:  "Noitaton hsilop" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]] 

message: An editor has identified a potential problem with the redirect :Noitaton hsilop esrever and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2022 September 17#Noitaton hsilop esrever until a consensus is reached, and readers of this page are welcome to contribute to the discussion.  CiaPan (talk) 16:26, 17 September 2022 (UTC)
thread_title:  "Noitaton hsilop esrever" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]] 

message: An editor has identified a potential problem with the redirect :Noitaton Hsilop Esrever and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2022 September 18#Noitaton Hsilop Esrever until a consensus is reached, and readers of this page are welcome to contribute to the discussion.  CiaPan (talk) 20:16, 18 September 2022 (UTC)
thread_title:  "Noitaton Hsilop Esrever" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]] 

message: An editor has identified a potential problem with the redirect :Noitaton Hsilop esrever and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2022 September 24#Noitaton Hsilop esrever until a consensus is reached, and readers of this page are welcome to contribute to the discussion.  CiaPan (talk) 11:01, 24 September 2022 (UTC)
thread_title:  "Noitaton Hsilop esrever" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]] 

message: An editor has identified a potential problem with the redirect :Zciweisakuł notation and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2022 October 4#Zciweisakul notation until a consensus is reached, and readers of this page are welcome to contribute to the discussion.  CiaPan (talk) 13:52, 4 October 2022 (UTC)
thread_title:  "Zciweisakuł notation" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]] 

message: An editor has identified a potential problem with the redirect :Zciweisakul notation and has thus listed it for discussion. This discussion will occur at Wikipedia:Redirects for discussion/Log/2022 October 4#Zciweisakul notation until a consensus is reached, and readers of this page are welcome to contribute to the discussion.  CiaPan (talk) 13:52, 4 October 2022 (UTC)
thread_title:  "Zciweisakul notation" listed at [[Wikipedia:Redirects for discussion|Redirects for discussion]]