1

I'm not entirely sure what amortized complexity means. Take a balanced binary search tree data structure (e.g. a red-black tree). The cost of a normal search is naturally log(N) where N is the number of nodes. But what is the amortized complexity of a sequence of m searches in, let's say, ascending order. Is it just log(N)/m?

user1377000
  • 1,313
  • 2
  • 14
  • 27

4 Answers4

1

Well you can consider asymptotic analysis as a strict method to set a upper bound for the running time of algorithms, where as amortized analysis is a some what liberal method.

For example consider an algorithm A with two statements S1 and S2. The cost of executing S1 is 10 and S2 is 100. Both the statements are placed inside a loop as follows.

n=0;
while(n<100)
{
  if(n % 10 != 0)
  {
    S1;
  }
  else
  {
    s2;
  }
  n++;
}

Here the number of times S1 executed is 10 times the count of S2. But asymptotic analysis will only consider the facts that S2 takes a time of 10 units and it is inside a loop executing 100 times. So the upper limit for execution time is of the order of 10 * 100 = 1000. Where as amortized analysis averages out the number of times the statements S1 and S2 are executed. So the upper time limit for execution is of the order of 200. Thus amortized analysis gives a better estimate of the upper limit for executing an algorithm.

Deepu
  • 7,406
  • 4
  • 23
  • 47
  • Thanks. So in case of a balanced binary search tree, it would be just O(logN)/m? (since O(logN) is the worse case scenario of a search). In fact, do we have to go back to the root every time? – user1377000 Mar 15 '13 at 07:37
0

I think it is mlog(N) because you have to do m search operations (each time from root node downto target node), while the complexity of one single operation is log(N).

EDIT: @user1377000 you are right, I have mistaken amortized complexity from asymptotic complexity. But I don't think it is log(N)/m... because it is not guaranteed that you can finished all m search operations in O(logN) time.

What is amortized analysis of algorithms? I think this might help.

Community
  • 1
  • 1
quantumrose
  • 165
  • 2
  • 2
  • 8
  • Are you sure? Amortized complexity seems to be a kind of average. I'm not sure how though. – user1377000 Mar 14 '13 at 14:58
  • Well I think the worse case of a search is O(logN). So technically it should be O(log(N)/m). But I've also heard people saying it's O(log(N/m))... Perhaps if we don't search from the root every time, but remember the position. – user1377000 Mar 15 '13 at 07:36
0

In case of a balanced search tree the amortized complexity is equal to asymptotic one. Each search operation takes O(logn) time, both asymptotic and average. Therefore for m searches the average complexity will be O(mlogn).

SomeWittyUsername
  • 17,203
  • 3
  • 34
  • 78
0

Pass in the items to be found all at once.

You can think of it in terms of divide-and-conquer.

  1. Take the item x in the root node.
  2. Binary-search for x into your array of m items.
  3. Partition the array into things less than x and greater than x. (Ignore things equal to x, since you already found it.)
  4. Recursively search for the former partition in your left child, and for the latter in your right child.

One worst case: your array of items is just the list of things in the leaf nodes. (n is roughly 2m.) You'd have to visit every node. Your search would cost lg(n) + 2*lg(n/2) + 4*lg(n/4) + .... That's linear. Think of it as doing smaller and smaller binary searches until you hit every element in the array once or twice.

I think there's also a way to do it by keeping track of where you are in the tree after a search. C++'s std::map and std::set return iterators which can move left and right within the tree, and they might have methods which can take advantage of an existing iterator into the tree.

leewz
  • 2,863
  • 1
  • 14
  • 33