Comments on: Announcing planar-graph

By: DNA sequence annotation: a graph coloring problem « GCBLOG

DNA sequence annotation: a graph coloring problem « GCBLOG — Mon, 18 Jun 2012 16:17:33 +0000

[...] are many ways to represent graphs, with several interesting implementations proposed for Haskell. The greedy algorithm above requires that an adjacency list [...]

By: Ivan Miljenovic

Ivan Miljenovic — Sat, 05 May 2012 03:57:10 +0000

That’s where the transformers concept comes in handy: if you’re doing a lot of stuff where finding adjacent nodes is important, then applying a transformer to your graph stack to cache these (rather than looking up the “to node” for each half-edge attached to that node) will give you this; otherwise, you avoid storing this extra information.

By: gcbenison

gcbenison — Sat, 05 May 2012 03:27:38 +0000

That’s true that with the “Node -> Node -> Bool” representation getting a list of edges would be O(N_v). So would getting the adjacency list for a single node. Another “function-based” representation would be (Node -> [Node]) where the returned list is the adjacency list. DFS and related algorithms could be implemented efficiently with that representation.

By: Ivan Miljenovic

Ivan Miljenovic — Fri, 04 May 2012 21:31:08 +0000

Well, just use a function hasEdge :: Graph -> Node -> Node -> Bool (though I'd be tempted to use a tupled version so you can map it over a list of pairs, etc.). In practice, having that as the only representation seems rather inefficient as there is a lot more you need to do with edges than just see if they exist (map a function for each edge, etc.). If you tried using this as the internal representation, it would also be O(n) in the number of edges.

By: gcbenison

gcbenison — Fri, 04 May 2012 16:41:47 +0000

I’m very interested in seeing how this will develop, as I’m starting to work with graphs in Haskell. For instance I am working on a Haskell program to annotate a DNA sequence with a number of shorter strings, which if they overlap, must be printed on different lines. This can be expressed as a graph colouring problem.

One idea that interests me is a “just in time” graph representation – where the only representation of edges is a function Node->Node->Bool that tells you whether those nodes are connected. No need to expose lists of edges as tuples, adjacency lists, whatever (though the library could of course maintain such lists internally.)