ANN: Haskell bindings for the igraph C library
Hi Haskellers, dear igraph community, I am pleased to announce the release of our (inofficial) Haskell bindings to the igraph C library. igraph is a powerfull library for creating and manipulating directed, undirected and weighted graphs. Our package offers a complete coverage of all functions on structural properties of graphs. Compared to the official packages for R and Python it is the first library that offers type level distinction between directed/undirected and weighted graphs. Haskells type system allows to keep track of the types of your nodes and whether or not your graph and its edges are directed or undirected, weighted or unweighted. Haskell graphs may contain any Haskell value as node values, kind of similar to Pythons attributes. igraph on hackage, the official package database for Haskell: http://hackage.haskell.org/package/igraph (requires the current igraph-0.6 C library) The official igraph website: http://igraph.sourceforge.net/index.html Until hackage generates the haddock documentation, the documentation is also available at: http://hs.nils.cc/igraph-0.1/html/index.html Any feedback is appreciated, - Nils Schweinsberg - George Giorgidze
On Sun, Dec 16, 2012 at 9:53 AM, Nils Schweinsberg
Hi Haskellers, dear igraph community,
I am pleased to announce the release of our (inofficial) Haskell bindings to the igraph C library. igraph is a powerfull library for creating and manipulating directed, undirected and weighted graphs. Our package offers a complete coverage of all functions on structural properties of graphs.
How does this compare with fgl? http://hackage.haskell.org/package/fgl Thanks! Jason
Am 16.12.2012 20:24, schrieb Jason Dagit:
How does this compare with fgl? http://hackage.haskell.org/package/fgl
FGL is a pure Haskell library while our haskell-igraph package uses the foreign function interface to run all graph-related calculations in C the C library igraph (I haven't implemented any graph algorithms). The runtime performance with our igraph library should be the same as if you'd be using the native C library (if you ignore the small Haskell->C->Haskell overhead). It is also seems to be more of a higher level library. As user you don't have to worry about node-IDs/labels or whether your graph is "static" or not (in the FGL context). Using features like GADTs and type families/associated types it is possible to keep track of informations like whether or not your graph is directed/weighted or not, while in FGL all graphs are by default directed and unweighted. Consider for example edges :: Graph d a -> [Edge d a] -- directed, unweighted graph g :: Graph D a -- undirected, weighted graph w :: Graph (Weighted U) a which leads to edges g :: [Edge D a] edges w :: [Edge (Weighted U) a] or even functions like toUndirected :: (IsDirected d, E (ToUndirected d) a) => Graph d a -> Graph (ToUndirected d) a toDirected :: (IsUndirected u, E (ToDirected u) a) => Graph u a -> Graph (ToDirected u) a which evaluate to toUndirected g :: Graph U a toDirected w :: Graph (Weighted D) a This is even revertable, and `toDirected . toUndirected == id` while the FGL function `undir` simply adds all missing edges and loses track of what the original/directed graph looked like. Maybe George has more details on why he wanted to use igraph instead of FGL. - Nils
participants (2)
-
Jason Dagit -
Nils Schweinsberg