Talk:Shunting yard algorithm

message: --78.50.237.77 (talk) 07:40, 10 May 2012 (UTC)
thread_title: Early discussions

message: Hello, I have just implemented this algorithm and I believe that the latest corrections (by anonymous users) to the detailed description might be wrong.  I believe it should read
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 (lower precedence) or equal to that of o2, or
 
o1 is right-associative and its precedence is less than (lower precedence) that of o2,
Earlier versions of this page seem to have had it this way originally
Also, ^2^3 in infix notation means ^8 by my reckoning, so the final answer I get for the complex example 3+4*2/(1−5)^2^3 is 3.0001220703125
Mike mueller nz 11:48, 4 April 2007 (UTC)
thread_title:  Operator precedence?? 

message: Does this algorithm work with unary minus "-" ( -x + x = 0 ) ?
If so, are these fundamental properties or conventions satisfied? :
a-b = a+(-b)
-a^b = -(a^b)
a/-b = a/(-b)
a^-b = a^(-b)
a/-b^c = a/-(b^c)
a^-b^c = a^-(b^c)
Thanks.
: yes but priorities must be such that 
*  binary_on_stack < minus (=> pospounding output of binary_on_stack, so minus goes first) 
*  and minus_on_stack < binary ( binary goes first ) 
*  ...
edit: basically you answered yourself
ca1 (talk) 01:20, 11 May 2008 (UTC)
thread_title:  unary minus "-" 

message: something like that will parse ok. should not there be mentioned that input has to be correct infix? ca1 (talk) 01:03, 11 May 2008 (UTC)
thread_title:  a a + + c 

message: The complex example section has these two statements:
* "^ has higher precedence than /"
* "^ is evaluated right-to-left"
Neither of these statements are true, at least in most programming languages I can think of:
http://en.wikipedia.org/wiki/Operators_in_C_and_C%2B%2B#Operator_precedence
Treating bitwise XOR like C++ should produce this final RPN output, presuming I didn't screw up my test program:
  3 4 2 * 1 5 - / + 2 ^ 3 ^
The current revision shoves "^ ^ / +" to the end of the output. Can someone verify that my assertion (and work!) are correct?
155.229.108.58 (talk) 21:32, 23 February 2009 (UTC)
replies: text: Thats because its not a bitwise XOR.  Its a pow function.  2 ^ 3 is equivalent to pow(2, 3) 70.15.250.196 (talk) 04:39, 5 April 2015 (UTC)
thread_title:  Bitwise XOR operator in example is incorrect? 

message: The operator '^' in this case isn't the bitwise XOR operator as in C++ but rather the exponential operator, so '^' is right-associative and has greater precedence than '/' in this example. Nevertheless, this could be explicitly stated in the article to avoid such confusion.  —Preceding unsigned comment added by 190.232.14.227 (talk) 21:21, 6 March 2009 (UTC)
thread_title:  Exponential operator 

message: I just took a look at the C++ example code, and it is shocking.
Why on earth are enums not being used in place of those magic numbers? I would go ahead and change it myself but I assume there's a reason behind not using enums.
Can someone clarify this? 124.168.95.207 (talk) 04:43, 18 July 2010 (UTC)
replies: text: And what's the use of a huge block of code in the middle of an article?  — Preceding unsigned comment added by 77.228.71.21 (talk) 09:09, 19 June 2013 (UTC)
thread_title:  C++ example code 

message: The .svg graphic is confusing from step d) to step e).  The transition between earlier steps only moves one item at a time.  The transition from step d) to step e) moves three items at once.  It's unclear as to which '+' was moved to the output and which plus is moved to the operand stack for that transition.  Was the plus on the operand stack moved to the output and the plus at the input moved to the operand stack?  Or, was the plus from the input moved to the output?  If someone doesn't understand the algorithm, they won't know that the plus at the output is from the operand stack and the plus now on the operand stack was from the input.  They won't recognize that both pluses were moved and one of them is now in the same place that the other one was.  They'll think that the plus from the input was moved to the output.  This can be resolved by moving fewer items per state transition, or by changing the second plus to a minus.  —Preceding unsigned comment added by 98.243.108.232 (talk) 18:12, 21 December 2010 (UTC)
thread_title:  .svg is confusing from step d) to step e) 

message: The following should be added to the C example after the #include statements so it compiles in ANSI C:
  #define bool int
  #define false 0
  #define true 1
These terms are not supported.  —Preceding unsigned comment added by 71.220.68.202 (talk) 03:54, 10 January 2011 (UTC)
replies: text: I see that change made it in the article. Another option is to include the c99 header <stdbool.h> which save two lines of code but break ANSI c89 compatibility. R4p70r (talk) 06:02, 18 February 2011 (UTC)
thread_title:  C example 

message: The article states that the shunting-yard algorithm is a method for parsing mathematical equations. I'm not too versed in mathematics but it seems that the word "equations" imply the equality between two expressions. The thing is I don't see an equal signs in the infix input to the algorithm. Is it correct to say that equations are being parsed in this context? R4p70r (talk) 05:01, 18 February 2011 (UTC)
replies: text: Indeed, it is probably not strictly correct. I would use the term "expressions". C3lticmatt (talk) 16:25, 28 March 2011 (UTC)
thread_title:  Parsing mathematical equations 

