If I have an empty avl tree and I want to insert a set of ordered numbers (1, 2, ... k), why the complexity is O(k).
thank you
It's more of a math question, so here is the deal
AVL tree has a time complexity of log(n) for inserting an element with n nodes inside the tree
so from your question, with a set of number (1,2,3,...,k) you wanted to insert, the time complexity would be like this
summation from i=1 to i=k of log(i) (i.e. log1 + log2 + log3 + ... + logk)
which is equals to
log(k!)
which is approximately equals to
k*log(k) (By using Stirling's approximation)
So to answer your question, it should be O(k log k) instead of O(k)
Related
So I'm trying to figure out an algorithm to join 2 AVL trees together in O(logn) time, where n is the total number of integers in both trees and is also odd. In this problem, the integers in the trees are distinct from one another. Additionally, each node of the trees store the size of the subtree rooted at it. I was thinking of adding the elements of the smaller tree into the larger one but I wasn't sure how to go about proving that this would take O(logn) time. Does anyone have any suggestions as to how I could go about this?
This is impossible.
Proof: Assume you had an algorithm to join 2 AVL search trees in O(logn), and let it be A(T1,T2)
We now represent a new sorting algorithm: Sort(A)(1)
Sort(A):
Let T_i be an AVL tree consisting only of A_i // O(1) n times, total O(n).
curr_size = 1
while curr_size < size(A):
Let T_i, T_j be two trees of size curr_size // O(1)
// Assume without loss of generality i < j.
if there are such T_i,T_j:
T_i = A(T_i,T_j) // O(log(curr_size))
else:
curr_size = curr_size * 2 // O(1)
return in_order(T_0) // O(n) by in-order traversal.
The algorithm complexity is:
T(n) = n/2 * log(2) + n/4 * log(4) + n/8 * log(8) + ... + 2*log(n/2) + log(n)
Explanation
First we need to merge all trees of size 1 to trees of size 2. This requires n/2 merges, each takes O(log(2)). Next, merge the resulting n/2 trees to trees of size 4. This is done n/4, each O(log4), ... lastly we have two trees and we merge them once, and it takes O(n).
This gives us the formula:
T(n) = sum (n/2^i * log(2^i)) for i=1,2,3,...,logn
We could do some more algebra, but I take a shortcut and feed it to Wolfram alpha, which gives us:
T(n) = 2n -log(n) -2
Since the above is linear, this means our general purpose sorting algorithm Sort(A) is linear.
But Sorting is Omega(nlogn).
This means something is wrong - so the assumption that such an algorithm A(T1,T2) exists, with O(logn) complexity is wrong.
QED
(1) For simplicity, the algorithm assumes size(A) = 2^i for some i in N. This restriction can be relaxed without changing the conclusion, only changing the complication of the algorithm.
Assume we constructed a quicksort and the pivot value takes linear time. Find the recurrence for worst-case running time.
My answer:
T(n)= T(n-1) + T(1) + theta(n)
Worst case occurs when the subarrays are completely unbalanced.
There is 1 element in one subarray and (n-1) elements in the other subarray.
theta(n) because it takes running time n to find the pivot.
Am I doing this correctly?
Your recurrence is mostly correct, but you don't actually have two recursive calls made. In the worst-case for quicksort, the pivot will be the largest or smallest element in the array, so you'll recur on one giant array of size n - 1. The other subarray has length 0, so no recursive calls are made. To top everything off, the total work done is Θ(n) per level, so the recurrence relation would more appropriately be
T(n) = T(n - 1) + Θ(n)
This in turn then solves to Θ(n2).
Hope this helps!
you cannot observe, because according to my research T(N)= T(N-K)+T(K-1)+n
we cannot observe exact value until we have
value of k,
T(n) = T(an/(a+b)) + T(bn/(a+b)) + n
Where a/(a+b) and b/(a+b) are fractions of array under consideration
i'm just wondering what is efficiency (O(n)) of this algorithm:
Find the largest index k such that a[k] < a[k + 1]. If no such index exists, the permutation is the last permutation.
Find the largest index l such that a[k] < a[l]. Since k + 1 is such an index, l is well defined and satisfies k < l.
Swap a[k] with a[l].
Reverse the sequence from a[k + 1] up to and including the final element a[n].
As I understand the worst case O(n) = n (when k is the first element of previous permutation), best case O(n) = 1 (when k is last element of previous permutation).
Can I say that O(n) = n/2 ?
O(n) = n/2 makes no sense. Let f(n) = n be the running time of your algorithm. Then the right way to say it is that f(n) is in O(n). O(n) is a set of functions that are at most asymptotically linear in n.
Your optimization makes the expected running time g(n) = n/2. g(n) is also in O(n). In fact O(n) = O(n/2) so your saving of half of the time does not change the asymptotic complexity.
All steps in the algorithm takes O(n) asymptotically.
Your averaging is incorrect. Just because best case is O(1) and worst case is O(n), you can't say the algorithm takes O(n)=n/2. Big O notation is simply for the upper bound of the algorithm.
So the algorithm is still O(n) irrespective of the best case scenario.
There is no such thing as O(n) = n/2.
When you do O(n) calculations you're just trying to find the functional dependency, you don't care about coefficients. So there's no O(n)= n/2 just like there's no O(n) = 5n
Asymptotically, O(n) is the same as O(n/2). In any case, the algorithm is performed for each of the n! permutations, so the order is much greater than your estimate (on the order of n!).
Can any one explain why the time complexity for generating a binary heap from a unsorted array using bottom-up heap construction is O(n) ?
(Solution found so far: I found in Thomas and Goodrich book that the total sum of sizes of paths for internal nodes while constructing the heap is 2n-1, but still don't understand their explanation)
Thanks.
Normal BUILD-HEAP Procedure for generating a binary heap from an unsorted array is implemented as below :
BUILD-HEAP(A)
heap-size[A] ← length[A]
for i ← length[A]/2 downto 1
do HEAPIFY(A, i)
Here HEAPIFY Procedure takes O(h) time, where h is the height of the tree, and there
are O(n) such calls making the running time O(n h). Considering h=lg n, we can say that BUILD-HEAP Procedure takes O(n lg n) time.
For tighter analysis, we can observe that heights of most nodes are small.
Actually, at any height h, there can be at most CEIL(n/ (2^h +1)) nodes, which we can easily prove by induction.
So, the running time of BUILD-HEAP can be written as,
lg n lg n
∑ n/(2^h+1)*O(h) = O(n* ∑ O(h/2^h))
h=0 h=0
Now,
∞
∑ k*x^k = X/(1-x)^2
k=0
∞
Putting x=1/2, ∑h/2^h = (1/2) / (1-1/2)^2 = 2
h=0
Hence, running time becomes,
lg n ∞
O(n* ∑ O(h/2^h)) = O(n* ∑ O(h/2^h)) = O(n)
h=0 h=0
So, this gives a running time of O(n).
N.B. The analysis is taken from this.
Check out wikipedia:
Building a heap:
A heap could be built by successive insertions. This approach requires O(n log n) time because each insertion takes O(log n) time and there are n elements. However this is not the optimal method. The optimal method starts by arbitrarily putting the elements on a binary tree, respecting the shape property. Then starting from the lowest level and moving upwards, shift the root of each subtree downward as in the deletion algorithm until the heap property is restored.
http://en.wikipedia.org/wiki/Binary_heap
Getting ready for exam. This is not the homework question.
I figured that the worst case O(N^2) to build BST. (each insert req N-1 comparison, you sum all the comparisons 0 + 1 + ... + N-1 ~ N^2). This is the case for skewed BST.
The insertion for (balanced) BST is O(log N), so why the best case is O(N logN) to construct the tree ?
My guess best guess - since single insertion is log N, than summing all the insertions somehow gives us N log.
Thanks !
As you wrote :) Single insertion is O(log N).Because the weighted tree height of N element is log N you need up to log N comparsions to insert single element. You need to do N of these insertions. So N*logN.