The nodes of a Network's graph can be any arbitrary, properly hashable object. The edges of the graph are members of the Edge class. This class is little more than a wrapper around an arbitrary object as well (the Edge's 'info' object). Thus your graph's nodes and edges can essentially be objects entirely of your choosing.
Edge objects also contain pointers to the Nodes that they are to and from (plus some auxillary index information for speed).
Nodes and Edges are stored in the Network using two data structures: a Bag containing all the nodes in the Field; and a HashMap which maps each Node to a container holding the Node's index in the Bag, plus a Bag of the Node's outgoing Edges and a Bag of the Node's incoming Edges. Ordinarily you won't fool with these structures other than to scan through them (in particular, to scan rapidly through the allNodes bag rather than use an iterator).
To add a node to the Network, simply use addNode(node). To remove a node, use removeNode(node). To add an edge to the Network, use addEdge(fromNode,toNode,edgeInfoObject), where edgeInfoObject is your arbitrary edge object. Alternatively, you can make an Edge object from scratch and add it with addEdge(new Edge(fromNode, toNode, edgeInfoObject)). You remove edges with removeEdge(edge). If you add an edge, and its nodes have not been added yet, they will automatically be added as well.
Traversing a Network is easy. To get a Bag of all the incoming (or outgoing) Edges to a node, use getEdgesIn(node) or getEdgesOut(node). Do not add or remove Edges from this Bag -- it's used internally and we trust you here. Also don't expect the Bag to not change its values mysteriously later on. Make a copy of the Bag if you want to keep it and/or modify it. Once you have an Edge, you can call its to() method and from() methods to get the nodes it's from and to, and you can at any time get and modify its info object. The to() and from() are fast and inlined.
However, the getEdgesIn(node) and getEdgesOut(node) methods are not super fast: they require a hash lookup. If you are planning on applying an algorithm on the Network which doesn't change the topology at all but traverses it a lot and changes just the contents of the edge info objects and the node object contents, you might consider first getting an adjacency list for the Network with getAdjacencyList(...), or an adjacency matrix with getAdjacencyMatrix(...) or getMultigraphAdjacencyMatrix(...). But remember that as soon as the topology changes (adding/deleting a node or edge), the adjacency list is invalid, and you need to request another one.
Computational Complexity. Adding a node or an edge is O(1). Removing an edge is O(1). Removing a node is O(m), where m is the total number of edges in and out of the node. Removing all nodes is O(1) and fast. Getting the in-edges or out-edges for a node is O(1). Getting the to or from node for an edge is O(1) and fast.
Warning About Hashing. Java's hashing method is broken in an important way. One can override the hashCode() and equals() methods of an object so that they hash by the value of an object rather than just the pointer to it. But if this is done, then if you use this object as a key in a hash table, then change those values in the object, it will break the hash table -- the key and the object hashed by it will both be lost in the hashtable, unable to be accessed or removed from it. The moral of the story is: do not override hashCode() and equals() to hash by value unless your object is immutable -- its values cannot be changed. This is the case, for example, with Strings, which hash by value but cannot be modified. It's also the case with Int2D, Int3D, Double2D, and Double3D, as well as Double, Integer, etc. Some of Sun's own objects are broken in this respect: Point, Point2D, etc. are both mutable and hashed by value.
This affects you in only one way in a Network: edges are hashed by nodes. The Network permits you to use any object as a node -- but you have been suitably warned: if you use a mutable but hashed-by-value node object, do NOT modify its values while it's being used as a key in the Network.
Directed vs. Undirected Graphs. Networks are constructed to be either directed or undirected, and they cannot be changed afterwards. If the network is directed, then an Edge's to() and from() nodes have explicit meaning: the Edge goes from() one node to() another. If the network is undirected, then to() and from() are simply the two nodes at each end of the Edge with no special meaning, though they're always consistent. The convenience method edge.getOtherNode(node) will provide "other" node (if node is to(), then from() is returned, and vice versa). This is particularly useful in undirected graphs where you could be entering an edge as to() or as from() and you just want to know what the node on the other end of the edge is.
There are three methods for getting all the edges attached to a node: getEdgesIn(), getEdgesOut(), and the less efficient getEdges(). These methods work differently depending on whether or not the network is directed:
Directed | Undirected | |
getEdgesIn() | Bag of incoming edges | Bag of all edges |
getEdgesOut() | Bag of outgoing edges | Bag of all edges |
getEdges() | Modifiable Bag of all edges | Modifiable Bag of all edges |
Hypergraphs. Network is binary. In the future we may provide a Hypergraph facility if it's needed, but for now you'll need to make "multi-edge nodes" and store them in the field, then hook them to your nodes via Edges. For example, to store the relationship foo(node1, node2, node3), here's one way to do it:
The adjacency list is an array of Edge arrays. Each edge array holds all outgoing edges from a node (if outEdges is true -- otherwise it's the incoming edges to the node). The edge arrays are ordered in their parent array in the same order that the corresponding nodes are ordered in the allNodes bag.
As soon as you modify any part of the Network's topology (through addEdge(), addNode(), removeEdge(), removeNode(), removeAllNodes(), etc.), the adjacency list data is invalid and should not be used. Instead, request a new adjacency list.
You can modify these edge arrays any way you like, though the Edge objects are the actual Edges.
*/
public Edge[][] getAdjacencyList(boolean outEdges)
{
final Edge[][] list = new Edge[allNodes.numObjs][];
for(int x=0;x
As soon as you modify any part of the Network's topology (through addEdge(), addNode(), removeEdge(), removeNode(), removeAllNodes(), etc.), the adjacency matrix data is invalid and should not be used. Instead, request a new adjacency matrix.
You can modify the array returned any way you like, though the Edge objects are the actual Edges.
*/
public Edge[][] getAdjacencyMatrix()
{
final int n = allNodes.numObjs;
final Edge[][] matrix = new Edge[n][n]; // I assume it filled with nulls?
Iterator nodeIO = indexOutInHash.values().iterator();
while(nodeIO.hasNext()) // this replaces n hash lookups with n class casts
{
IndexOutIn ioi = (IndexOutIn)nodeIO.next();
if(ioi.out==null) continue;
int outDegree = ioi.out.numObjs;
Edge[] outEdges = matrix[ioi.index];
Object sourceNode = allNodes.objs[ioi.index];
for(int i=0;i
Important note: if there are no edges FROM a given node TO another, an empty array is placed in that entry. For efficiency's sake, the same empty array is used. Thus you should not assume that you can compare edge arrays for equality (an unlikely event anyway).
As soon as you modify any part of the Network's topology (through addEdge(), addNode(), removeEdge(), removeNode(), removeAllNodes(), etc.), the adjacency matrix data is invalid and should not be used. Instead, request a new adjacency matrix.
You can modify the array returned any way you like, though the Edge objects are the actual Edges.
*/
public Edge[][][] getMultigraphAdjacencyMatrix()
{
final int n = allNodes.numObjs;
final Edge[][][] matrix = new Edge[n][n][]; //I assume it filled with nulls?
Iterator nodeIO = indexOutInHash.values().iterator();
Bag[] tmp = new Bag[n];
for(int i=0; i
for(int x=0;x<field.allNodes.numObjs;x++) ... field.allNodes.objs[x] ...
... but do NOT modify the allNodes.objs array. */ public Iterator iterator() { return allNodes.iterator(); } /** The structure stored in the indexOutInHash hash table. Holds the index of a node in the allNodes bag, a Bag containing the node's outgoing edges, and a Bag containing the node's incoming edges. */ public static class IndexOutIn implements java.io.Serializable { /** Index of the node in the allNodes bag */ public int index; /** Bag containing outgoing edges of (leaving) the node */ public Bag out; /** Bag containing incoming edges of (entering) the node */ public Bag in; public IndexOutIn(final int index, final Bag out, final Bag in) { this.index = index; this.out = out; this.in = in; } // static inner classes don't need serialVersionUIDs } /* Returns the index of a node. If the node does not exist in the Network, a runtime exception is thrown. */ public int getNodeIndex( final Object node ) { IndexOutIn ioi = (IndexOutIn)(indexOutInHash.get(node)); if( ioi == null ) throw new RuntimeException( "Object parameter is not a node in the network." ); return ioi.index; } /** * This reverse the direction of all edges in the graph. * It is more expensive to clone the graph than to reverse the edges in place. * It is more than twice as fast to reverse the edges than to * create the dual graph. As a matter of fact getDualNetwork() took 240 time units * while two reverseAllEdges() calls took only 40 time units on a directed * graph (1time unit = 1 millisecond / 10000 calls). * * In that case it is more advantageous to reverse the edges, * compute whatever stats on the dual and revert it than to allocate memory. * */ public void reverseAllEdges() { if(!directed) return;//that was quick int n = allNodes.numObjs; Iterator i = indexOutInHash.values().iterator(); for(int k=0;k