6 * 35 + 8 – (25 / 5)
1)How many operators and operands are in equation?
2)Is parenthesis considered as operator?
3)Inside the parenthesis operator and operand is considered?
Related
This question already has an answer here:
Operator precedence of "unary minus" (-) and exponentiation (^) outside vs. inside function
(1 answer)
Closed 8 months ago.
R seems pretty comfortable with computing the odd root of a negative number
-0.2^(1/3) # returns a good number
# [1] -0.5848035
but something weird happens if you raise a vector to the 1/3.
c(-0.2, 1)^(1/3) # returns an NA for the first element
# [1] NaN 1
I'm interested in an answer that explains what is happening differently to the vector than to the negative value when provided as a numeric scalar.
I'm not looking for a workaround e.g. function(x){sign(x)*(abs(x))^(1/3)}. This answer seems to point in a good direction... how does the "^" operator think differently about vectors and scalars?
I'm not looking for a workaround e.g. function(x) {sign(x) * (abs(x)) ^ (1/3)}.
I'm interested in an answer that explains what is happening differently to the vector than to the negative value when provided as a numeric scalar.
how does the ^ operator think differently about vectors and scalars?
You seem to believe that c(-0.2, 1)^(1/3) translates to c(-0.2^(1/3), 1^(1/3)). This is incorrect. Operator ^ is actually a function, that is, (a) ^ (b) is as same as "^"(a, b). Therefore, the correct interpretation goes as follows:
c(-0.2, 1)^(1/3)
=> "^"(c(-0.2, 1), 1/3)
=> c( "^"(-0.2, 1/3), "^"(1, 1/3) )
=> c( (-0.2)^(1/3), (1)^(1/3) )
=> c( NaN, 1 )
Now, why doesn't -0.2^(1/3) give NaN? Because ^ has higher operation precedence than +, -, * and /. So as it is written, it really implies -(0.2^(1/3)) instead of (-0.2)^(1/3).
The lesson is that, to avoid buggy code, write your code as (a) ^ (b) instead of just a ^ b.
Additional Remark:
I often compare ^ and : when teaching R to my students, because they have different behaviors. But they all show the importance of protecting operands with brackets.
(-1):2
#[1] -1 0 1 2
-1:2
#[1] -1 0 1 2
-(1:2)
#[1] -1 -2
2*3:10
#[1] 6 8 10 12 14 16 18 20
(2*3):10
#[1] 6 7 8 9 10
2*(3:10)
#[1] 6 8 10 12 14 16 18 20
See ?Syntax for details of operator precedence.
I typed the following in Julia's REPL:
julia> 6÷2(1+2)
1
julia> 6÷2*(1+2)
9
Why are the different results output?
Presh Talwalkar says 9 is correct in the movie
6÷2(1+2) = ? Mathematician Explains The Correct Answer - YouTube
YouTube notwithstanding, there is no correct answer. Which answer you get depends on what precedence convention you use to interpret the problem. Many of these viral "riddles" that go around periodically are contentious precisely because they are intentionally ambiguous. Not a math puzzle really, it's just a parsing problem. It's no deeper than someone saying a sentence with two interpretations. What do you do in that case in real life? You just ask which one they meant. This is no different. For this very reason, the ÷ symbol isn't often used in real mathematical notation—fraction notation is used instead, which clearly disambiguates this as either:
6
- (1 + 2) = 9
2
or as
6
--------- = 1
2 (1 + 2)
Regarding Julia specifically, this precedence behavior is documented here:
https://docs.julialang.org/en/v1/manual/integers-and-floating-point-numbers/#man-numeric-literal-coefficients
Specifically:
The precedence of numeric literal coefficients is slightly lower than that of unary operators such as negation. So -2x is parsed as (-2) * x and √2x is parsed as (√2) * x. However, numeric literal coefficients parse similarly to unary operators when combined with exponentiation. For example 2^3x is parsed as 2^(3x), and 2x^3 is parsed as 2*(x^3).
and the note:
The precedence of numeric literal coefficients used for implicit multiplication is higher than other binary operators such as multiplication (*), and division (/, \, and //). This means, for example, that 1 / 2im equals -0.5im and 6 // 2(2 + 1) equals 1 // 1.
Given the infix expression -190 + 20, what would the correct result look like as RPN?
-190 + 20 == -190 20 + ?
or..
-190 + 20 == 190 - 20 + ?
Are the rules for unary operators (negative) the same as other operators, but just a right associative property, and higher priority?
Similarly an expression like:
-(9 + 9)
Would be?
-(9 + 9) = 9 - 9 +?
In a typical RPN language, you can't have the same token - interpreted as either a unary or binary operator depending on context, because there is no context. It has to always be one or the other. So commonly - is kept as the binary subtraction operator, and some other token is used for the unary negation operator. Forth, for instance, called it NEGATE. Thus in Forth, your -190 + 20 could be coded as 190 NEGATE 20 +, and your -(9+9) as 9 9 + NEGATE.
Forth could also parse negative numbers, so your -190 + 20 could also be coded -190 20 +. However the - is not an operator in this instance, but merely part of the single token -190. The only operator being used in this example is +.
If you write 190 - 20 + in a typical RPN language, you will get a stack underflow (or else whatever happened to be on the stack, minus 190, plus 20) since - is unconditionally interpreted as the binary operator.
RPN has no concept of precedence nor associativity - those serve to resolve ambiguity in the evaluation of expressions, and RPN has no such ambiguity in the first place.
I am trying to extract values from a vector using numeric vectors expressed in two seemingly equivalent ways:
x <- c(1,2,3)
x[2:3]
# [1] 2 3
x[1+1:3]
# [1] 2 3 NA
I am confused why the expression x[2:3] produces a result different from x[1+1:3] -- the second includes an NA value at the end. What am I missing?
Because the operator : has precedence over + so 1+1:3 is really 1+(1:3) (i. e. 2:4) and not 2:3. Thus, to change the order of execution as defined operator precedence, use parentheses ()
You can see the order of precedence of operators in the help file ?Syntax. Here is the relevant part:
The following unary and binary operators are defined. They are listed in precedence groups, from highest to lowest.
:: ::: access variables in a namespace
$ # component / slot extraction
[ [[ indexing
^ exponentiation (right to left)
- + unary minus and plus
: sequence operator
%any% special operators (including %% and %/%)
* / multiply, divide
+ - (binary) add, subtract
Using boolean algebra (not a specific language implementation), can we evaluate 1 ^ 1 + 1 (or 1 XOR 1 OR 1) unambiguously?
I can derive two evaluations:
[I]: (1 ^ 1) + 1 = 0 + 1 = 1
[II]: 1 ^ (1 + 1) = 1 ^ 1 = 0
Perhaps there's some stated order of operations, or of a left-to-right evaluation? Or is this not defined in Boolean algebra?
We can use the rules of boolean algebra to attempt to evaluate the expression 1 XOR 1 OR 1.
Now:
XOR is derived from OR such that A XOR B = (¬A AND B) OR (¬B AND A);
Associativity tells us that A OR (B OR C) = (A OR B) OR C;
Associativity also tells us that A AND (B AND C) = (A AND B) AND C
So, taking either of the possible interpretations of evaluation order:
(1 XOR 1) OR 1 1 XOR (1 OR 1)
Even though we have no left-to-right "evaluation order" defined, these rules are all we need to show that the two possible interpretations are not equivalent:
= (¬1 AND 1) OR (¬1 AND 1) OR 1 = (¬1 AND (1 OR 1)) OR (¬(1 OR 1) AND 1)
= (0 AND 1) OR (0 AND 1) OR 1 = (0 AND 1) OR (0 AND 1)
= 0 OR 0 OR 1 = 0 OR 0
= 1 = 0
Unless I'm forgetting some crucially pertinent axiom, I've confirmed that you need more context to evaluate the given expression.
(And, of course, examining the expression A XOR B OR C ∀A,B,C is of course substantially more tricky! But if the expression is ambiguous for just one value of all three inputs, then why bother checking for any others?)
This context is usually provided in language-specific evaluation-order rules. C-type languages give XOR a low precedence (something Richie came to dislike); by contrast, mathematical convention dictates a left-to-right associativity where no other axiom can be applied and an ambiguity is otherwise present.
So, basically, since we're ignoring language-specific rules, you'd probably go with [I].
Most languages would do XOR then OR; experienced coders will put parentheses in anyway just to make the intent clear.
Many more modern languages do what's called fast- or short-circuit- evaluation, so 0 & ? is always 0, so ? will not be evaluated; same with 1 + ?.
I don't think there is a generally agreed upon order of precedence with logical operators. The evaluation would be entirely specific to a language.
In c# for instance, the Operator precedence for bitwise operators is:
AND
XOR
OR
But this might be different for another language. If the precedence is the same, then the operations are executed from left to right. There is no logical XOR operator, but you can use NOT EQUAL (!=) instead.