associativity of parentheses - associative

This msdn link says that '(' and ')' has left to right associativity.
How does that make sense? Can someone give me a example?

In formal grammars an operator with left-to-right precedence is left recursive. So with binary addition:
S -> E
E -> E + a
E -> a
So the tree would look like:
S
|
E
|
E + a
|
E + a
|
a
As you can see the first two a's are added before the second two.
For a right-associative operator, your grammar would contain right-recursion. So with binary exponentiation:
S -> E
E -> a ** E
E -> a
Subsequently your parse tree would look like:
S
|
E
|
a ** E
|
a ** E
|
a
As you can see the last two a's are exponentiated, first, and the result of that is the power of the first a (this is the proper associativity for exponentiation, by the way).
For ternary and greater operators the same pattern is applied, the recursive rule is either the left-most nonterminal or the right-most nonterminal. In the case of unary operators, though, whether or not it's left- or right-recursive depends on whether or not the nonterminal s on the left or right, respectively. In the case of ( E ) there is a terminal on either side, and the nonterminal, although recursive, is neither left- nor right-recursive from a grammatical point of view so I think the MSDN article has arbitrarily declared it to be "left to right."
The associativity of parenthesis has no bearing on the fact that d is evaluated prior to a+b+c in d+(a+b+c) and has no bearing on the associativity of a+b+c as well, so I have no idea what the other Jared is talking about.

What is unclear? They come in a pair whenever you have a ( you will have a ). Once inside of them you work the arythmatic from left to right so if you have d+(a+b+c) you will do a+b then the sum of a+b added to c then the total sum of a,b,c added d

Related

Google Query function not filtering the right way (Order by desc)

Good day,
I'm facing an issue with the Google Query function. Indeed I'm trying to us the below :
=query(RESEARCH!A4:O,"Select A, D, E, K, N, O, C, H where E is not null and not E contains 'SPOT' order by E Desc",0)
But for some reasons it's not ordering E the right way. Strange thing is that if I chose B it works perfectly fine. I double checked that my columns where in number format.
Does anyone know from where it could come from please ?
Thank you in advance for your help. Have a nice day.

How to write relational algebra for SQL WHERE column IN?

select age from person where name in (select name from eats where pizza="mushroom")
I am not sure what to write for the "in". How should I solve this?
In this case the sub-select is equivalent to a join:
select age
from person p, eats e
where p.name = e.name and pizza='mushroom'
So you could translate it in:
πage (person p ⋈p.name=e.name (σpizza='mushroom'(eats e)))
Here's my guess. I'm assuming that set membership symbol is part of relational algebra
For base table r, C a column of both r & s, and x an unused name,
select ... from r where C in s
returns the same value as
select ... from r natural join (s) x
The use of in requires that s has one column. The in is true for a row of r exactly when its C equals the value in s. So the where keeps exactly the rows of r whose C equals the value in s. We assumed that s has column C, so the where keeps exactly the rows of r whose C equals the C of the row in r. Those are same rows that are returned by the natural join.
(For an expression like this where-in with C not a column of both r and s then this translation is not applicable. Similarly, the reverse translation is only applicable under certain conditions.)
How useful this particular translation is to you or whether you could simplify it or must complexify it depends on what variants of SQL & "relational algebra" you are using, what limitations you have on input expressions and other translation decisions you have made. If you use very straightforward and general translations then the output is more complex but obviously correct. If you translate using a lot of special case rules and ad hoc simplifications along the way then the output is simpler but the justification that the answer is correct is longer.

Getting ordered subset of records

I have table which basically describes a bus route. The table includes all the stops of a particular route.
This SQLFiddle shows an example. The data shows the flow in one direction, but a route can also be in the other direction.
I need to get a subset of this route (or all of it) depending on the start and end stations. So for example, I might have these:
A -> M (subset would be B -> L)
A -> K (subset would be B -> J)
C -> H (subset would be D -> G)
I -> M (subset would be J -> L)
However, if the direction is from, for example, H -> B, the subset would need to be G -> C.
The sequence column is for this purpose.
Is there a clean and easy way to do this using just SQL?
Assuming I understand your question, it seems simple enough.
To get a subset just use a between...and operator on the sequence column:
SELECT stop_from, stop_to
FROM routes
WHERE sequence BETWEEN 2 AND 11
ORDER BY sequence
To get the subset in the opposite direction, just order by desc, and select the stop_to as stop_from, and stop_from as stop_to:
SELECT stop_to As stop_from, stop_from As stop_to
FROM routes
WHERE sequence BETWEEN 3 AND 7
ORDER BY sequence DESC
See fiddle here

Relation between Left factoring a grammar and removing epsilon

Let's say I'd using below grammar for compiler
S -> a | aB
if I perform left factoring on it, it would be like (e is epsilon)
S -> aC
C -> B | e
then I want to remove epsilon which ends up being like
S -> a | aC
C -> B
notice that it looks like I again need to perform left factoring, and doing so infinitely left factoring and removing epsilon back and forth. Am I doing something wrong ??
Is it require to remove both left factoring and epsilon on grammar for compiler?
You shouldn't need to do either transformation, most of the time. In fact, for some grammars, left-factoring will create shift-reduce conflicts for LALR(1) parser generators.

SQL Order of precendence of query expressions

I am trying to work out how SQL queries are run and have hit a bit of a stumbling block.
If a where clause akin to the below is used:
A OR B AND C
This could mean either of the below
(A OR B) AND C
or
A OR (B AND C)
In the majority of cases the results will be the same, but if the set to be queried contains solely {A}, the first variant would return an empty result set and the second would return {A}. SQL does in fact return the 1 result.
Does anyone know (or have links to) any insight that will help me understand how queries are built?
Ketchup
The order is the following according to MSDN:
~ (Bitwise NOT)
(*) (Multiply), / (Division), % (Modulo)
(+) (Positive), - (Negative), + (Add), (+ Concatenate), - (Subtract), & (Bitwise AND), ^ (Bitwise Exclusive OR), | (Bitwise OR)
=, >, <, >=, <=, <>, !=, !>, !< (Comparison operators)
NOT
AND
ALL, ANY, BETWEEN, IN, LIKE, OR, SOME
= (Assignment)
In the knowledge (from documentation) that AND has a higer precedence than OR, you should aim to write predicates for WHERE clauses in conjunctive normal form ("a seires of AND clauses").
If the intention is
( A OR B ) AND C
then write it thus and all is good.
However, if the intention is
A OR ( B AND C )
then I suggest you apply the distributive rewrite law that results in conjunctive normal form i.e.
( P AND Q ) OR R <=> ( P OR R ) AND ( Q OR R )
In your case:
A OR ( B AND C ) <=> ( A OR B ) AND ( A OR C )
AND and OR have different precedende.
See Precedence Level
For SQL-Server (which is your tag) here is the precedence http://msdn.microsoft.com/en-us/library/ms190276.aspx but..
If you're worried about the exact result set given you should indeed start working with () subsets.