Hello, Thanks all for valuable information given and sorry for answering late... Personally, I also think we need a graph lib for small scale application (100 nodes maximum). This is actually my needs as our research model won't go beyond 50 nodes I guess (and around the same scale for edges). That being said, in an ideal world, we would have a nice designed library that could map/translate/primitivize to a more efficient lib / functions easily. I've started looking at the exemples YossiDM gave to me and in particular Lemon which was according to him his best experience. I found the model quite clear and covering all what I expect for a generic graph lib (directed, undirected, mapping concept, iterators, and algorithms of course). Moreover and contrary to Boost, it's still developed in 2010. To be more precise, here's what I expect for a generic graph lib in smalltalk (note all in Lemon except visualization): - data structure: directed graphs, undirected graphs, possible loop and parallel edged, ..., trees (?) - mapping: easily map objects, informations on nodes and/or edges (here, don't know if I'd like subclassing nodes/eges instead...) - iterators: efficient way to iterate over nodes and edges - algorithms: basic algorithms implementation (bfs, dfs, ..., shortest paths, ...), and plug-ability for specific ones... - visualization: having an interactive graph visualization web/SVG and eventually morphic (... graphviz, mondrian, .......) then, I could use this for my research work... - I need "belief" nodes with associated conditional beliefs tables - I need to implement algorithms to propagate an information change (change of a node state) in any nodes... ****mainly, I'd like to get junction trees from a graph [1] which are rely useful for several domains in machine learning field *** Actually, I don't know if I really need a graph lib as a simple implementation directed to bayesian should be enough but it's the second time I need graphs (last time was for planification) and I think that would be great to have a nice and clean basic implementation. Couldn't we start developing something similar to Lemon (regarding "API", enitites, etc...) that would work for small scale project project in smalltalk ? Yossi, what were the limitations you found with Lemon ? Cheers, Cédrick [1] http://en.wikipedia.org/wiki/Junction_tree
JGraphT worked alright in what I tried against in the past, but it won't scale to huge heights like most libs without major tweaking or a graph DB backing it along with some serious threading.
Just to throw in a few others I've used, but not with Smalltalk:
* https://software.sandia.gov/trac/mtgl MTGL * http://lemon.cs.elte.hu/trac/lemon LEMON * .NET http://quickgraph.codeplex.com/ Quickgraph /Graph# * http://igraph.sourceforge.net/introduction.html iGraph * http://snap-graph.sourceforge.net/ SNAP
Of the above, I've had some of the best experience with LEMON in terms of scale and speed for real-world usage. Unfortunately, none of these libraries include everything you'd want, so at some point you will have to roll some stuff yourself. That's been my experience at least.
Some Graph or Graph-like Databases (tend to have some algorithm libs as well):
* http://www.infinitegraph.com InfiniteGraph (this runs on Objectivity underneath the covers which has a Smalltalk impl) * http://www.neo4j.org neo4j * http://www.kobrix.com/hgdb.jsp HyperGraphDB
Some related useful items for dealing with large sets and graphs when you are thinking about performance and/or parallel processing:
* http://gauss.cs.ucsb.edu/~aydin/doc/html/index.html Combinatorial BLAS * http://www.semanticdesigns.com/Products/PARLANSE/ PARLANSE * http://research.microsoft.com/en-us/projects/dryadlinq/ DRYAD LINQ
FYI, I would strongly recommend against using Ruby for anything with graphs except as a simple client lib. I spent a lot of time on this before and it simply does not scale or perform to anything beyond very simple cases, and the memory footprint in a real app becomes horrendous. We had to tweak the hell out of some libs to get anything decent and even then we ended up writing stacks of C to compensate. If you're just dealing with 100 vertex undirected graphs, then it works great. It's honestly the fault of a lot of the libs rather than the language, but nonetheless be warned.
Thanks ;-)
-- View this message in context: http://forum.world.st/Graph-library-in-Smalltalk-Need-for-advices-tp3092747p... Sent from the Pharo Smalltalk mailing list archive at Nabble.com.