# Static Sparse Graphs¶

Static Sparse Graphs

## What is the point ?¶

This class implements a Cython (di)graph structure made for efficiency. The graphs are static, i.e. no add/remove vertex/edges methods are available, nor can they easily or efficiently be implemented within this data structure.

The data structure, however, is made to save the maximum amount of computations for graph algorithms whose main operation is to list the out-neighbours of a vertex (which is precisely what BFS, DFS, distance computations and the flow-related stuff waste their life on).

The code contained in this module is written C-style. While Sage needs a class for static graphs (not available today, i.e. 2012-01-13) it is not what we try to address here. The purpose is efficiency and simplicity.

Author:

• Nathann Cohen (2011)

## Data structure¶

The data structure is actually pretty simple and compact. short_digraph has five fields

• n (unsigned short) – the number of vertices in the graph.
• m (unsigned int) – the number of edges in the graph.
• edges (unsigned short *) – array whose length is the number of edges of the graph.
• neighbors (unsigned short **) – this array has size $$n+1$$, and describes how the data of edges should be read : the neighbors of vertex $$i$$ are the elements of edges addressed by neighbors[i]...neighbors[i+1]-1. The element neighbors[n], which corresponds to no vertex (they are numbered from $$0$$ to $$n-1$$) is present so that it remains easy to enumerate the neighbors of vertex $$n-1$$ : the last of them is the element addressed by neighbors[n]-1.
• edge_labels – this cython list associates a label to each edge of the graph. If a given edge is represented by edges[i], this its associated label can be found at edge_labels[i]. This object is usually NULL, unless the call to init_short_digraph explicitly requires the labels to be stored in the data structure.

In the example given above, vertex 0 has 2,3,5,7,8 and 9 as out-neighbors, but not 4, which is an out-neighbour of vertex 1. Vertex $$n-1$$ has 2, 5, 8 and 9 as out-neighbors. $$\text{neighbors[n]}$$ points toward the cell immediately after the end of $$\text{edges}$$, hence outside of the allocated memory. It is used to indicate the end of the outneighbors of vertex $$n-1$$

Iterating over the edges

This is the one thing to have in mind when working with this data structure:

cdef list_edges(short_digraph g):
cdef int i, j
for i in range(g.n):
for j in range(g.neighbors[i+1]-g.neighbors[i]):
print "There is an edge from",str(i),"to",g.neighbors[i][j]

Two great points :

• The neighbors of a vertex are C types, and are contiguous in memory.
• Storing such graphs is incredibly cheaper than storing Python structures.

Well, I think it would be hard to have anything more efficient than that to enumerate out-neighbors in sparse graphs ! :-)

## Technical details¶

• When creating a fast_digraph from a Graph or DiGraph named G, the $$i^{\text{th}}$$ vertex corresponds to G.vertices()[i]
• In its current implementation (with unsigned short variables), the data structure can handle graphs with at most 65535 vertices. If necessary, changing it to int is totally straightforward.
• Some methods return bitset_t objets when lists could be expected. There is a very useful bitset_list function for this kind of problems :-)
• When the edges are labelled, most of the space taken by this graph is taken by edge labels. If no edge is labelled then this space is not allocated, but if any edge has a label then a (possibly empty) label is stored for each edge, which can represent a lot of memory.
• The data structure stores the number of edges, even though it appears that this number can be reconstructed with g.neighbors[n]-g.neighbors[0]. The trick is that not all elements of the g.edges array are necessarily used : when an undirected graph contains loops, only one entry of the array of size $$2m$$ is used to store it, instead of the expected two. Storing the number of edges is the only way to avoid an uselessly costly computation to obtain the number of edges of an undirected, looped, AND labelled graph (think of several loops on the same vertex with different labels).
• The codes of this module are well documented, and many answers can be found directly in the code.

## Cython functions¶

 init_short_digraph(short_digraph g, G) Initializes short_digraph g from a Sage (Di)Graph. int n_edges(short_digraph g) Returns the number of edges in g int out_degree(short_digraph g, int i) Returns the out-degree of vertex $$i$$ in g has_edge(short_digraph g, ushort u, ushort v) Tests the existence of an edge. edge_label(short_digraph g, ushort * edge) Returns the label associated with a given edge init_empty_copy(short_digraph dst, short_digraph src) Allocates dst so that it can contain as many vertices and edges as src. init_reverse(short_digraph dst, short_digraph src) Initializes dst to a copy of src with all edges in the opposite direction. free_short_digraph(short_digraph g) Free the ressources used by g

Connectivity

can_be_reached_from(short_digraph g, int src, bitset_t reached)

Assuming bitset_t reached has size at least g.n, this method updates reached so that it represents the set of vertices that can be reached from src in g.

strongly_connected_component_containing_vertex(short_digraph g, short_digraph g_reversed, int v, bitset_t scc)

Assuming bitset_t reached has size at least g.n, this method updates scc so that it represents the vertices of the strongly connected component containing v in g. The variable g_reversed is assumed to represent the reverse of g.

## What is this module used for ?¶

At the moment, it is only used in the sage.graphs.distances_all_pairs module.

## Python functions¶

These functions are available so that Python modules from Sage can call the Cython routines this module implements (as they can not directly call methods with C arguments).

sage.graphs.base.static_sparse_graph.strongly_connected_components(G)

Returns the strongly connected components of the given DiGraph.

INPUT:

• G – a DiGraph.

Note

This method has been written as an attempt to solve the slowness reported in trac ticket #12235. It is not the one used by sage.graphs.digraph.DiGraph.strongly_connected_components() as saving some time on the computation of the strongly connected components is not worth copying the whole graph, but it is a nice way to test this module’s functions. It is also tested in the doctest or sage.graphs.digraph.DiGraph.strongly_connected_components().

EXAMPLE:

sage: from sage.graphs.base.static_sparse_graph import strongly_connected_components
sage: g = digraphs.ButterflyGraph(2)
sage: strongly_connected_components(g)
[[('00', 0)], [('00', 1)], [('00', 2)], [('01', 0)], [('01', 1)], [('01', 2)],
[('10', 0)], [('10', 1)], [('10', 2)], [('11', 0)], [('11', 1)], [('11', 2)]]