Adjency lists are indeed nice for general graph processing but one doesn’t usually implement, for example, linked lists with adjency lists.

I’m exploring specialized representations for GSS. I’ll keep you posted as I progress: experiment will tell us if a specialized representation is worth its complexity.

I also like to keep my graphs as a set of edges. It matches the mathematical definition of a graph:

A set of vertices V and a set of edges E: {V, E}. The edge is a map like this {:a 7 :b 3} so that it’s directed. It’s also easy to add labels to the edges if you need them.

All sorts of graph operations are easier with this method. You could also build an index of this if you really needed fast lookup times. The index would be vertex to a set of edges containing that vertex. Or you could build two indexes, one for the :a position and one for the :b position.

see you later

Eric

]]>I have to work with a lot of (directed) graphs on the clock. I have found it very useful to simply keep track of a edges. So, I would do something like this

[{:source 7 :dest 3}

{:source 7 :dest 4}

{:source 7 :dest 5}

{:source 3 :dest 1}

{:source 4 :dest 1}

{:source 8 :dest 6}

{:source 5 :dest 2}

{:source 6 :dest 2}

{:source 1 :dest 0}

{:source 2 :dest 0}]

This also makes it very simple to determine what are direct dependencies with a simple filter, and all dependencies with a simple recursive call. It also fits with a classic RDBMS well, or a NoSQL alternative.

HTH,

Sean