Added AI,DB2 and FLC notes

Artificial Intelligence/lesson_05.md

@@ -0,0 +1,118 @@
+# AI - lesson 05
+#### Francesco Arrigoni
+###### 21 October 2015
+## Search Strategies
+Ways to select the elements from the frontier
+### Uninformed search strategies
+Know only information from the formulation of the problem.
+### breadth-first search
+Select the element of the frontier which is closest to the root (shallowest solution)  
+Given the example
+|A|5|B|5|E|1|D|1|C|1|A|
+|---|---|---|---|---|---|---|---|---|---|---|
+Steps:
+1. We select the __root__ of the space-state (state A)
+2. We apply the goal function which results to be false
+2. We expand the selected node and add __adjacent items__ (B,C) to the frontier
+3. We have to select the __nearest node to the root__, we have a tie so we use the lexycographic order (B)
+    - In case of tie we can apply any principle to choose the node
+4. We expand the chosen node (B), adding the adjacent nodes (A,E) to the frontier
+5. We select the shallowest solution like in step 3, (C )
+6. We expand the selected node C, we have another tie in which we select the oldest node (A)
+...
+
+If there are no ties, we can manage the frontier as a __FIFO__ queue.
+
+#### Properties
+Is breadth-first search a __complete strategy__? yes
+
+There is anyway a degerate case in which we have a state space with infinite children, in which we cannot find a solution.
+
+Is this search strategy __optimal__? no
+
+This strategy finds the solutions which are closest to the root.  
+In the case in which all the costs are *unitary*, or in general when the __path costs__ are a *non decreasing* function of the depth from the root, the closest solution to the root (provided by this algorithm) is also optimal.
+
+#### Complexity
+
+__Time Complexity__
+> Number of nodes that are generated in the worst case
+
+In the worst case (solution in node D) we are generating (nodes at level d)
+$$1+b+b^2+...+b^d$$
+$b$= branching factor: maximum number of children  
+The time complexity is:
+$$O(b^{d+1})$$
+
+__Improving time complexity__
+The solution node (E) was put in the frontier early but recognized as a solution only later, we apply the goal test when i generate the node rather than when i choose from the frontier.
+The resulting complexity consists in half the nodes.
+$$O(b^{d})$$
+
+__Space Complexity__
+> The nodes to be kept in memory until a solution is found
+$$O(b^d)$$
+
+This result if for both version with duplicated list elimination and without it.
+
+### Uniform-cost search
+The frontier is ordered according to the path cost, according to the space-state weights.
+Is is called like that because is a special case of another strategy.
+#### Properties
+
+Is breadth-first search a __complete strategy__? yes
+
+Also in this case there is a degenerated state in which one or more costs are zero and then i keep expanding the same nodes.
+
+Is this strategy __optimal__? yes
+
+__Time Complexity__
+$$O(b^{\lceil C*/\varepsilon\rceil})$$
+__Space Complexity__
+$$O(b^{\lceil C*/\varepsilon\rceil})$$
+
+### Depth-first search
+Select the nodes that are farthest from the root.
+
+This can be seen as a __LIFO__ queue
+#### Propertires
+Is breadth-first search a __complete strategy__? no
+
+If we use the closed list (never expanding two nodes corresponding to the same state), this search trategy is __complete__
+
+Is this strategy __optimal__? no
+
+__Time Complexity__
+$$O(b^{n})$$
+__Space Complexity__  
+If we have not found any solution along a branch, we can remove the content of the branch from the memory, we need to keep in memory only one branch at time
+$$O(bm)$$
+
+#### Backtracking (dfs variant)
+I keep in memory only one node with some informations about the chosen nodes
+
+### Depth limited search
+I fix a number $l$ which becomes the maximum depth of my search tree
+#### Propertires
+Is breadth-first search a __complete strategy__? yes
+
+Only when $e\ge d$
+
+Is this strategy __optimal__? no
+
+__Time Complexity__
+$$O(b^{e})$$
+__Space Complexity__  
+$$O(bl)$$
+### Iterative deepening search
+#### Propertires
+Is breadth-first search a __complete strategy__? yes
+
+Is this strategy __optimal__? no
+
+Unless costs are all 1
+
+__Time Complexity__
+$$O(b^{d})$$
+__Space Complexity__  
+$$O(bd)$$