message: I can make no sense of the sentence explaining prefix notation:
The shunting yard algorithm can also be applied to produce prefix notation (also known as polish notation). To do this one would simply start from the beginning of a string of tokens to be parsed and work backwards, and then reversing the output queue (therefore making the output queue an output stack).
Presumably the participle 'reversing' should be 'reverse'. But then how do you start at the beginning of a string and work backwards, without falling off the beginning of the string? Marinheiro (talk) 10:16, 8 December 2011 (UTC)
thread_title:  Prefix notation 

message: Python implementation is not correct. I opened a bug with an original author: https://github.com/ekg/shuntingyard/issues/1  — Preceding unsigned comment added by Yuriyzubarev (talk • contribs) 19:46, 23 March 2012 (UTC)
thread_title:  Python external link 

message: It seems to be an error, because it does not work for the case 
sin(max(2,3)/5)
If the current token is an operator o1, then I think when we look on top of the stack not just for other operators, but functions as well. And if it is a function we should pop it onto the output queue, because function calls have a very high precedence.  Bob Ueland (talk) 21:17, 28 January 2016 (UTC)
thread_title:  A bug in the Algorithm description. 

message: Hello fellow Wikipedians,
I have just added archive links to  on Shunting-yard algorithm. Please take a moment to review my edit. If necessary, add  after the link to keep me from modifying it. Alternatively, you can add  to keep me off the page altogether. I made the following changes:
*Added archive http://web.archive.org/web/20110718214204/http://en.literateprograms.org/Shunting_yard_algorithm_(C) to http://en.literateprograms.org/Shunting_yard_algorithm_(C)
When you have finished reviewing my changes, please set the checked parameter below to true or failed to let others know (documentation at ).
Cheers.—cyberbot IITalk to my owner:Online 04:48, 3 March 2016 (UTC)
thread_title:  External links modified 

message: In the algorithm description under "The algorithm in detail", at the first "while", it is not clear whether "and the operator is left associative" refers to the operator on top of the stack or the operator found from the token. I assumed the former when implementing it, but ran into issues, which the latter approach happened to solve.
Could anybody clarify on this ambiguous statement and perhaps correct it?
103.9.76.196 (talk) 22:09, 15 October 2017 (UTC)
replies: text: The algorithm was reworded in June 2017. See the version at 12 April 2017 which has more detail and a relevant example. It's a long time since I looked the algorithm so I don't want to offer an opinion on which operator is intended at the moment. Johnuniq (talk) 03:31, 16 October 2017 (UTC)
thread_title:  Shunting yard algorithm description ambiguous 

message: It says: "The shunting yard algorithm can also be applied to produce prefix notation (also known as Polish notation). To do this one would simply start from the end of a string of tokens to be parsed and work backwards, reverse the output queue (therefore making the output queue an output stack), and flip the left and right parenthesis behavior (remembering that the now-left parenthesis behavior should pop until it finds a now-right parenthesis)."
Correct me if I'm wrong, but I don't think this is actually sufficient to produce prefix notation with the same semantics. This is because associativity would be flipped if you just used this method. As in, if you have 2*3/4 that would be 23*4/ in postfix notation assuming left-associativity ((2*3)/4). However, using the method stated here to get prefix notation, I get *2/34 (2*(3/4)), i.e. associativity has been switched! SorteKanin (talk) 18:38, 17 February 2018 (UTC)
thread_title:  Slight error in algorithm description 

message: I am new to Wikipedia.
I submitted an implementation of the algorithm fully working. I implemented the code based on the concept in this page and it was very straight forward. A few adjustments were done indeed for the unary sign (to answer question above). 
The code actually uses OOP to discover the operands and functions dynamically and builds all the required data structures on demand. I think could help many people that need to implement a similar one, reason why I placed it in the external reference. With the parser and the dynamic structures created, I also built a calculator. The code was written for Pharo Smalltalk. I used the GitHub URL which allows anybody to download the code.  — Preceding unsigned comment added by Grpistoia (talk • contribs) 04:34, 24 January 2021 (UTC)
thread_title:  Implementation example in Pharo 

message: I think that there is a problem in the while cycle where we verify the operator stack before pop another one onto, instead of:
while ((there is a operator at the top of the operator stack)
               or (there is an operator at the top of the operator stack with greater precedence)
               or (the operator at the top of the operator stack has equal precedence and the token is left associative))
              and (the operator at the top of the operator stack is not a left parenthesis):
            pop operators from the operator stack onto the output queue.
we have to fix with something like:
              
        while ((there is a operator at the top of the operator stack)
               AND ((the operator at the top of the operator stack has greater precedence)
               or (the operator at the top of the operator stack has equal precedence and the token is left associative)))
              and (the operator at the top of the operator stack is not a left parenthesis):
            pop operators from the operator stack onto the output queue.
GPaolin (talk) 07:20, 13 May 2020 (UTC)
thread_title:  Algorithm problem 

message: The link given in the first paragraph for "Mathematisch Centrum report MR 34/61" points to a good enough source but I believe a better one exists here; the years of publishing do differ, however. Chorl (talk) 14:36, 26 August 2023 (UTC)
thread_title:  Better reference for Dijkstra's original?