My question is where does the piping operator of magrittr package %>% come in the order of operations?
I have a problem simmilar to the following:
set.seed(10)
df <- data.frame(a=rnorm(3),b=rnorm(3),c=rnorm(3))
df/rowSums(df) %>% round(.,3)
This results in the following non rounded figures:
a b c
1 -0.0121966 0.119878 0.8922125
To get the rounded figures I need to put df/rowSums(df) between brackets.
I experimented with the +,-,*,/ and ^ and from the results I found the order of operation is as follow:
Exponents
Piping
Multiplication and division
Addition and subtraction
Is that right or there is something wrong with my understanding of the piping operator?
The help page you are looking for is ?Syntax. (Don't feel bad for not being able to find this, it took me about six guesses at search keywords.) I'm going to quote its entire operator precedence table here:
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
‘< > <= >= == !=’ ordering and comparison
‘!’ negation
‘& &&’ and
‘| ||’ or
‘~’ as in formulae
‘-> ->>’ rightwards assignment
‘<- <<-’ assignment (right to left)
‘=’ assignment (right to left)
‘?’ help (unary and binary)
So magrittr's pipe operators, like all the operators of the form %whatever%, do indeed have precedence greater than multiply and divide but lower than exponentiation, and this is guaranteed by the language specification.
Personally, I don't see the value in these operators. Why not just write
round(df/rowSums(df), 3)
which has the evaluation order you want, and is (IMNSHO) easier to read as well?
Related
A simple math question requiring the use of BODMAS/PEMDAS, that is, 6/2(1+2) = ?, has gone viral on Twitter, leading to confusion as to whether the answer is 1 or 9. There are two schools of thought that the 'O' in BODMAS stands for Of instead of the Orders argument. To some, the 'Of' operator means implicit multiplication. Implicit multiplication as in a number multiplied by a bracket seems to take precedence in traditional math over explicit multiplication using the times (X or *) symbol.
How can I implement this implicit multiplication symbol "of" in R? Using the * symbol would convert the 'Of' symbol to an explicit times symbol and might not always lead to the right answer. For example, in R, 6/2*(1+2) = 9 but traditional BODMAS will result in a 1.
As an example of what I'm after, suppose that I want every multiple of 3 in the list of numbers from 1 to 100. The easier way that I know of doing this is as follows:
all<-1:100
mod3<-all[all%%3==0]
Is there a way to do this without the first line? It seems silly that I have to declare a list (and therefore give it a name) before I can subset it. I could call the subset function, but the array notation in my second line comes so naturally that it would be a shame to not use it. In an ideal world, I'd call something like 1:100[1:100%%3==0] but that obviously gives errors. Referring only to things that are built-in to R, what are my options?
We could wrap within brackets to make it a self-contained block as there is precedence for different operators
(1:100)[(1:100)%%3==0]
If the check the ?Syntax, the different operator precedence are given
#:: ::: 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
#...
In the above case, the expression within the [] works as expected because the : is above on the precedence wrt to %%. But, it is the one outside having an issue because [ is higher when compared to :
The working behind the solution or arithmetic equation like 2+3-4*6/3-2^3/4+7-6*2**3/2+2-4+5 in R programming ? The logic behind the solving of the equation.
In order to know how R evaluates an arithmetic expression like the one in your question, you need to understand the operator precedence in R. Operator precedence, also known as the order of operations, is explained on R's Syntax help page. Type ?Syntax at any R prompt and you'll see:
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
‘< > <= >= == !=’ ordering and comparison
‘!’ negation
‘& &&’ and
‘| ||’ or
‘~’ as in formulae
‘-> ->>’ rightwards assignment
‘<- <<-’ assignment (right to left)
‘=’ assignment (right to left)
‘?’ help (unary and binary)
This tells you that ^ is evaluated before * and \, which in turn are evaluated before + and -, and so on.
I have an ifElse Statement which can be of the following two types
a) ifElse(condition, expression_bool_result, expression_bool_result)
whereas expression_bool_result may either be TRUE/FALSE, the result of and(), or(), ==, !=.... or further ifElse
b) ifElse(condition, expression_arith_result, expression_arith_result)
whereas expression_arith_result may either be any number, the result of calculations of further functions returning a number... (or further ifElse)
Since I am new to javacc, I would like to ask you how a production could look like which allows the parser for a clear decision.
Currently I get the warning
Warning: Choice conflict involving two expansions at
line 824, column 5 and line 825, column 5 respectively.
A common prefix is: "ifElse" "("
Consider using a lookahead of 3 or more for earlier expansion.
which - as far as I can tell - implies that my grammer (regarding ifelse) is ambiguous.
If there is no way to write it unambiguously, how could the suggested lookahead look like?
Thanks for your feedback in advance!
No fixed amount of lookahead could possibly resolve this ambiguity in all cases. You could have an arbitrarily long stream of tokens that form a valid expression_arith_result - but is then followed by a comparison operator and another arithmetic value, thus turning it into an expression_bool_result.
The solution would be to have a single ifElse statement, that takes two arbitrary expressions. The required agreement in type between the two expressions would be a matter of semantics, not grammar.
Jason's answer is correct in that you can't resolve the choice with a fixed length of lookahead. However JavaCC does not limit you to fixed length of lookahead. So you can do the following.
void IfExpression() :
{ }
{ LOOKAHEAD( <IFELSE> "(" Condition() "," BooleanExpression() )
BooleanIfExpression()
|
ArithmeticIfExpression()
}
My question is where does the piping operator of magrittr package %>% come in the order of operations?
I have a problem simmilar to the following:
set.seed(10)
df <- data.frame(a=rnorm(3),b=rnorm(3),c=rnorm(3))
df/rowSums(df) %>% round(.,3)
This results in the following non rounded figures:
a b c
1 -0.0121966 0.119878 0.8922125
To get the rounded figures I need to put df/rowSums(df) between brackets.
I experimented with the +,-,*,/ and ^ and from the results I found the order of operation is as follow:
Exponents
Piping
Multiplication and division
Addition and subtraction
Is that right or there is something wrong with my understanding of the piping operator?
The help page you are looking for is ?Syntax. (Don't feel bad for not being able to find this, it took me about six guesses at search keywords.) I'm going to quote its entire operator precedence table here:
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
‘< > <= >= == !=’ ordering and comparison
‘!’ negation
‘& &&’ and
‘| ||’ or
‘~’ as in formulae
‘-> ->>’ rightwards assignment
‘<- <<-’ assignment (right to left)
‘=’ assignment (right to left)
‘?’ help (unary and binary)
So magrittr's pipe operators, like all the operators of the form %whatever%, do indeed have precedence greater than multiply and divide but lower than exponentiation, and this is guaranteed by the language specification.
Personally, I don't see the value in these operators. Why not just write
round(df/rowSums(df), 3)
which has the evaluation order you want, and is (IMNSHO) easier to read as well?