Data Bases 2/lesson_04.md

@@ -0,0 +1,114 @@
+# DB2 - lesson 04
+#### Paraboschi
+##### 19 October 2015
+## Concurrency Control pt.III
+
+### Hierarchical locking
+
+Locking can be done upon objects at various level of granularity (tables, sets, whole database)
+
+The objective is to:
+- minimize the number of the locks
+- recogniziung conflicts as soon as possible.
+
+A typical hierarchy can be:
+- table
+- page
+- tuple
+- rule
+
+The lower we put the lock, the higher is concurrency, but also lock manager load is higher.
+
+### Enhanced locking scheme
+
+We have 5 lock modes:
+- __r_lock__ -> __shared lock__ (SL)
+- __w_lock__ -> __exclusive lock__ (XL)
+
+Also intention of locking at lower levels of granularity is defined:
+- __ISL__ intention of locking in shared mode
+- __IXL__ intention of locking in exclusive mode
+- __SIXL__ lock in shared mode with intention of locking in exclusive mode
+
+#### Conflicts in hierarchical locks
+|| ISL | IXL|SL|SIXL|XL|
+| :------------- | :------------- |---|---|---|---|
+|ISL | __OK__ |__OK__|__OK__|__OK__|NO|
+|IXL|__OK__|__OK__|NO|NO|NO|
+|SL|__OK__|NO|__OK__|NO|NO|
+|SIXL|__OK__|NO|NO|NO|NO|
+|XL|NO|NO|NO|NO|NO|
+
+This way i can identify the conflicts based on the requests of the resources.
+
+### Hierarchical locking protocol
+- Locks are requested starting from the root and going down in the hierarchy
+- Locks are  released starting from the leaves and then going up in the hierarchy
+- To request an SL or ISL lock o a non-root  node, a transaction must hold an ISL or IXL lock on its parent node
+. To request and IXL, XL, or SIXL lock on a non-root node, a transaction must hold a SIXL or IXL lock on its parent.
+
+#### Example
+```
+Transaction 1: IXL(root)
+read(P1) SIXL(P1)
+write(t3) XL(t3)
+read(t8) ISL(P2) SL(t8)
+```
+| Page 1 |Page 2    |
+| :------------- | :------------- |
+|t1 read|t5|
+|t2 read|t6|
+|t3 write|t7|
+|t4 read|t8 read|
+```
+Transaction 2: IXL(root) ISL(P1)
+read(t2) SL(t2)
+read(t4) SL(t4)
+write(t5) IXL(P2) XL(t5)
+write(t6) XL(t6)
+```
+| Page 1 |Page 2    |
+| :------------- | :------------- |
+|t1|t5 write|
+|t2 read|t6 write|
+|t3|t7|
+|t4 read|t8|
+
+The two transactions (read and write operations) are compatible, in fact we have one type of lock for each resource.
+
+### Deadlock
+Occurs because concurrent transactions hold and, in
+turn, require resources held by other transactions
+
+A deadlock is represented by a cycle in the wait-for graph of the resources
+#### Deadlock resolution techniques:
+- Timeout: transactions killed after a long wait
+- Deadlock prevention: transactions killed when they *could be* in deadlock
+- Deadlock detection: transactions killed then they *are* in deadlock
+
+#### Timeout method
+A transaction is killed after given waiting, assuing it is involved in a deadlock.  
+Is the simplest, most used method
+
+Timeout value is system-determined, the problem is choosing a __proper value__:
+- too long: useless waits
+- too short: unrequired kills
+
+#### Deadlock prevention
+
+A possible scheme is:
+- Assigning transactions a number (an __age__)
+- killing transactions when __older__ transactions wait for __younger__ transactions
+
+Options for choosing the transaction to kill:
+- pre-emptive (killing the waiting transaction)
+- non-pre-emptive (killing the requesting transaction)
+
+The problem: too many killings (waiting probability vs deadlock probability)
+
+Deadlock prevention is not used because in any case it generates many killings.
+
+#### Deadlock detection
+
+Requires an algorithm to find real cycles in the wait-for graph
+It consumes resources but works well and is the solution used.

Data Bases 2/lesson_05.md

