In a expression like "10 - 3 - 2", it's easy to understand why - and + operators are left associative. To match mathematical convention and have 5 instead of 9 as the result. As I understood it, associativity means the order when some operators have the same precedence level.
But what relevance does this have with unary operators? I don't get why an unary operator has associativity.
Note: The question is about general programming, but if you have to answer in a language dependent manner C is preferred.
**Arithmetic Operators** (Left-to-Right)
+ Additive operator (a + b)
- Subtraction operator (a - b)
* Multiplication operator (a * b)
/ Division operator (a / b)
% Remainder operator (a % b)
**Unary operators** (Right-to-Left)
+ Unary plus operator; indicates positive value (numbers are positive without this, however)
- Unary minus operator; negates an expression
++ Increment operator; increments a value by 1
-- Decrement operator; decrements a value by 1
! Logical complement operator; inverts the value of a boolean
But when we consider unary for example:
a = +1
a= -1
a++
a-- etc
What you mentioned here with 10 - 3 - 2 will not be taken into unary operation.
So the operation will be Left-to-Right. Therefore:
10 - 3 equals 7 then
7 - 2 equals 5
Not as given below (Arithmetic operators always Left-to-Right not Right-to-Left)
3 - 2 = 1 then
10 - 1 = 9 This is absolutely wrong.
For further details, please check the below references:
Precedence and Associativity
Assignment, Arithmetic, and Unary Operators (I'm not much in touch with the C language. But operators are common.)
Unary operators don't have associativity, really. At least, not as individual operators. As you say, it's impossible for a unary operator to compete with another instance of itself for the same operand; that can only happen with a binary operator.
On the other hand, the grammatical definition of associativity doesn't just apply between two identical operators. It applies between two operators of the same class. For example, + and - associate mutually, since they both have the same precedence.
Postfix operators including, for example, array subscription and function application) normally associate more tightly than any other operator, including prefix operators. We could annotate that by putting postfix operators in a higher precedence level, or we could annotate it by putting prefix and postfix operators in the same precedence level, and then saying that that precedence level associates to the right.
Both of those descriptions would explain why *f() means "dereference the result of calling f" —*(f())— and not "call the function referenced by what f points at" —(*f)().
Personally, I find it more intuitive to put postfix operators in a different precedence level than prefix operators, and prefix operators in their own precedence levels as well. But the original precedence declaration syntax for yacc did not provide a declaration for precedence levels without associativity. (%nonassoc is different; it prevents chaining, which actually modifies the grammar.) So you had to declare unary operators as %left or %right. Of those two choices, %right makes more sense, because postfix operators (usually) associate more strongly than prefix operators. So that's the usual style. But it's really not very clear.
Bison does allow you to declare a precedence level without associativity, using the %precedence declaration. That's handy for unary operators. But many other yacc-based parser generators do not provide this feature, so you'll still often see unary operators declared with %right.
Related
I am trying to write an algorithm for presenting the below mathematical expression in a binary tree in order to present the post fixed and prefixed expression.
I know the precedence levels of common used operators, and i know how to deal with normal mathematical expressions, but i am not familiar with the use of inequalities like < >= , add for that the use of AND.
any help will be appreciated
Operator precedence usually goes
arithmetic > equality > logical
so the < and >= would evaluate before the AND.
Treat them like normal arithmetic operators when building the parse tree but give equality operators lower precendence than arithmetic, and logical lower than that.
for example check the java operator precendence
How can I realize/understand what is the preferential order/precedence of operators while converting infix notation to postfix notation :
" * ", " / ", " + ", " - ", " ^ ", " ) ", " ( ".
I understand that one can just look at an algorithm for this and solve this but I don't want to do that. What should be my thought process?
Operator precedence is a convention and property of a formal infix language to indicate which operations should evaluate first. A higher precedence operation means that it should operate before lower precedence operations.
Grouping parentheses are not part of the operator precedence. (Note that other kinds of parentheses such as function call parentheses may be however I am assuming you do not refer to those here) They are used to explicitly indicate the order of operations. Parentheses are only useful to indicate an order of operations in infix notation. The purpose of the operator precedence convention in a given language is to avoid using parentheses in most case. So, for example, if I want to multiply 4 by 5 and then add 7 to the result, I can write:
4*5+7
This is valid under normal arithmetic operator precedence rules because multiplication ('*') has higher precedence than addition ('+'). But if I want to add 3 and 4 and then multiply this result by 8, I need to write:
(3+4)*8
In this case I want the order of operations to be different than the normal order of "higher precedence operations first." In other words, parenthesis are only necessary when we are using infix notation and want operations to execute in an order other than precedence-order.
In standard arithmetic, exponentiation ("^") has highest precedence. Next is multiplication and division (equal precedence) and finally addition and subtraction. Therefore, an infix expression written using these operators without parenthesis will evaluate all exponentiation first, then all multiplications and divisions (in left to right order) and finally all additions and subtractions, again in left to right order.
If you want to infer the operator precedence of an unknown language, you would need to look at the places where parentheses are and are not used. Since it is valid to use parentheses everywhere even when unnecessary, this is only a heuristic. For the examples above, I can write:
((4*5)+7)
And this gives no hint about operator precedence. It is because every binary operator in this case has parentheses, and therefore at least one of the two sets is redundant assuming the precedence of addition and multiplication are not the same.
Similarly, looking at the next example:
(3+4)*8
since parentheses were used around the addition but not the multiplication, we can infer that probably in this language addition has lower precedence than multiplication. Otherwise, the parenthesis would be redundant. So look for the pattern where parentheses are and are not used to try to figure out operator precedence in unknown languages. It is more common to assume a certain precedence level based on the formal specification of the language under consideration. Most formal languages have an operator precedence chart for the infix form to avoid this ambiguity.
We never need parentheses in prefix or postfix languages because the order of terms and operators already makes the order of evaluation explicit. Therefore this issue is really an infix-language-specific problem.
If parentheses are balanced properly you can always find a parenthesis-free subexpression, which reduces the problem to that case.
Now just ask yourself, according to precedence rules, which operation in such an expression should be performed first?
Generally, programs which evaluate an infix mathematical expression use some variation of the Shunting Yard Algorithm to first translate the expression into Reverse Polish Notation, and then evaluate the Reverse Polish Notation to get a single final value.
My question is, is there some well-known algorithm that bypasses the INFIX -> RPN step, and just evaluates the initial infix expression in place, using some kind of recursive descent parsing?
Presumably, it might be useful when writing compilers or parsers to translate INFIX -> RPN. The RPN is sort of a "compiled form" of the expression (an AST), which can be more easily evaluated by a computer using a simple output stack. But, if you're just simply writing code that immediately translates an infix expression into a numeric output value, you might not have any use for caching the intermediate RPN form.
So, is there any well-known algorithm for parsing infix expressions WITHOUT first converting to RPN? Or is converting to RPN generally more efficient than any other approach?
You can easily modify the shunting-yard algorithm to immediately evaluate the expression as you go rather than building up an RPN representation. Specifically, whenever you would normally pop off an operator and two operands from the stacks, rather than appending those tokens to the output, instead just evaluate the expression and push the result back onto the operand stack. Finally, at the very end, evaluate the expression implied by the operator and operand stacks by popping off two operands, popping an operator, computing the result, and pushing it back onto the stack.
For example, to evaluate 3 * 4 + 2, you'd do the following:
Process 3:
Operators
Operands 3
Process *:
Operators *
Operands 3
Process 4:
Operators *
Operands 3 4
Process +:
Operators +
Operands 12
Process 2:
Operators +
Operands 12 2
End of input:
Operators
Operands 14
Hope this helps!
I saw the & sign recently in Ruby and after searching for a while I can't find an explanation online.
As in:
62 & 15 #=> 14
This Fixnum#& method works as a bitwise and (&) operator in Ruby.
Bitwise AND operator &
The & (bitwise AND) operator compares each bit of its first operand to the corresponding bit of the second operand. If both bits are 1's, the corresponding bit of the result is set to 1. Otherwise, it sets the corresponding result bit to 0.
Both operands must have an integral or enumeration type. The usual arithmetic conversions on each operand are performed. The result has the same type as the converted operands.
Because the bitwise AND operator has both associative and commutative properties, the compiler can rearrange the operands in an expression that contains more than one bitwise AND operator.
The following example shows the values of a, b, and the result of a & b represented as 16-bit binary numbers:
bit pattern of a 0000000001011100
bit pattern of b 0000000000101110
bit pattern of a & b 0000000000001100
Note: The bitwise AND (&) should not be confused with the logical AND. (&&) operator. For example,
1 & 4 evaluates to 0
while
1 && 4 evaluates to true
& is a bitwise and.
See also:
Ruby operators at Tutorialspoint
I am studying on Ivan Bratko book: "Programming for artificial intelligence"
Now I am studying the operators and I have some doubts about it, on the book I can read the following thing:
So the precedence of the operators decides what is the correct interpretation of expressions. For example, the expression a + b*c can be, in principle, understood either as:
1. +(a, *(b,c))
or as:
2. *(+(a,b), c)
And now I havde the first doubt: "what it means this thing? it seems me very strage because these two expressions give different three and different result !!!
For example if I have: a=2, b=3, c=4
The result of the first one is 14 and the result of the second one is 20 so there are different: different thress means different order of operator execution that means different result !!!
So I think that (using the usual priority of arithmetic operator: execute first the multiplications and after the sums) the correct expression is the first one and the second one is wrong.
Is it correct?
Continuing to read the book I can read also:
The general rule is that operator with the highest precedence is the principal functor of the term. If expression containing + and * are to be understood according to our normal convention, then + have a higher precedence then * operator
and now I have the second doubt: as I said, in normal convention of arithmetic I execute first the multiplications and after the sums,so in my opinion is the * operator that have the precedence and not +
What I am missing about it? Why on the book say that + has higher precedence then *?
"The principal functor of the term" means the last operation to be executed, or the outermost one in prefix notation. This definition is the inverse of yours, thus the contradiction.
So the precendence of the operators decides what is the correct interpretation of expressions. For example, the expression a + b*c can be, in principle, understood either as:
+(a, *(b,c))
or as:
*(+(a,b), c)
It says that without precedence, those are 2 possible ways to interpret the expression (and different way of parsing the expression will give different result). You only know to group a + (b * c) when you know that * should be executed before +. (I avoid explaining with precedence here, since it is confusing as pointed out below).
+ and * are just symbols, and it just happens that they are used as operator with some defined precedence. Generally speaking, you can define anything to be an operator, and give it a precedence.
The general rule is that operator with the highest precedence is the principal functor of the term. If expression containing + and * are to be understood according to our normal convention, then + have a higher precedence than * operator
The definition of precedence in English is "The condition of being considered more important than someone or something else; priority in importance, order, or rank". As long as something has to happen before some other thing, we have a precedence.
In C, operator precedence is the order of binding in an expression. Higher precedence operator in C will get executed before lower precedence operators.
In Prolog, the precedence is the order of getting the functor, which is the reverse of the case of C operator's order of binding. Higher precedence operator will appear earlier when we analyze the expression with =...