
\section{Introduction}

\Link is a flexible environment for the creation, manipulation, and 
drawing of graphs and hypergraphs.  This chapter will
describe the basic architecture of the system and illustrate its
flexibility with several examples.  These descriptions will be
accompanied by commentary on the associated design decisions,
but will certainly not be exhaustive.  The \Link manual fills in the details.
\Link is distinguished from existing software for discrete mathematics 
by its layered interface, including a graphical user interface 
tied into an object-oriented Scheme language interface which incorporates 
to graphics, and an extensible underlying set of C++ libraries.  This 
selection of
interface first and foremost ensures that the interface is customizable,
but also provides a large degree of platform independence.  \Link 
currently runs on Unix and Microsoft Windows operating systems. 
The command language interface is much friendlier and more flexible 
than the ``scripting'' or ``prototyping'' 
facilities typical of other graph visualization software; indeed, it is
an integral part of any \Link session.  Unlike any existing system for
discrete mathematics, \Link combines a computing environment comparable to
those of the familiar symbolic mathematics packages with graph editing
facilities.

\section{Background}
%\trtwel{ {\bf 1 \ Background}}

\trnine{}


Over the past several years, there have been many efforts to construct
software systems for discrete mathematics, and in particular, for the
manipulation of graphs.  None, however, has resulted in a product with
influence comparable to the familiar symbolic mathematics
packages.

Some notable existing systems for discrete mathematics are 
{\em Combinatorica}~\cite{Ski90},
Steven Skiena's extension package for {\em Mathematica}, 
{\em NETPAD}~\cite{MDM90}
due to Nathaniel Dean and others at Bellcore, 
{\em SetPlayer}~\cite{BCGR92},
due to Mark Goldberg and his students at Rensselaer Polytechnic Institute,
and Gregory Shannon et. al.'s {\em GraphLab}~\cite{SMF90}.   For various
reasons, none of these
systems has the potential to be a widely-useful environment for both
graph manipulation and computation.  
The authors of these systems recognized this and proposed the development
of \Linkn, a freely available
and portable software system for discrete mathematics overcoming
the various shortcomings of existing systems.
After three years of development, the system, which includes
a 200 page on-line manual and an on-line tutorial, is now freely available
from the \Link web site:
\begin{center}
\verb+http://dimacs.rutgers.edu/Projects/LINK.html+.  
\end{center}



\Link's design philosophy placed flexibility as the highest priority,
and this led to the selection of STk, Erick Gallesio's 
object-oriented Scheme language interface to John Ousterhout's portable,
interpretive Tk graphics system.~\cite{Ous94}\cite{eg95}.  Tk enables
involved graphics programming without any knowledge of underlying
graphical systems such as X-windows,
and offers the advantages of interpretation and portability at the cost
of speed.  This means that the system is not appropriate for viewing 
massive data sets. Graph views with a few thousand objects have
been used, but these took several minutes to load on a Sparcstation 5.

