12

I'm learning f-heap from 'introduction to algorithms', and the 'decrease-key' operation really confuses me -- why does this need a 'cascading-cut' ?

if this operation is removed:

  1. the cost of make-heap(), insert(), minimum() and union() remains obviously unchanged
  2. extract-min() is still O(D(n)), because in the O(n(H)) 'consolidate' operation, the cost of most rooted trees can be payed when they were added to the root list, and the remaining costs O(D(n))
  3. decrease-key(): obviously O(1)

As for D(n), though i can't explain it precisely, i think it is still O(lgn), cuz without 'cascading-cut', a node may just be moved to root list a bit later, and any node hides under its father does not affect the efficiency. At least, this will not make the situation worse.

apologize for my poor english :(

anyone can help? thanks

templatetypedef
  • 328,018
  • 92
  • 813
  • 992
exprosic
  • 620
  • 5
  • 15
  • Great question. It seems very unintuitive to just throw away all the information that is in the position of the parent. – Thomas Ahle Jun 14 '14 at 14:45

1 Answers1

8

The reason for the cascading cut is to keep D(n) low. It turns out that if you allow any number of nodes to be cut from a tree, then D(n) can grow to be linear, which makes delete and delete-min take linear time.

Intuitively, you want the number of nodes in a tree of order k to be exponential in k. That way, you can have only logarithmically many trees in a consolidated heap. If you can cut an arbitrary number of nodes from a tree, you lose this guarantee. Specifically, you could take a tree of order k, then cut all of its grandchildren. This leaves a tree with k children, each of which are leaves. Consequently, you can create trees of order k with just k + 1 total nodes in them. This means that in the worst case you would need a tree of order n - 1 to hold all the nodes, so D(n) becomes n - 1 rather than O(log n).

Hope this helps!

templatetypedef
  • 328,018
  • 92
  • 813
  • 992
  • Yeah, you're right. This misleading D(n) does cause a problem, but that doesn't appear when the D(n) children's parent is extracted (the reason i wrote is above). It appears **when their parent is choosing its parent** during 'consolidate' -- wrong D() causes unbalance. Now consider, if, after decrease a key with cas-cut, I can maintain all the D(n) just as i DID the cas-cut, that is, D() may be smaller than the amount of children -- the complexity of extract-min is still O(lgn). It's hard to maintain exactly the same D(), but I think there's another way to maintain the balance: – exprosic Apr 11 '13 at 11:36
  • every node have a S : initially, it's the size of the node. Obviously, it's exponentation of 2 -- in binary notation, 10..000. When its child is removed, and **the number of its bits** ([log2(S)]) decreased (1000->111, 1011->101, etc), it report the difference to its parent. When the difference is big enough to decrease the parent's [log2(s)], the difference is reported to grandparent, and so on. – exprosic Apr 11 '13 at 11:37
  • The same point is to hide the decrease of nodes to parent, but keep the relation between S(or D) and real amount of nodes (tree with S has at least S/2 nodes) in O(1) time, and during consolidate, use S/D to keep balance (combine nodes with same D, or same [log2(S)]). Is that right? – exprosic Apr 11 '13 at 11:37
  • FIX: in comment 1: after decrease a key with cas-cut -> after decrease a key **without** cas-cut (i mean, it acts just like using a cas-cut-fib-heap to maintain all the D() filed in my non-cas-cut-fib-heap) – exprosic Apr 11 '13 at 11:48
  • @exprosic- I think that there are two separate questions here. The first - why do Fibonacci heaps do cascading cuts? - I tried to answer above. Your second question - could we do this another way? - is a really interesting one, but I think it's probably not the best fit for Stack Overflow. You might want to describe your approach in detail at either cs.stackexchange.com or cstheory.stackexchange.com so that more expert computer scientists could look over it. – templatetypedef Apr 11 '13 at 22:02