
\documentclass[12pt]{article}

\usepackage{fullpage}
\usepackage{graphicx}
\usepackage{clrscode3e}




\begin{document}

\title{Algorithms Lab 10}

\date{}
\maketitle

\vspace{-2cm}
\section*{ In lab}

% {\bf Prim's algorithm.}  In class we talked about the high-level idea
% of Prim's algorithm: 

% \begin{itemize}
% \item Start from an arbitrary vertex $v$. 
% \vspace{-.3cm}
% \item Consider all edges with exactly one endpoint in the current tree
%   and pick the one of minimum weight; add it to $T$.  Repeat. 
% \end{itemize} 

% To implement this, the main question is how to store the edges with
% one endpoint in $T$ so that we can select the minimum weight edge
% fast. Do you remember a data structure that can give us the
% smallest/largest element fast?  A priority queue!  Main ideas:

% \begin{itemize} 
% \item The priority queue will store all the vertices that are not in
%   $T$ yet;

% \item A vertex $v$ in the PQ has priority equal to the weight of the
%   minimum edge that connects $v$ with a vertex already in $T$. The
%   other endpoint of this edge is stored in $visit(v)$.

% \item Essentially the priority queue stores all edges that
%   \emph{cross} the cut between the vertices in $T$ and the vertices in
%   $V-T$ (If a vertex not in $T$ is connected by several edges to
%   vertices in $T$, the pq will store only one of these edges, the
%   smallest).

% \item Initially $T$ is empty and PQ contains all vertices in $G$ with
%   priority $\infty$, except an arbitrary vertex $v$ which has priority
%   $0$.

% \end{itemize} 


% The textbook implementation is the following: 

% %\vspace{1cm}
%  \fbox{
%     \parbox{12cm}{
%       {\bf PRIM(r)}\\
%       For each vertex  $u \in V, u \neq v, $:  {\sc Insert}($PQ,u,\infty$)\\
%       {\sc Insert}$(PQ,v,0)$, set $visit(v)=NULL$ \\
%       WHILE $PQ$ not empty DO
%           \begin{itemize}
%           \item[] $u$ = {\sc Delete-min}($PQ$)
%           \item[] For each $(u,v) \in E$ DO
%             \begin{itemize}
%             \item[] IF $v \in PQ$ and $w(u,v) < $ key($v$): 
%             \item[] ~~~~visit[$v$] = $u$
%             \item[] ~~~~{\sc Decrease-Key}($PQ,v,w(u,v)$)
%             \end{itemize}
%           \end{itemize}
%       Output edges $(u, visit(u))$ as the  MST
        
%   }}

%\newpage
\centerline{\includegraphics[height=5cm]{graph.jpg}}

\vspace{3cm}
\begin{enumerate} 
\item Show how Prim's and Kruskal's algorithms run on an example graph.
\item Prim's: 
  \begin{itemize} 
  \item What is the role of checking whether $v \in PQ$?
  \item How many  {\sc Insert} operations are performed by the algorithm? 
  \item How many  {\sc Delete-min} operations are performed by the algorithm? 
%  \item How many  {\sc Decrease-Key} operations are performed by the algorithm? 
  \item Assuming the priority is implemented as a heap, what is the complexity of the algorithm? 
  \item Consider a vertex $v$ that's not yet in the tree. Note that
    there may exist several edges that connect $v$ to a vertex in $T$; the smallest one of these edges will come out of the queue and will be added to the tree, and the rest of them will be discarded. 
    Can you think of a way to improve Prim's algorithm to store only
    the smallest one of these edges in the priority queue? What is the benefit of this idea? 
  \end{itemize} 
\item Kruskal's algorithm: Come up with a data structure that can hadle sets in the way  needed by Kruskal's algorithm. 

\end{enumerate} 


\newpage
\section*{Homework}

\begin{enumerate}

\item (CLRS 23.1-1) Show that a minimum-weight edge in $G$ belongs to
  some MST of $G$.

%  {\bf Answer: } It follows basically from the cut theorem: For any
%   cut $(V_1, V_2)$, the lightest edge that crosses the cut must be in
%   an MST. Consider a cut that places the two endpoints of the lightest
%   edge on two different sides of the cut. By the theorem, the edge
%   must be in an MST.
  
  \item (CLRS 24.2-4) Suppose that all edge weights in a graph are
  integers in the range from 1 to $|V|$.  How can you take advantage
  of this in Kruskal's algorithm, and how fast can you make it run?
  What if the edge weights are integers from 1 to $W$ for some
  constant $W$?

% {\bf Answer:} If we know that the edge weights are integers, we can
%   start thinking of using a more efficient sort, such as bucket-sort
%   or counting sort.  This runs in $O(n+k)$ time, where $n$ is the
%   number of inputs being sorted (in our case $|E|$) and $k$ is their
%   range (in our case $|V|$). In our case sorting the edge weights with
%   bucket-sort will take $O(V+E)$ time. 

%   In addition to the sorting Kruskal's algorithm uses a Union-Find
%   data structure, for $V$ Make-Set operations, $O(E)$ Find-Set
%   operations, and $O(V)$ Union-Set operations.  In class we talked
%   about how to store the sets as linked lists of elements pointing to
%   the first in the list, etc.  This way Make-set and Find-Set run in
%   $O(1)$ time, and Union-Set runs in amortized $O(\lg V)$
%   time. Overall this part of the algorithm will run in $O(E \lg V)$
%   time.

%  If you read the chapter in the textbook, you'll see that in fact a
%   much better bound for Union-Find operations can be obtained with a
%   very similar idea, namely $O(\alpha(V))$ amortized per operation;
%   here $\alpha(*)$ is the inverse Akermann function, and is very very
%   small, practically a constant. With this structure, Kruskal will
%   take $O(sort)$ + $O(E \alpha(V))$.  With a standard merge ($O(E \lg
%   E) = O(E \lg V)$ the sorting step will dominate.  When the edge
%   weights are integers in the range from 1 to $|V|$, sorting is
%   reduced to $O(V+E)$ and Kruskal runs in $O(E \alpha(V))$.


\end{enumerate} 

\end{document} 