@@ -0,0 +1,114 @@
+# DB2 - lesson 04
+#### Paraboschi
+##### 19 October 2015
+## Concurrency Control pt.III
+
+### Hierarchical locking
+
+Locking can be done upon objects at various level of granularity (tables, sets, whole database)
+
+The objective is to:
+- minimize the number of the locks
+- recogniziung conflicts as soon as possible.
+
+A typical hierarchy can be:
+- table
+- page
+- tuple
+- rule
+
+The lower we put the lock, the higher is concurrency, but also lock manager load is higher.
+
+### Enhanced locking scheme
+
+We have 5 lock modes:
+- __r_lock__ -> __shared lock__ (SL)
+- __w_lock__ -> __exclusive lock__ (XL)
+
+Also intention of locking at lower levels of granularity is defined:
+- __ISL__ intention of locking in shared mode
+- __IXL__ intention of locking in exclusive mode
+- __SIXL__ lock in shared mode with intention of locking in exclusive mode
+
+#### Conflicts in hierarchical locks
+|| ISL | IXL|SL|SIXL|XL|
+| :------------- | :------------- |---|---|---|---|
+|ISL | __OK__ |__OK__|__OK__|__OK__|NO|
+|IXL|__OK__|__OK__|NO|NO|NO|
+|SL|__OK__|NO|__OK__|NO|NO|
+|SIXL|__OK__|NO|NO|NO|NO|
+|XL|NO|NO|NO|NO|NO|
+
+This way i can identify the conflicts based on the requests of the resources.
+
+### Hierarchical locking protocol
+- Locks are requested starting from the root and going down in the hierarchy
+- Locks are  released starting from the leaves and then going up in the hierarchy
+- To request an SL or ISL lock o a non-root  node, a transaction must hold an ISL or IXL lock on its parent node
+. To request and IXL, XL, or SIXL lock on a non-root node, a transaction must hold a SIXL or IXL lock on its parent.
+
+#### Example
+```
+Transaction 1: IXL(root)
+read(P1) SIXL(P1)
+write(t3) XL(t3)
+read(t8) ISL(P2) SL(t8)
+```
+| Page 1 |Page 2    |
+| :------------- | :------------- |
+|t1 read|t5|
+|t2 read|t6|
+|t3 write|t7|
+|t4 read|t8 read|
+```
+Transaction 2: IXL(root) ISL(P1)
+read(t2) SL(t2)
+read(t4) SL(t4)
+write(t5) IXL(P2) XL(t5)
+write(t6) XL(t6)
+```
+| Page 1 |Page 2    |
+| :------------- | :------------- |
+|t1|t5 write|
+|t2 read|t6 write|
+|t3|t7|
+|t4 read|t8|
+
+The two transactions (read and write operations) are compatible, in fact we have one type of lock for each resource.
+
+### Deadlock
+Occurs because concurrent transactions hold and, in
+turn, require resources held by other transactions
+
+A deadlock is represented by a cycle in the wait-for graph of the resources
+#### Deadlock resolution techniques:
+- Timeout: transactions killed after a long wait
+- Deadlock prevention: transactions killed when they *could be* in deadlock
+- Deadlock detection: transactions killed then they *are* in deadlock
+
+#### Timeout method
+A transaction is killed after given waiting, assuing it is involved in a deadlock.  
+Is the simplest, most used method
+
+Timeout value is system-determined, the problem is choosing a __proper value__:
+- too long: useless waits
+- too short: unrequired kills
+
+#### Deadlock prevention
+
+A possible scheme is:
+- Assigning transactions a number (an __age__)
+- killing transactions when __older__ transactions wait for __younger__ transactions
+
+Options for choosing the transaction to kill:
+- pre-emptive (killing the waiting transaction)
+- non-pre-emptive (killing the requesting transaction)
+
+The problem: too many killings (waiting probability vs deadlock probability)
+
+Deadlock prevention is not used because in any case it generates many killings.
+
+#### Deadlock detection
+
+Requires an algorithm to find real cycles in the wait-for graph
+It consumes resources but works well and is the solution used.

Formal Languages and Compilers/lesson_06.md

@@ -0,0 +1,4 @@
+# FLC - lesson 05
+##### Luca Oddone Breveglieri
+###### 19 october 2015
+## Grammars pt.III