542 CSE Advanced Data Structures and Algorithms
Lab 1 Solution
Jon Turner
Part 1. The source code for this part appears below. Dheap.h (with unchanged parts omitted) ... class Dheap { public: ... // stats methods void clearStats(); string& stats2string(string&) const; private: ... // statistics counters int changekeyCount; int siftupCount; int siftdownCount; ... }; Dheap.cpp ... void Dheap::siftup(item i, int x) { int px = p(x); while (x > 1 && kee[i] < kee[h[px]]) { h[x] = h[px]; pos[h[x]] = x; x = px; px = p(x); siftupCount++; } h[x] = i; pos[i] = x; } ... void Dheap::siftdown(item i, int x) { int cx = minchild(x); while (cx != 0 && kee[h[cx]] < kee[i]) { h[x] = h[cx]; pos[h[x]] = x; x = cx; cx = minchild(x); siftdownCount += D; } h[x] = i; pos[i] = x; } ... void Dheap::changekey(item i, keytyp k) { changekeyCount++; -1-
keytyp ki = kee[i]; kee[i] = k; if (k == ki) return; if (k < ki) siftup(i,pos[i]); else siftdown(i,pos[i]); } ... /** Clear the statistics counters */ void Dheap::clearStats() { siftupCount = siftdownCount = changekeyCount = 0; } /** Return a string representation of the statistics counters. * @param s is a string in which the result is returned * @return a reference to s */ string& Dheap::stats2string(string& s) const { string s1; s = "changekeyCount = " + Util::num2string(changekeyCount,s1) + " "; s += "siftupCount = " + Util::num2string(siftupCount,s1) + " "; s += "siftdownCount = " + Util::num2string(siftdownCount,s1); return s; }
-2-
Part 2. The table below shows the counter values, the values of d for each case, the maximum depth of the heap and the upper bounds on the counter values. 4K changekeyCount siftupCount siftdownCount d heap depth changekeyBound siftupBound siftdownBound 1,301 2,292 18,798 6 4 4,000 20,000 24,000 10K 2,213 1,790 29,592 12 3 10,000 33,000 36,000 20K 2,980 1,431 44,352 22 3 20,000 63,000 66,000 40K 3,575 1,225 75,852 42 2 40,000 82,000 84,000 100K 4,533 1,048 170,952 102 2 100,000 202,000 204,000 200K 5,165 882 297,950 202 2 200,000 402,000 404,000 400K 5,860 672 486,018 402 2 400,000 802,000 804,000
The changkeyBound is equal to the number of edges in the graph, the siftupBound is computed by multiplying ((# of inserts=1,000) + (the changekeyBound)) times the maximum heap depth and the siftdownBound is computed by multiplying the number of deletemin operations (1,000) times the product of d and the heap depth. The changekeyCount values are much smaller than the bounds. This apparently reflects the fact that when a new edge (u,v) is examined by Prim's algorithm, most of the time, the new edge is more expensive than cheap(v). This is a direct consequence of the fact that in the random graphs used here, the edge costs are random. In order to achieve the worst-case bound, the algorithm must examine the edges incident to a vertex in decreasing order of their cost, and this is not likely to occur when edge costs are random. We find that the examination of most edges does not trigger a call to changekey. The difference is quite striking. For the densest graphs, changekey is called for only about 1.5% of the edges. The siftupCount values are smaller than expected largely because they are directly dependent on the number of calls to changekey. However, we find that this only partly explains the difference, since the worst-case analysis would lead us to expect the number of siftup iterations to be equal to the number of changekeys times the depth of the heap. In fact, the number of siftup iterations is usually smaller than the number of changekeys, reflecting the fact that normally when we do a changekey, we end up not actually moving the item in the heap at all. The siftdownCount values behave in a way that is generally consistent with the worst-case bound. While they are a bit smaller than the bounds, they do grow in proportion with the bounds and are only smaller by a small constant factor. This reflects two factors. First, the siftdown is called once per deletemin and this number is n 1 for all graphs. It also appears that the number of iterations tends to more closely match the heap depth in this case than for the siftdowns. This makes sense, since we're always doing a siftdown from the top of the heap, and -3-
its likely that the item being "sifted" will need to move most of the way down the heap in order to satisfy the heap-ordering condition.
-4-
Part 3. The table below shows the counter values, the values d of for each case, the maximum depth of the heap and the upper bounds on the counter values. 4K changekeyCount siftupCount siftdownCount d heap depth changekeyBound siftupBound siftdownBound 1301 5,751 14,056 2 9 4,000 36,000 18,000 10K 2,213 6,543 14,606 2 9 10,000 90,000 18,000 20K 2,980 7,205 14,674 2 9 20,000 180,000 18,000 40K 3,575 7,919 14,760 2 9 40,000 360,000 18,000 100K 4,533 8,504 14,760 2 9 100,000 900,000 18,000 200K 5,165 8,848 14,760 2 9 200,000 1,800,000 18,000 400K 5,860 9,427 14,768 2 9 400,000 3,600,000 18,000
In this case, the changekeyCount values are the same as before. There is some increase in the siftupCount values, since the smaller value of d makes it more likely that a changekey will move an item at least a few positions in the heap. The siftdownCounts are dramatically smaller in this case (as are the bounds) due to the smaller value of d. These results make it clear that for the random graphs used here, a choice of d=2 is better than a value that increases with the graph density. The dramatic reduction in the siftdownCounts should translate to a significant improvement in the running time for the densest graphs. Of course, the worst-case results remain valid, and it is certainly possible that there are some graphs for which we may be better off using a value of d that increases with the edge density.
-5-
Part 4. The source for the alternate version of Prim's algorithm appears below. /** Find a minimum spanning tree using Prim's algorithm. * This version uses a Fibonacci heap * @param wg is a weighted graph * @param mstree is a second weighted graph data structure in * which the result is to be returned; it is assumed to have * no edges */ void primF(Wgraph& wg, Wgraph& mstree) { vertex u,v; edge e; edge* cheap = new edge[wg.n()+1]; Fheaps nheap(wg.n()); fheap root; bool *inHeap = new bool[wg.n()+1]; //inHeap[u]=true if u in heap int numInHeap = 0; for (u = 1; u <= wg.n(); u++) inHeap[u] = false; e = wg.firstAt(1); if (e == 0) return; root = wg.mate(1,e); do { u = wg.mate(1,e); root = nheap.insert(u,root,wg.weight(e)); cheap[u] = e; inHeap[u] = true; numInHeap++; e = wg.nextAt(1,e); } while (e != 0); while (numInHeap > 0) { u = root; root = nheap.deletemin(root); inHeap[u] = false; numInHeap--; e = mstree.join( wg.left(cheap[u]), wg.right(cheap[u])); mstree.setWeight(e,wg.weight(cheap[u])); for (e = wg.firstAt(u); e != 0; e = wg.nextAt(u,e)) { v = wg.mate(u,e); if (inHeap[v] && wg.weight(e) < nheap.key(v)) { root = nheap.decreasekey(v,nheap.key(v) wg.weight(e),root); cheap[v] = e; } else if (!inHeap[v] && mstree.firstAt(v) == 0) { root = nheap.insert(v,root,wg.weight(e)); cheap[v] = e; inHeap[v] = true; numInHeap++; } } } delete [] cheap; delete [] inHeap; }
-6-
Part 5. The table below shows the average running times for the two versions of Prim's algorithm in milliseconds for graphs with 10,000 vertices and edge counts ranging from 20 K to 1M. This is averaged over 10 runs. 20K prim primF 5 10 50K 6 16 100K 16 25 150K 27 37 200K 39 48 300K 62 71 400K 84 97 500K 105 115 750K 159 169 1M 214 221
It is interesting to note that the version using Fibonacci heaps is consistently slower than the version using d-heaps. This most likely reflects the greater overhead associated with the F-heap data structure. The intrinsic simplicity of the d-heap gives it a significant "constant factor" advantage. It's also worth noting that even though the number edges in the graphs grows by a factor of 50, going from the smallest to the largest, the running time in the d-heaps case grows by a factor of 43 and the running time of the F-heaps case grows by a factor of 22. This is because not all of the running time grows as m grows. For the F-heap case, it appears that for the smallest graphs, the fraction that increases with m represents about half of the total. This reflects the fact that the number of changeKeys is so small that most of the growth in the running time comes just from the overhead of the inner loop, not the actual heap operations. For the d-heap case, the running time does increase almost as much as the number of edges. This suggests that the term that grows with m accounts for most of the running time even for the smallest graphs. Why is this, given that in both cases, the number of changeKey operations is small, so the cost associated with inner loop should be about the same in both cases? The reason is that the choice of d causes the running times of the deleteMins to increase with m.
-7-