Several other graph manipulation systems have been designed using
Tk, including 
Graphlet~\footnote{See http://fmi.uni-passau.de/himsolt/Graphlet.}, 
which is built on top of the LEDA C++ 
library~\cite{MeN95}.  However, these systems rely on Tcl,
a language more similar to operating system shell scripting 
languages than high-level programming languages.
\Linkn's command interface, on the other hand, offers the mathematician or 
computer scientist a high-level 
Scheme language interface with an object-oriented front-end to Tk.
Scheme is a compact, standardized dialect of 
Lisp, a functional language useful for symbol manipulation.

The remainder of the paper is broken into sections describing \Linkn's
architecture, its layered interface, its
its flexibility, and its roles in research and education.

\section{\Linkn's Templated C++ Libraries}

Underlying the \Link system is a set of object-oriented C++ libraries 
designed to offer a rich and coherent set of graph and collection objects
to support programming in the pursuit of discrete mathematics research.

\subsection{\Collections\  and \Containers}

The basis of the \Link system is a set of classes grouped into two
hierarchies:  \Collection\ and \Container.  The \Collection\ hierarchy
consists of multisets (bags), sets, and sequences, while the \Container\
hierarchy is subdivided into data structures such as lists and arrays and
keyed dictionary structures such as binary heaps, red-black trees, etc.
As in the Standard Template Library (STL), the glue that binds all container
and collection objects is the \Iterator.  STL was not
mature enough at system design time to be used, and even had it been, we
might not have employed it since our \Collection\ hierarchy offers some
flexibility that STL does not.  \Linkn's \Iterator\ object
can be used to retrieve the elements of any \Collection\ or \Container,
and has been used to create a robust set of constructors and assignment
operators which allow the easy transfer of data between any two 
collection or container objects.

The hierarchies of \Collection\ and \Container\ classes give library
programmers a common interface for performing simple operations such
as copying, assignment, insertion, deletion, extraction, 
comparison, display of values, 
and the set primitive operations.  Also available are standard queries
such as membership and whether or not the structure is empty, sorted, 
a permutation, or a subset of another.

\input{cont}

\input{coll}

\subsection{The Graph Hierarchy}

\begin{figure}[tbh]
\centerline{\psfig{width=3.335in,figure=figures/graph_hier.ps}}
\caption{This figure shows \Linkn's
hierarchy of {\em simple graphs}.  Not shown is another
hierarchy of {\em multigraphs} with the same structure, in which 
each class other than \Graph\ is duplicated, and multiple occurrences
of edges are allowed.}

\label{fig:graph-hier}
\end{figure}

The \Collection\ hierarchy allows the definition of a variety of 
graph objects.  These are also arranged into a hierarchy, depicted
in Figure~\ref{fig:graph-hier}  so that objects
from different graph classes can interact. 
As in the \Collection\ hierarchy, objects of the \Graph\ hierarchy  
can be copied and assigned gracefully.  The classes of the \Graph\
hierarchy are shown in Figure~\ref{fig:graph-hier} and 
will be introduced below.  In this figure, each graph type is
accompanied by the type of object used to store an edge.  For example,
each edge in a {\em HyperGraph} is a \Collection, i.e., either a 
multiset or a sequence.

\subsubsection{Graph Types}
The central goals of \Linkn's design philosophy are that many different
graph types should be available to the user and that algorithms need 
only be written once to work on many types of graph.  The \Collection\
hierarchy has been used extensively to meet both goals, with the
result that \Link users may now select between 12 types of graph by 
specifying the
edge type.  An edge is a collection of vertices, and the \Collection\
hierarchy enables us to offer graph types, classified
by the following pertinent questions:
\label{sec:graph}

	\begin{itemize}
	\item	{\bf Multigraph or not?}  
		Multiple edges between the same vertices can be allowed or not.
	\item   {\bf Binary Graph or Hypergraph?} 
		Edges can be defined as groups of two vertices or not. 
		Relaxing this restriction results in hypergraph objects. 
	\item   {\bf Directed, Undirected, or Mixed Graph?}  
		Each edge is either a 
		multiset or a sequence of vertices.  Graphs can either 
		limit their
		edge sets to undirected edges or directed edges, or they can
		make no such restriction.  The result of the latter is a
		set of graph types in which a single graph object instance
		might contain both directed and undirected edges.
	\end{itemize}


\begin{figure}[bth]
%\centerline{\includegraphics*[width=3.335in]{mhg}}
\centerline{\psfig{width=3.335in,figure=mhg.ps}}
\caption{A ``mixed'' hypergraph}
\label{fig:mhg}
\end{figure}

A {\em directed} hyperedge has been defined to be a set of vertices in
which
one vertex is specified to be a ``sink,'' and the other vertices are
assumed to precede
that vertex~\cite{M90}.  We give a more general definition:  a directed
hyperedge is simply a sequence of vertices.  A ``mixed'' 
hypergraph is shown in Figure~\ref{fig:mhg}, and a ``mixed'' binary
graph with multiple edges is shown in Figure~\ref{fig:mbmg}.  
Figure~\ref{fig:mhg} is particularly interesting since it illustrates the
two different modes for displaying hyperedges.  Edge {\em e1} has
been thickened for clarity, and edge {\em e0} is
drawn using {\em star draw} mode, in which edge segments radiate from a
central, draggable edge label.  The other two edges are displayed using
{\em path draw} mode, in which identically-labeled edge segments connect
the vertices of the hyperedge.  The complete order of vertices within a 
{\em directed} hyperedge, however,  will only be visible if the path draw 
display mode is used.
The graphical user interface described below in Section~\ref{sec:GUI}
 allows the user to change the edge display mode for the whole graph 
or some selected subset of the edges.  

\begin{figure}[tbh]
%\centerline{\includegraphics*[width=3.335in]{mbmg}}
\centerline{\psfig{width=3.335in,figure=mbmg.ps}}
\caption{A ``mixed'' binary multigraph}
\label{fig:mbmg}
\end{figure}

Figure~\ref{fig:DBinGraph2} shows a complete \Link\ program which
illustrates iteractions between graph types.  An multigraph with
directed edges (MDBinGraph) is built, then several other graphs of
different types receive copies of the original graph subject to 
their own rules.  Note that the simple graphs automatically remove
multiple occurrences of edges, and that undirected edges correspond
to directed edges during the copy.  The call to \verb+DepthFirstSearch+
works for all of the graph types since it is implemented the \Graph\ 
hierarchy's primitive methods, to be described below, are all
polymorphic.

\begin{figure}[tbh]
\input{ProgDBinGraph2}
\caption{Building graphs,  copying graphs, and running algorithms}
\label{fig:DBinGraph2}
\end{figure}

It is fair to ask why algorithms in \Link\ are defined as standalone
functions rather than \Graph\ methods.  This might seem reasonable
at first glance, but the system would be less flexible, were it organized
that way.  As it is, algorithms can be added to the library without
modifying the interface of the \Graph\ hierarchy.  Furthermore, the
latter is flexible enough to provide for algorithms to be written
once, yet run on many graph types.


\subsubsection{Graph Methods}

All graph objects have the same core functionality, and the member 
functions implementing this functionality can be broken down
roughly as follows:
\begin{itemize}
	\item Predicates indicating whether the graph is mixed, directed,
	or undirected, whether multiple edges are allowed, and whether
	hyperedges are allowed.
	\item Vertex and edge manipulation routines such as the insertion 
	and deletion of vertices and edges, either as individuals or in
	groups.
	\item Queries to determine properties of the graph such as
	order and size, whether
	or not it is directed, binary, simple, etc., whether or not two
	vertices are adjacent, and whether or not the graph is isomorphic
	to another.  The latter test uses {\em nauty}, Brendan McKay's 
	well-known and practical isomorphism testing tool.~\cite{mck90}. 
	\item Routines to find groups of vertices and edges such as
	the neighbors and incident edges of a given vertex.
	These routines use \Collection\ functionality to return appropriate
	answers for undirected, directed, and mixed graphs.  Also included
	are routines to return the sequence of edge objects associated with
	a path of vertices and vice versa.
	\item Input and output operations for graphs, vertices, and edges, 
	both to and from files and the screen.  Note: \Linkn's graph
	language, fully specified in the manual, is similar in flavor
	to Graphlet's GML~\cite{h96}, but explicitly stores a graph's
	attributes along with it rather than separating them into maps to
	be applied later.  A better graph definition language is needed,
	in which data types can be defined, and attribute values of these
	types declared.  \Link's parser automatically recognizes data
	of type \verb+int+, \verb+double+, and \verb+String+.
	\item Conversion and construction operations which take sets of
	vertices and edges and produce graph objects.  This set of 
	routines also can convert into adjacency or incidence matrix
	representation.
	\item Edge comparison routines -- two edges are comparable if they
	contain the vertices of the same name in the same order.  Inequalities 
	are resolved using lexicographic ordering.
\end{itemize}

Multigraphs also feature subgraph collapsing and extracting methods which
are supported by the graphical user interface.  These are useful when
studying properties which are defined in 
terms of graph contractions, such as the chromatic polynomial.

\subsection{Attributes}

\Link provides a mechanism for creating and manipulating attributes of graphs, 
vertices, and edges.  The default attributes for all graph objects (including
vertices and edges) are currently {\em name, direction, width, size, weight, x, 
y, color,
label, mark, type, starttime, finishtime, back, low, distance, pred}, and
{\em forefather}.  To save space, the attribute mechanism stores a 
single copy of each attribute for the entire graph until individual 
attributes are changed (at which point an individual copy is made for the
affected object).  Some of the default attributes are used by the graphical
user interface, and some are used by fundamental graph algorithms.  If 
different attributes are desired, however, defining
new attributes is simple, both for the library programmer and the 
interface user.

\begin{figure}[tbh]
\begin{flushleft}
\hrulefill
{\scriptsize
\begin{alltt}
STk>  {\bf (describe (graph (current-graph-view))) }{\em{
\(\#\)[\(<\)dbingraph*\(>\) \(\#\)p63f5cc] is an instance of class \(<\)dbingraph*\(>\)
Slots are: 
     val = \(\{\)[1 2 3 4 5 6]  \(\{\)\(<\)1 2\(>\) \(<\)1 6\(>\) \(<\)2 5\(>\) \( <\)3 4\(>\) \(<\)5 3\(>\) \(<\)5 6\(>\)\(\}\)\(\}\)
\(\#\)f} }
STk>  {\bf (map color (vertices (current-graph-view))) }{\em{
("black" "black" "black" "black" "black" "black")} }
STk>  {\bf (define vg(car(vertices(current-graph-view)))) }{\em{
\(\#\)[undefined]} }
STk>  {\bf (set! (color vg) ``green'')  }{\em{
\(\#\)[undefined]} }
STk>  {\bf (map color (vertices (current-graph-view))) }{\em{
("green" "black" "black" "black" "black" "black")} }
\end{alltt}
}
\hrulefill
\end{flushleft}
\caption{This Scheme code segment retrieves and manipulates the 
attributes of
the graph of the current {\em graph-view}~(window) after the user 
has constructed a graph in it.}
\label{fig:graph-view}
\end{figure}

\section{The STk Interface}

STk is a complete programming environment in itself, and \Link inherits
all of its functionality.  In addition to a standard $R^4RS$ Scheme 
interpreter,
STk provides an object-oriented extension based on the Common Lisp Object
System called STklos, as well as operating system 
shell access, regular expression processing, and Unix socket handling.
  The STklos extension enables the scheme programmer to
define classes and generic functions, and \Linkn's interface takes full
advantage of this power.  All of the basic \Link objects have been
``wrapped'' into the STk interpreter so that users can create, manipulate,
and destroy them, and \Linkn's graphical user interface consists exclusively
of new STklos classes so that users may take advantage of high-level,
object-oriented functionality to manipulate their data.

\subsection{\Linkn's STklos Objects}

\begin{figure}[tbh]
\begin{flushleft}
\hrulefill
{\scriptsize
\begin{alltt}
STk>  {\bf (define gv (show-graph (graph '(1 2 3) '((1 2) (2 3) (1 3))))) }{\em{
\(\#\)[undefined]} }
STk>  {\bf (define g (graph gv)) }{\em{
\(\#\)[undefined]} }
STk>  {\bf (define eg (car (edges gv))) }{\em{
\(\#\)[undefined]} }
STk>  {\bf (define e (edge eg)) }{\em{
\(\#\)[undefined]} }
STk>  {\bf eg }{\em{
\(\#\)[\(<\)edge-item\(>\) \(\#\)p64ba68]} }
STk>  {\bf e }{\em{
\(\#\)[\(<\)edge*\(>\) \(\#\)p64c7a0]} }
STk>  {\bf (set! (weight eg) 3.21) }{\em{
\(\#\)[undefined]} }
STk>  {\bf (find-double-attribute 'weight e) }{\em{
3.21} }
STk>  {\bf (set-double-attribute! 'weight 2.1 e) }{\em{
\(\#\)[undefined]} }
STk>  {\bf (weight eg) }{\em{
2.1} }
\end{alltt}
}
\hrulefill
\end{flushleft}
\caption{Fundamental attribute operations}
\label{fig:objects}
\end{figure}

The \Link interface user has access to graph objects at both the graphical
user interface level and the Scheme command language level.  \Linkn's 
manual contains dozens of Scheme programming examples, and we will 
include some herein.  Figure~\ref{fig:graph-view} contains 
Scheme code to retrieve the colors of the vertices that a user has
created using the graphical interface.   The example subsequently
changes the color of the first vertex, a change reflected graphically
on the screen.  Note that {\em vg} is an STklos object which contains 
both a graphics field (displayed on the screen) and a reference to
an underlying C++ vertex object.  STklos gives users the considerable
convenience of setting fields (or ``slots'') using the {\em set!} 
primitive.  The expression \verb+(color vg)+ is a shorthand way of 
extracting the ``color'' field from the vertex.

\begin{figure}[tbh]
\begin{flushleft}
\hrulefill
{\scriptsize
\begin{alltt}
STk>  {\bf (define gv (show-graph (graph '(1 2 3)
                       '((1 2) (2 3) (1 3))))) }{\em{
\(\#\)[undefined]} }
STk>  {\bf (map weight (edges gv)) }{\em{
(1.0 1.0 1.0)} }
STk>  {\bf (random-edge-weights (graph gv)) }{\em{
\(\#\)[\(<\)ubingraph*\(>\) \(\#\)p63c0c0]} }
STk>  {\bf (map weight (edges gv)) }{\em{
(38.0 58.0 13.0)} }
STk>  {\bf (define mst (kruskal (graph gv))) }{\em{
\(\#\)[undefined]} }
STk>  {\bf (describe mst) }{\em{
\(\#\)[\(<\)set\(<\)edge*\(>\)\(>\) \(\#\)p6f1c98] is an instance of class \(<\)set\(<\)edge*\(>\)\(>\)
Slots are: 
     val = \(\{\)\(\{\)1 2\(\}\) \(\{\)2 3\(\}\)\(\}\)
\(\#\)f} }
STk>  {\bf (map (lambda (x) (find-double-attribute 'weight x))
                (set-edge\(->\)list mst)) }{\em{
(38.0 13.0)} }
\end{alltt}
}
\hrulefill
\end{flushleft}
\caption{Scheme code to call an algorithm and
	examine the results.}
\label{fig:mst}
\end{figure}

The fundamental STklos graph objects of the \Link system correspond
to the graph types described in Section~\ref{sec:graph}:
{\em vertex, edge, graph, bingraph, dbingraph, ubingraph, hypergraph, 
uhypergraph, dhypergraph mbingraph, mdbingraph, mubingraph, mhypergraph, 
muhypergraph, and mdhypergraph}.  These and their most important 
methods are available to the \Link interface user, and detailed in 
the manual.  

The \Link objects mentioned above are mirrored by special STklos graphics 
objects.  The most important correspondences are those between
classes representing the fundamental graph objects.  The three most
important STklos classes in \Link are:
\begin{itemize}
	\item {\em graph-view}: a window which contains a 
	\Link {\em graph} object.
	\item {\em vertex-item}: a class containing an STklos 
		graphics object and a \Link {\em vertex} object.
	\item {\em edge-item}: a class containing (potentially many) 
	STklos {\em line} graphics
	objects and a \Link {\em edge} object.
\end{itemize}
Figure~\ref{fig:objects} illustrates the difference between STklos graphics
objects and \Link objects.  In this example, a graph is defined and displayed
in a {\em graph-view} window called {\em gv}.  The method {\em (graph gv)}
returns the \Link graph object associated with this graph-view.
The
example then extracts the first {\em edge-item} from the graph-view and
extracts the {\em edge} associated with that edge-item.  STklos supports
``virtual'' data within a class, and the \Link interface takes advantage of
this by inseparably linking the attributes of the edge to those of the 
edge-item.  When the user evaluates or modifies an attribute of the edge-item,
such as its weight, that request is translated into an evaluation or 
assignment to the corresponding attribute of the underlying edge.  For
example, In figure~\ref{fig:objects}, changes to the edge-item's 
weight attribute are reflected in the edge's weight attribute and vice 
versa.


Figure~\ref{fig:mst} shows a more detailed example in which a graph
is created and displayed, its edges are assigned random weights,
and a minimum spanning tree is computed, extracted, and manipulated.
This example illustrates two different levels of attribute retrieval:
directly from a graphics object, and via a \Link object.  The former method 
is used in the command {\em (map weight (edges gv))}, which extracts
the {\em weight} slot from each STklos edge object in the graph window
called {\em gv}.  Note that {\em mst}, the variable used to store the
result of the spanning tree algorithm, is a \Link {\em set} object. This 
is converted into a Scheme list using the {\em set-edge$\rightarrow$list} 
method (provided with all collection objects).

\begin{figure*}[tbh]
\hrule
{\scriptsize
\begin{alltt}
(define (forefather-binding graph-view)
 (strongly-connected-components (graph graph-view))
 (bind (slot-ref graph-view 'graph-toplevel) "<KeyPress-f>"
      (lambda (x y) 
           (flash (vertex-item 
                 (find-vertex-attribute 'forefather 
                    (slot-ref (car *link:selected-vertex-items*) 'vertex)) graph-view)))))
\end{alltt}
}
\hrule
\caption{This complete code segment binds the ``f'' key so that the 
	forefather of 
	a selected vertex is flashed.  The strongly-connected-components
	algorithm sets an attribute called {\em forefather} that is
	subsequently retrieved to decide which vertex to flash.}
\label{fig:ff-code}
\end{figure*}

It is legitimate to ask why \Linkn's \Collection\ objects are at all useful in
a list-based Scheme interpreter (why not just have all algorithms return 
Scheme lists?).  Figure~\ref{fig:new-graph} provides an answer.  Many of
\Collection's methods, including the copying, insertion, deletion, query, 
and set primitive operations are available from the STklos interface.
The example in Figure~\ref{fig:new-graph} is a simple graph sum computation
using the set primitive operations.
\begin{figure}[tbh]
\begin{flushleft}
\hrulefill
{\scriptsize
\begin{alltt}
STk>  {\bf (define g (graph '(1 2 3) '((1 2) (2 3) (3 1)))) }{\em{
\(\#\)[undefined]} }
STk>  {\bf (define h (graph '(2 3 4) '((2) (2 3 4) (3 4))))  }{\em{
\(\#\)[undefined]} }
STk>  {\bf (define ng (graph (+ (vertices g) (vertices h)) 
                              (+ (edges g) (edges h)))) }{\em{
\(\#\)[undefined]} }
STk>  {\bf (describe ng) }{\em{
\(\#\)[\(<\)uhypergraph*\(>\) \(\#\)p63e848] is an instance of class \(<\)uhypergraph*\(>\)
Slots are: 
     val = \(\{\)[1 2 3 4]  \(\{\)\(\{\)1 2\(\}\) \(\{\)1 3\(\}\) \(\{\)2\(\}\) \( \{\)2 3\(\}\) \(\{\)2 3 4\(\}\) \(\{\)3 4\(\}\)\(\}\)\(\}\) 
\(\#\)f} }
\end{alltt}
}
\hrulefill
\end{flushleft}
\caption{An example which uses \Collection\ methods}
\label{fig:new-graph}
\end{figure}

\subsection{Graphical User Interface}
\label{sec:GUI}

STklos provides a core set of graphics classes (windows, labels, buttons, etc.)
which make interface customization a high-level operation, and \Linkn's 
graphical
interface consists of a set of classes which inherit from these.
The result is that standard graph operations such as 
graph creation, insertion and removal of vertices and edges, execution
of algorithms, and animation viewing are both point and click
features and high-level STklos operations.  
Multiple graph windows can be viewed at once, and multiple
algorithm animations can be stepped through side-by-side for comparison.
Graphics attributes such as world coordinates, size, arrow shape, label, 
color, text-color, stipple, outline width, outline color, and font can
be evaluated and changed easily.

{\em It is important to note that any command in the graphical user interface 
corresponds to a STklos command that could have been typed into the command
line prompt.}  This makes \Link a powerful environment for systematically
constructing, executing, viewing, modifying, and rerunning experiments.
This interface has been used in several research projects, and two will
be abstracted in Section~\ref{sec:research}.

\subsection{Flexibility}
Consider the following example of the interface's flexibility.  When describing
the strongly connected components of a directed graph, it is important to 
relate
the concept of the {\em forefather} of a vertex.  Simply stated, the
forefather $\phi(v)$ of a vertex $v$ with respect to a depth-first search
is the vertex reachable from $v$ which has the maximum finishing time in the 
depth-first search.  \Linkn's
interface can easily be tailored to illustrate the concept 
intuitively.
Figure~\ref{fig:ff-code} shows, in its entirety, the STKlos code necessary
to ``bind'' the {\em f} key on the keyboard to a function which will
flash the forefather of a vertex selected with the mouse.  
Figure~\ref{fig:ff-lab} shows a graph-view in which a depth-first search
\begin{figure}[t]
%\centerline{\includegraphics*[width=3.335in]{ff_labeled}}
\centerline{\psfig{width=3.335in,figure=ff_labeled.ps}}
\caption{Forefather finding with finishing times depicted}
\label{fig:ff-lab}
\end{figure}
has been run and the discovery and finishing times of the vertices are
displayed.  Selecting a vertex, then pressing the {\em f} key highlights
a vertex's forefather by flashing it several times.

\subsection{Animations}


When \Link algorithms are added to the C++ libraries, they can be
augmented with special animation commands which modify the attributes
of the graph's vertices and edges.  These commands are executed if the
algorithm is run from the interface (as opposed to being run from a 
standalone C++ program using \Linkn's libraries).   
Algorithms selected from a graph-view bring
up an animation controller/debugger which allows the user to step through
the algorithm forwards and backwards, set breakpoints, continue, and
restart.  An example animation of a depth-first search is shown in
Figure~\ref{fig:anim}.

\section{Algorithms, Generators, and Layouts}

\Linkn's libraries include several fundamental algorithms for manipulating,
generating, and drawing graphs, including depth and breadth-first search,
Kruskal's and Prim's minimum spanning tree algorithms, Goldberg \& Tarjan's
maximum flow algorithm, strongly connected components, generators for
random graphs, cycles, complete graphs and grid graphs, and circular,
random, grid, spring, and component-wise layout algorithms.   This 
algorithms library will certainly grow as the system develops and new
versions are distributed.  If the reader is interested in contributing
to this effort, please contact Jonathan Berry at \verb+berryj@numen.elon.edu+.

\begin{figure}[tbh]
%\centerline{\includegraphics*[width=3.335in]{dfs}}
\centerline{\psfig{width=3.335in,figure=dfs.ps}}
\caption{The animation controller}
\label{fig:anim}
\end{figure}

\section{Research Examples}
\label{sec:research}

\Link has already demonstrated its usefulness in research, and
its role in two recent projects will be summarized below.

\subsection{Latka Tournaments}

In the first project, 
Brenda Latka, while visiting DIMACS from Lafayette College, 
used \Link to assist in her study of infinite antichains 
of tournaments (complete directed graphs).
An antichain of tournaments is a set for which it is impossible to
embed any tournament in the set within any other.
Latka is interested in the construction of infinite antichains of
tournaments.~\cite{cl96,l94}.  Arguments to prove that a given
set of tournaments is an antichain typically 
show that a specific sub-tournament of any given tournament 
cannot be mapped to any sub-tournament of any other tournament
in that class.  A crucial element of these arguments is the
use of a non-trivial edge attribute:
the number of directed 3-cycles in which an edge 
participates.  Sub-tournaments 
\begin{figure*}[tbh]
%\centerline{\includegraphics*[width=3.335in]{latka511}}
\centerline{\psfig{width=3.335in,figure=latka511.ps}}
\caption{A Latka tournament and an induced subgraph 
		extracted with \Linkn's graphical user interface}
\label{fig:latka}
\end{figure*}
and these edge attributes are easily visualized using \Linkn's features:
the former can be extracted by clicking on vertices and selecting
a menu option, while the latter can be computed (and the edges colored) by  
small programs written in \Linkn's command language.
Figure~\ref{fig:latka} 
shows an instance of a special class of tournaments defined by Latka
(see \cite{cl96,l94} for details),
and an induced sub-tournament extracted by
pointing and clicking (see the \Link web page for a color image).

Once \Link functionality had been used to generate Latka Tournaments,
compute the edge attributes, and color their edges accordingly,
Latka and Jonathan Berry used \Link to visualize dozens of these tournaments
and variations upon them.  Soon patterns began to emerge, leading 
Latka to conjecture that adding an extra parameter to her initial
tournament construction would reveal the first known {\em infinite} set of 
infinite antichains of tournaments.  The conjecture, still unproven, will be
detailed in a future paper.  

During this time, Jonathan Berry was also serving as a mentor for 
Chris Burrows, a participant in the the
{\em NSF Research Experience for Undergraduates (REU)} at DIMACS.
He used \Link to study isomorphisms
of certain sub-tournaments by implementing some special
invariants described by Latka and using 
\Linkn's point and click access to {\em nauty}.
During this process, we observed that one of the Latka tournaments 
also happened to be a Paley 
tournament.~\footnote{The well-studied Paley tournaments consist
of $p$ vertices,  where $p$ is prime and congruent to 3 mod 4.  Arc
$(i, j)$ exists iff $j-i$ is a quadratic residue mod $p$.} 
Burrows then used \Link to find two additional Latka-Paley tournaments,
then develop the conjecture
that no other Latka tournaments are Paley tournaments.

\subsection{Market Basket Analysis}

In another project, a set of 
supermarket data compiled and studied previously at Bell
Laboratories was analyzed in a more meaningful way with \Linkn.
Considering each type of item in a shopper's ``basket'' 
(e.g., bananas, 2\% milk, skim milk) to be
a vertex, ``market-basket analysis'' attempts to identify customer buying 
patterns by examining receipts.  Correlations between purchases identified
by the analysis can be used, for example, to arrange products more 
advantageously on the shelves or manipulate prices.

When a shopper purchases a set of items at once,
we must represent this grouping somehow.  An obvious approach
to the problem is to place an edge between each pair of vertices in a
basket, 
thus producing a graph where each purchase is represented by a clique.  
Given such a graph, however, the original ``baskets'' cannot by 
reconstructed.  Nathaniel Dean and Jonathan Berry used \Link 
to re-model the problem using hypergraphs (graphs
where each edge might contain more or fewer than two vertices)
where each hyperedge represents a single shopper's basket.  In addition
to the considerable space savings inherent in this solution, more real-world
information is preserved.  Furthermore, the STk 
command language used by \Link makes it possible to pose interactive queries 
such as: ``find all purchases in which both a snack food item 
and a beverage were purchased.''  A paper describing this work in more
detail is available at the \Link web site~\cite{bd96}.

\section{\Link as an educational tool}

\Linkn's flexible interface makes it an valuable educational tool, both
in the classroom and as a vehicle for interesting assignments.  The
key binding example discussed above (see Figure~\ref{fig:ff-code})
enables the instructor to present the forefather concept as a puzzle to
engage students.  This was done recently with encouraging success in an 
algorithms course at Elon College. The instructor also made extensive use of 
\Linkn's graphical user interface and interactive algorithm animations in
class.  A discussion of \Linkn's role in computer science education is
found in~\cite{bsig97}.

\section{Conclusion}

The early development and primary designers and developers of \Link are 
detailed and acknowledged, respectively, in~\cite{tr95}, while the current
system is described in the manual available from the web site. 
Jonathan Berry took over the direction of the project in 
June, 1995, and spent a year at DIMACS preparing the public release.  

With further development, \Link can become a formidible tool for prototyping,
teaching, and experimentation.  Current directions 
include improving the documentation, extending the algorithms library, and
improving the STklos interface.

%The experience of designing, working on, and finally directing the \Link 
%project has made it clear to me that in the
%arena of {\em Algorithm Engineering}, the primary emphasis of systems 
%designers should be software engineering, and the primary goal should
%be to produce a system flexible enough for users to handle most 
%anticipated algorithmic applications.  Should algorithms experts become 
%involved in the system design, they must recognize that a frustrating 
%number of factors take precedence over the development of algorithms 
%libraries.

\section{ Acknowledgments}
%\trtwel{ {\bf Acknowledgments} }

We would like to acknowledge the support of DIMACS and 
the \Link grant: CCR-9214487.  DIMACS is a cooperative project of Rutgers
University, Princeton University, AT\&T Laboratories, 
Lucent Technologies/Bell Laboratories
Innovations, and Bellcore. 
DIMACS is an NSF Science and Technology Center, funded under contract 
STC-91-19999; and also receives support from the New Jersey Commission
on Science and Technology.  
The original primary investigator of the \Link project was Daniel 
Gorenstein, the founding director of DIMACS.

We would also like to acknowledge the 
contributions of Patricia K. Fasel of Los Alamos National Laboratory,
who was the original project leader and who helped design the graph
hierarchy and implemented many system fundamentals.
Many students have helped with the \Link effort as well, and we
acknowledge their effort.
