Closed jovo closed 10 years ago
I would need some clarifications here.
So I am a bit lost with this.
hey gabor - i was just reporting notes from the discussion we all had in carey's office. it seems as if we already have a suitable solution in igraph/R, so perhaps this comment was moot. for clarification, in general, do you find that if something is in R, even if it does not exist in C and/or python, that it is not worth putting in igraph?
In general, if something is already implemented and freely available, we don't want to include it, unless including it in igraph makes it much more accessible to use (e.g. a hard to use C/C++ library), or the current implementation is inferior. So we would consider including a C/C++ lib, that is expected to be widely used, but probably not a big piece of software (igraph is already huge!), or something that is already in R/Python.
But we/I always decide case by case. E.g. if somebody is (1) willing to program their methods in a way that is easy to include and (2) provide patches/pull requests, complete with docs and testing, then is likely that we include it. Even if people do this, it is a lot of work to go through the code and make sure it passes CRAN checks, etc.
In general the problems with including third party code:
understood. so louvain is already in there, mclust is already good, so let's close this one.
given the embedded graph, cluster the vertices, possibly hooking in to a scalable clustering code, such as kmeans++ or kmeans||
eventually, we will want to consider hooking in to something like mclust (http://cran.r-project.org/web/packages/mclust/index.html) or other highly scalable things, like louvain (http://perso.uclouvain.be/vincent.blondel/research/louvain.html) or Nerstrand (http://sc13.supercomputing.org/sites/default/files/PostersArchive/tech_posters/post193s2-file3.pdf)