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-tp3092747p3092943.html
> Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
>