Top Banner
Tirgul 11 •Solutions for questions from T2, T3 •DFS & BFS - reminder •Some Hashing Reminder: don’t forget to run ~dast/bin/testEx3.csh on your jar file before submitting ex3!!!
24

Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

Dec 21, 2015

Download

Documents

Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Page 1: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

Tirgul 11

•Solutions for questions from T2, T3

•DFS & BFS - reminder

•Some Hashing

Reminder: don’t forget to run ~dast/bin/testEx3.csh on your

jar file before submitting ex3!!!

Page 2: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

T2 – Question 3

• Q: Prove that there is no comparison-based sort whose running time is linear for at least half of the n! inputs of length n.

• A: A comparison based sort can be described by a decision tree:– Each node is a comparison– Each edge is an outcome of a comparison

• The running time is the depth of the correct leaf.

Page 3: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

T2 – Question 3• A tree of height h has less than 2h+1 nodes• If there are n!/2 leaves at depth cn, then

2cn+1 ≥ n!/2 cn + 1 ≥ log(n!) - 1 n = (n logn) contradiction!

• What about 1/n of the input? And 1/2n of the input?

2cn+1 ≥ n!/n cn + 1 ≥ log((n-1)!) = (n logn)2cn+1 ≥ n!/2n cn + 1 ≥ log(n!) - n = (n logn)

Both impossible as well

Page 4: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

T3 – Question 1

• Q: Suppose that another data structure contains a pointer to a node y in a binary search tree, and suppose that y’s predecessor z is deleted from the tree by the procedure TREE-DELETE. What problem can arise? How can TREE-DELETE be rewritten to solve the problem?

y

externalreference

zdelete

Page 5: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

T3 – Question 1

• If z has two children, then the deletion of z consists of:– Replacing the contents of z with the

contents of the successor of z– Deleting the successor of z

• In this case, we will delete the node where y used to be.

• So the reference to y will become invalid, even though we did not delete y itself

externalreference

y

?

Page 6: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

T3 – Question 1

• Solution: instead of copying the contents of y into z, place the node y in the tree where z used to be, after deleting it:

y=z.successor

make y.right the child of y.parent instead of y

connect y to z’s parent and children instead of z external

reference

y

Page 7: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

T3 – Question 5

• An in-order tree walk can be implemented by finding the minimum element and then making n-1 calls to TREE-SUCCESSOR

• Q: How many times at most do we pass through each edge?

Page 8: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

T3 – Question 5

TREE-SUCCESSOR(x)if x.right==null y=x.parentwhile y!=null && x==y.right

x=yy=y.parent

elsey=x.rightwhile y.left!=null

y=y.leftreturn y

going up (1)

going up (2)

going down (3)

going down (4)

Page 9: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

T3 – Question 5• Right edges:

– A right edge nn.right is passed downwards only at (3), which happens when we call TREE-SUCCESSOR(n)

– Since we call TREE-SUCCESSOR once for each node, we go down each right edge once, at most

• Left edges:– After we pass a left edge nn.left (at (1) or (2)), TREE-SUCCESSOR returns n

– Since TREE-SUCCESSOR returns each node once, we go up each left edge once, at most

• For each time we go down an edge, we have to go back up that edge, and vice versa

• Therefore, we pass each edge at most twice• In-order walk takes O(n) steps

Page 10: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

T4 – Question 2

• Q: You are in a square maze of nn cells and you’ve got loads of coins in your pocket. How do you get out?

• A: The maze is a graph where– Each cell is a node– Each passage between cells is an

edge

• Solve the maze by running DFS until the exit is found

Page 11: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

DFS-VISIT(u) u.color=gray u.d=++time for each vadj[u] if v.color=white v.prev=u DFS-VISIT(v) u.color=black u.f=++time

DFS(G) for each uV[G] u.color=white u.prev=nil time=0 for each uV[G] if u.color=white DFS-VISIT(u)

DFS - Reminder

Page 12: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

BFS(G,s) for each uV[G] u.dist=∞ s.dist=0 Q.enqueue(s) while Q not empty u=Q.dequeue() for each vadj[u] if v.dist=∞ v.dist=u.dist+1 v.prev=u Q.enqueue(v)

BFS - Reminder

Page 13: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

T4 – Question 2• A white node is a cell without any coins• A gray node is a cell with a coin lying with its

head side up• A black node is a cell with a coin lying with its tail

side up• An edge connecting a node to its parent is

