![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||
|
I don't think the really long example showing how to convert infix notation to RPN really belongs. - Furrykef 15:12, 9 Sep 2004 (UTC)
Why is there always a space between the left bracket and letter, in the pre box? lysdexia 13:37, 5 Nov 2004 (UTC)
I added the step to handle function tokens in the infix->postfix algorithm. It was mentioned what to do when they are found on the stack, but with no mention of how/when they would be placed there. BryanMWoods 05:28, 14 September 2005 (UTC)
There's a contradiction. -- It was introduced before it was invented -- Which is right?
The algorithm (still) doesn't seem to handle functions properly. If an operator's left arguement is the result of a function call, the These must only be operators part of the last clause isn't true. If no one objects I'll add my fixes to the algorithm on the page. However, if I add my changes it may no longer strictly be Edsger Dijkstra's shunting yard algorithm. It might be. The "shunting" between the operand and operator stacks is still the core of the algorithm. Thoughts? -- BryanMWoods 07:27, 8 November 2005 (UTC)
yeah, sounds good!
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.
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)
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)
I agree too. I have to admit that having that on the same RPN page vas *very* useful to me 'cause i didn't know this efficient way to convert from one notation to the other. Anyway, as long as it is clearly marked this possibility (not just in a link at the end of the page), i'm cool with making a separate page. Danilo Roascio 11:42, 13 September 2006 (UTC)
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),
I was baffled by this example: (e.g. "/ 6 3" in Polish notation and "6 3 /" in reverse Polish both evaluating to 2, whereas "3 6 /" in reverse Polish notation would evaluate to ½)
Would not it be better to say that "6 3 /" is equal to 6 / 3 = 2 in the conventional postfix notation, but it would be 3 / 6 in true reverse Polish notation? Itman
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)
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)
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)
I've removed this paragraph:
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)
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)
I Second this. Yehoodig ( talk) 05:04, 18 February 2012 (UTC)
The postfix evaluator example does not work at all. Passing it "3 2 +", for example, returns 4 instead of 5. "3 2 + 7 1 * -" returns 6, not -2. "3 2 + 7 * 1 -" returns 0, not 34. However, is a code example really necessary anyway? Burbble 23:49, 25 September 2007 (UTC)
Would anybody object if I just deleted it then? 75.83.32.62 18:22, 30 September 2007 (UTC)
I really don't think the Python code (or any code, for that matter) belongs in the article. I'd like to remove it, but since it's been there for a while, it seems like a good idea to ask for others' input first. Dead Horsey ( talk) 05:20, 19 February 2010 (UTC)
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)
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)
What if you wanted to add 34 and 4? What would the RPN be then, 344+? —Preceding unsigned comment added by 138.23.202.6 ( talk) 17:05, 3 June 2009 (UTC)
This should be noted somewhere (obvious) in the main entry. Also rather than simple spaces, the example should be "3 [ent] 4 [ent] + [ent]" for clarity. —Preceding unsigned comment added by 138.162.0.44 ( talk) 00:28, 6 May 2011 (UTC)
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)
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)
No worries. There won't be a cultural reference section. 129.128.221.64 ( talk) 15:46, 7 October 2009 (UTC)
I just showed my gf that comic, then brought her to this article to explain why it's funny. She took one look at the example and said "thirtyfour plus?", which is the perfect example of why this notation is flawed. Logically, the operand makes the perfect delimiter. —Preceding unsigned comment added by 24.141.181.248 ( talk) 07:39, 8 October 2009 (UTC)
National Semiconductor also had calculator models that used RPN in the 70's. Halconen ( talk) 16:52, 11 November 2009 (UTC)
These included the Novus 650 Mathbox, 3500 Sliderule, 4510 Mathematician, 4515 Mathematician PRO/RG, 4520 Scientist, and 4525 Scientist PR, as well as the National Semiconductor 4615 and 4640. Normfromga ( talk) 01:10, 22 June 2023 (UTC)
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)
A lot of the entries in here are confusing at best and debatable at worst. For instance, "it is not possible to simply copy the expression from paper into the machine" -- this presumes the expression is given in some other notation, doesn't it? "Reverse Polish notation also reflects the way calculations are done on pen and paper" similarly makes undocumented and unclear assumptions about how calculations are done on paper. "Users must know the size of the stack" is simply untrue; what is true is that users who exhaust the stack will get incorrect answers, but I'll bet most buyers of HP calculators have no idea what the stack size is. I could go on, but my real point is that this seems to be a collection of observations various Wikipedia editors have made, which is not very Wikipedia-like, and I think readers would be better served by citations from sources. "The concept is easy to teach" is a debatable statement and probably not falsifiable; "According to Dijkstra, the concept is easy to teach --" assuming he did say so and an appropriate reference can be found -- "because..." would be nice and encyclopedic. -- Chronodm ( talk) 17:52, 5 October 2011 (UTC)
119~2\3\5\7\ would show 119/2, 119/3, 119/5 and 119/7, because the operator did not enable either stack lift or drop.
Add to the "Current implementations" section dc
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)
Under the "Practical implications" section, it is stated that RPN requires less keystrokes. Is this REALLY correct? Surely, including the keystroke to seperate numbers, 3 enter 4 enter 5 + + in RPN is actually 1 MORE keystroke then 3 + 4 + 5 =. MrZoolook ( talk) 12:08, 14 April 2014 (UTC)
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)
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)
RippleSax ( talk) 22:33, 11 December 2015 (UTC) ( talk)
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) ( talk)
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)
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)
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)
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)
It appears this algorithm is the same as the algorithm listed in the article for prefix evaluation, only in reversed order. This algorithm is completely wrong and should be changed. I suggest using a recursive algorithm.
revursive algorithm: token ← pop from token stack if token is an operator operand_2 ← result of recursively applying the algorithm operand_1 ← result of recusrively applying the algorithm result ← evaluate operator with operand_1 and operand_2 else result ← token
— Preceding unsigned comment added by 77.218.241.131 ( talk) 16:10, 19 January 2018 (UTC)
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)
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)
This often-used synonym name is more meaningful than the initialism "RPN" or the irrelevant adjective "Polish" (which is offensive to some), and should at least be mentioned in an encyclopedic article. Here are a few references: https://www.thefreedictionary.com/Zciweisakul+notation https://courses.cs.washington.edu/courses/cse373/06sp/handouts/lecture04.pdf https://www.cs.auckland.ac.nz/courses/compsci105ssc/archive/2007/lectures/lecture18.pdf https://www.planetmath.org/ReversePolishNotation https://www.xspdf.com/resolution/54685430.html https://dbpedia.org/page/Reverse_Polish_notation
Furthermore, the initialism "RPN" is ambiguous, e.g.: https://www.closingthegap.ca/nurses-do-you-know-the-difference-between-rn-rpn-and-np/ https://www.sciencedirect.com/topics/engineering/risk-priority-number https://www.psionline.com/platforms/rpnow/ http://rpnsales.com/ https://acronyms.thefreedictionary.com/RPN The last of these references has 28 entries for the meaning of "RPN". — Preceding unsigned comment added by Tripodics ( talk • contribs) 13:25, 13 April 2021 (UTC)
The term "Polish" is both silly and offensive, as it alludes to the ethnicity (not the nationalities) of the logician who developed the Prefix Notation -- the proper name for which should be "Łukasiewicz Notation". Granted, the even-sillier initialism "RPN" is far more popular, but that is no reason to hide the fact that some mathematicians do refer to "Postfix Notation" as "Zciweisakul Notation" (perhaps to avoid the offensive and inaccurate appellations). Nevertheless, I shall refrain from stating a reversion-war by again including correct and factual information in this incomplete Wikipedia article. Tripodics ( talk) 19:50, 18 April 2021 (UTC)
There is little or no reason to add his suggestion of the term "Zciweisakul Notation" in a Wikipedia article about Hamblin. However, many have followed his suggestion, and the lack of mention in the Hamlin' article is no reason to exclude that fact from THIS article. Tripodics ( talk) 19:59, 18 April 2021 (UTC)
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)
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)
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)
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)
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)
![]() | This edit request by an editor with a conflict of interest was declined. |
Robert1003 ( talk) 14:00, 25 February 2023 (UTC)
References
![]() | This article is rated C-class on Wikipedia's
content assessment scale. It is of interest to the following WikiProjects: | ||||||||||
|
I don't think the really long example showing how to convert infix notation to RPN really belongs. - Furrykef 15:12, 9 Sep 2004 (UTC)
Why is there always a space between the left bracket and letter, in the pre box? lysdexia 13:37, 5 Nov 2004 (UTC)
I added the step to handle function tokens in the infix->postfix algorithm. It was mentioned what to do when they are found on the stack, but with no mention of how/when they would be placed there. BryanMWoods 05:28, 14 September 2005 (UTC)
There's a contradiction. -- It was introduced before it was invented -- Which is right?
The algorithm (still) doesn't seem to handle functions properly. If an operator's left arguement is the result of a function call, the These must only be operators part of the last clause isn't true. If no one objects I'll add my fixes to the algorithm on the page. However, if I add my changes it may no longer strictly be Edsger Dijkstra's shunting yard algorithm. It might be. The "shunting" between the operand and operator stacks is still the core of the algorithm. Thoughts? -- BryanMWoods 07:27, 8 November 2005 (UTC)
yeah, sounds good!
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.
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)
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)
I agree too. I have to admit that having that on the same RPN page vas *very* useful to me 'cause i didn't know this efficient way to convert from one notation to the other. Anyway, as long as it is clearly marked this possibility (not just in a link at the end of the page), i'm cool with making a separate page. Danilo Roascio 11:42, 13 September 2006 (UTC)
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),
I was baffled by this example: (e.g. "/ 6 3" in Polish notation and "6 3 /" in reverse Polish both evaluating to 2, whereas "3 6 /" in reverse Polish notation would evaluate to ½)
Would not it be better to say that "6 3 /" is equal to 6 / 3 = 2 in the conventional postfix notation, but it would be 3 / 6 in true reverse Polish notation? Itman
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)
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)
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)
I've removed this paragraph:
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)
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)
I Second this. Yehoodig ( talk) 05:04, 18 February 2012 (UTC)
The postfix evaluator example does not work at all. Passing it "3 2 +", for example, returns 4 instead of 5. "3 2 + 7 1 * -" returns 6, not -2. "3 2 + 7 * 1 -" returns 0, not 34. However, is a code example really necessary anyway? Burbble 23:49, 25 September 2007 (UTC)
Would anybody object if I just deleted it then? 75.83.32.62 18:22, 30 September 2007 (UTC)
I really don't think the Python code (or any code, for that matter) belongs in the article. I'd like to remove it, but since it's been there for a while, it seems like a good idea to ask for others' input first. Dead Horsey ( talk) 05:20, 19 February 2010 (UTC)
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)
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)
What if you wanted to add 34 and 4? What would the RPN be then, 344+? —Preceding unsigned comment added by 138.23.202.6 ( talk) 17:05, 3 June 2009 (UTC)
This should be noted somewhere (obvious) in the main entry. Also rather than simple spaces, the example should be "3 [ent] 4 [ent] + [ent]" for clarity. —Preceding unsigned comment added by 138.162.0.44 ( talk) 00:28, 6 May 2011 (UTC)
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)
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)
No worries. There won't be a cultural reference section. 129.128.221.64 ( talk) 15:46, 7 October 2009 (UTC)
I just showed my gf that comic, then brought her to this article to explain why it's funny. She took one look at the example and said "thirtyfour plus?", which is the perfect example of why this notation is flawed. Logically, the operand makes the perfect delimiter. —Preceding unsigned comment added by 24.141.181.248 ( talk) 07:39, 8 October 2009 (UTC)
National Semiconductor also had calculator models that used RPN in the 70's. Halconen ( talk) 16:52, 11 November 2009 (UTC)
These included the Novus 650 Mathbox, 3500 Sliderule, 4510 Mathematician, 4515 Mathematician PRO/RG, 4520 Scientist, and 4525 Scientist PR, as well as the National Semiconductor 4615 and 4640. Normfromga ( talk) 01:10, 22 June 2023 (UTC)
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)
A lot of the entries in here are confusing at best and debatable at worst. For instance, "it is not possible to simply copy the expression from paper into the machine" -- this presumes the expression is given in some other notation, doesn't it? "Reverse Polish notation also reflects the way calculations are done on pen and paper" similarly makes undocumented and unclear assumptions about how calculations are done on paper. "Users must know the size of the stack" is simply untrue; what is true is that users who exhaust the stack will get incorrect answers, but I'll bet most buyers of HP calculators have no idea what the stack size is. I could go on, but my real point is that this seems to be a collection of observations various Wikipedia editors have made, which is not very Wikipedia-like, and I think readers would be better served by citations from sources. "The concept is easy to teach" is a debatable statement and probably not falsifiable; "According to Dijkstra, the concept is easy to teach --" assuming he did say so and an appropriate reference can be found -- "because..." would be nice and encyclopedic. -- Chronodm ( talk) 17:52, 5 October 2011 (UTC)
119~2\3\5\7\ would show 119/2, 119/3, 119/5 and 119/7, because the operator did not enable either stack lift or drop.
Add to the "Current implementations" section dc
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)
Under the "Practical implications" section, it is stated that RPN requires less keystrokes. Is this REALLY correct? Surely, including the keystroke to seperate numbers, 3 enter 4 enter 5 + + in RPN is actually 1 MORE keystroke then 3 + 4 + 5 =. MrZoolook ( talk) 12:08, 14 April 2014 (UTC)
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)
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)
RippleSax ( talk) 22:33, 11 December 2015 (UTC) ( talk)
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) ( talk)
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)
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)
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)
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)
It appears this algorithm is the same as the algorithm listed in the article for prefix evaluation, only in reversed order. This algorithm is completely wrong and should be changed. I suggest using a recursive algorithm.
revursive algorithm: token ← pop from token stack if token is an operator operand_2 ← result of recursively applying the algorithm operand_1 ← result of recusrively applying the algorithm result ← evaluate operator with operand_1 and operand_2 else result ← token
— Preceding unsigned comment added by 77.218.241.131 ( talk) 16:10, 19 January 2018 (UTC)
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)
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)
This often-used synonym name is more meaningful than the initialism "RPN" or the irrelevant adjective "Polish" (which is offensive to some), and should at least be mentioned in an encyclopedic article. Here are a few references: https://www.thefreedictionary.com/Zciweisakul+notation https://courses.cs.washington.edu/courses/cse373/06sp/handouts/lecture04.pdf https://www.cs.auckland.ac.nz/courses/compsci105ssc/archive/2007/lectures/lecture18.pdf https://www.planetmath.org/ReversePolishNotation https://www.xspdf.com/resolution/54685430.html https://dbpedia.org/page/Reverse_Polish_notation
Furthermore, the initialism "RPN" is ambiguous, e.g.: https://www.closingthegap.ca/nurses-do-you-know-the-difference-between-rn-rpn-and-np/ https://www.sciencedirect.com/topics/engineering/risk-priority-number https://www.psionline.com/platforms/rpnow/ http://rpnsales.com/ https://acronyms.thefreedictionary.com/RPN The last of these references has 28 entries for the meaning of "RPN". — Preceding unsigned comment added by Tripodics ( talk • contribs) 13:25, 13 April 2021 (UTC)
The term "Polish" is both silly and offensive, as it alludes to the ethnicity (not the nationalities) of the logician who developed the Prefix Notation -- the proper name for which should be "Łukasiewicz Notation". Granted, the even-sillier initialism "RPN" is far more popular, but that is no reason to hide the fact that some mathematicians do refer to "Postfix Notation" as "Zciweisakul Notation" (perhaps to avoid the offensive and inaccurate appellations). Nevertheless, I shall refrain from stating a reversion-war by again including correct and factual information in this incomplete Wikipedia article. Tripodics ( talk) 19:50, 18 April 2021 (UTC)
There is little or no reason to add his suggestion of the term "Zciweisakul Notation" in a Wikipedia article about Hamblin. However, many have followed his suggestion, and the lack of mention in the Hamlin' article is no reason to exclude that fact from THIS article. Tripodics ( talk) 19:59, 18 April 2021 (UTC)
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)
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)
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)
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)
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)
![]() | This edit request by an editor with a conflict of interest was declined. |
Robert1003 ( talk) 14:00, 25 February 2023 (UTC)
References