marked by a coin• When visiting a cell, we color it gray• If it has a white cell adjacent to it – visit it• If there are no such cells,

– Color the cell “black” by flipping the coin– backtrack by going to the cell marked as parent

Page 14: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

T4 – Question 2

• Each node has one parent

• When backtracking, the parent will be the only adjacent “gray” cell that has a coin leading to it

• Can we solve it using BFS?

• Answer: No! In DFS we go between adjacent cells; in BFS, the nodes are in a queue, so the next cell could be anywhere

Page 15: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

Dynamic Hash Tables• Since performance depends on the load factor,

we would like to expand the table when the load factor is too high

• Expansion involves allocating a new table and rehashing the keys into it from the old table

• Most insertions would be O(1), but some insertions will cause the table to expand, which would take O(n)

• So, table operations take O(n) in the worst case, but what is the average time for a table operation in the worst case? What is the worst case for n operations? We use amortized analysis to answer these questions

Page 16: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

Example - Stack with multi-pop• As a first example we analyze the performance of a

stack with one additional operation - multipop(k)- that pops the top k elements of the stack.

• Since multipop can take O(n) time in the worst-case, we might conclude that n stack operations can take O(n2) in the worst case.

• We will analyze this simple D.S. using two methods:– The aggregate method– The accounting method

and see that the average time per operation is still O(1).

Page 17: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

The aggregate method

• In this method we find T(n), the total time to perform n operations in the worst-case. The amortized cost of each operation is then defined as T(n)/n.

• In our stack example, T(n) = O(n) :If we performed a total of k push operations, then the total time for the pop and multipop operations is also at most k (the number of elements we can pop is at most the number of elements we pushed). Since k is at most n, then T(n)=O(n).

• Thus the amortized cost for all operations is O(1).

Page 18: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

The accounting method• In this method, we receive “money” for each

operation.– We pay for the actual cost of the operation

– With what’s left we may pay for future operations.

– The total cost for n operations is the total “money” we got, since with it we covered the entire actual cost.

– The amortized cost of each operation is the money we got for this operation.

• In our stack example, we define the following:– The amortized cost (the “money” we get) for a push

operation is 2, and for the pop and multipop operation is 0.

– When pushing an item, we pay 2 – 1 goes to the push operation, and 1 is left to its credit; this will pay for its pop or multipop.

Page 19: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

The accounting method (continued)

• So we see that the average cost of each operation is constant (in contrast to the actual cost). In other words, since the total payment is at most 2n, the total time is at most O(n), and the average time is per operation is O(1).

Operation Actual cost Average (amortized) cost

push

pop

multipop

1

1

k

2

0

0

Page 20: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

Dynamic Tables• A Dynamic table is an array that expands

dynamically when it becomes overloaded, to fit itself to a variable demand. What is it good for?– Java’s Vector– Heaps– Hash tables

• In a dynamic table, besides the regular insert and delete, there is also expansion when the table is overloaded and we want to insert a new element.

Page 21: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

Expansion

• Consider the following expansion scheme:– Table starts with a size of 1.– Upon an insert, if the table is full, create a

table twice the old size and copy the old table to the beginning of the new one.

• Actual cost: 1 for regular insertion, size(T) for expansion.

Page 22: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

• Expansion doubles the table size• Therefore, for every i, after inserting the

2i+1 item, a new table of size 2i+1 will be allocated and 2i values will be copied

• So, the number of operations required for n insertions is:

• Therefore, the amortized cost of each insertion is O(1).

Expansion - Aggregate

)(122 1log

log

0

nnn

i

i

Page 23: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

Expansion - Accounting• Amortized cost, the accounting method:

– Suppose we pay 3 for every regular insertion: 1 for the actual cost, and 2 remains as credit for this element.

– How do we pay for an expansion? Suppose the table is doubled from size x to 2x. Then we have x/2 elements that didn’t pay for an expansion yet (have credit of 2). Thus each one of them pays for itself and for one other element out of the x/2 with credit 0.

Page 24: Tirgul 11 Solutions for questions from T2, T3 DFS & BFS - reminder Some Hashing Reminder : don’t forget to run ~dast/bin/testEx3.csh on your jar file before.

Expansion – Hash Tables

• When the load factor is too high, we would like to expand the table

• Since the hash codes depend on the table size, we need to rehash: compute the new hash code for every item in the old table and use it to insert it to the new table

• If the maximal load factor is constant, the amortized cost of insertion remains O(1)