Coder Social home page Coder Social logo

igraph / igraph Goto Github PK

View Code? Open in Web Editor NEW
1.7K 81.0 397.0 130.39 MB

Library for the analysis of networks

Home Page: https://igraph.org

License: GNU General Public License v2.0

Shell 0.11% C 86.86% C++ 10.50% Makefile 0.01% Python 0.04% Fortran 0.01% Lex 0.23% Yacc 0.65% sed 0.01% CMake 1.56% Game Maker Language 0.01% Mathematica 0.03% Emacs Lisp 0.01%
graph-algorithms network-graph c mathematics complex-networks graph-theory network-analysis

igraph's Introduction

Build Status on Azure Pipelines Build Status on Github Actions codecov DOI

The igraph library

igraph is a C library for complex network analysis and graph theory, with emphasis on efficiency, portability and ease of use.

See https://igraph.org for installation instructions and documentation.

igraph can also be used from:

igraph is a collaborative work of many people from all around the world — see the list of contributors here. If you would like to contribute yourself, click here to see how you can help.

Citation

If you use igraph in your research, please cite

Csardi, G., & Nepusz, T. (2006). The igraph software package for complex network research. InterJournal, Complex Systems, 1695.

igraph's People

Contributors

adalisan avatar araujo88 avatar borsgeorgica avatar das-intensity avatar dependabot[bot] avatar ferranpares avatar frederik-h avatar gaborcsardi avatar ganzuratheconsumer avatar gendelpiekel avatar grotegnoom avatar guyroznb avatar iosonofabio avatar jankatins avatar jannick0 avatar jgmbenoit avatar krlmlr avatar kwofach avatar larah19 avatar naviddianati avatar ntamas avatar peterscott avatar pradkrish avatar professorcode1 avatar rfulekjames avatar szhorvat avatar tagl avatar valdaarhun avatar vtraag avatar yasirkusay avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

igraph's Issues

Add a igraph64.vcproj file

It would be nice if igraph-msvc came with a igraph64.vcproj so that i could be compileable in a 64bit environment as done in #1

R: igraph.from.graphNEL removes multiple loop edges

R

library(igraph)
library(graph)

nodes <- LETTERS[1:4]
edges <- list(A=c("A", "A", "B", "B"),
B=c("B", "B", "A", "A"),
C=c("D"),
D=c("C"))

gN <- new("graphNEL", nodes=nodes, edgeL=edges)

g <- igraph.from.graphNEL(gN)
g


Imported from Launchpad using lp2gh.

building python-igraph and igraph C-lib under Win64 fails

See https://bugs.launchpad.net/igraph/+bug/1132270 for the initial problems.

This is a 64bit windows with visual studio express 2008 FP1 and 64bit compiler, setup like explained here:
http://statsmodels.sourceforge.net/devel/install.html#windows
http://blog.victorjabur.com/2011/06/05/compiling-python-2-7-modules-on-windows-32-and-64-using-msvc-2008-express/
-> I can compile statsmodels, pandas (which use cython) for my 64bit python install, so that environment seems to work.

First attempt was to compile the igraph c parts "as is":

# First upgrade the vcproj as suggested by the error in vcbuild call
vcbuild igraph.vcproj "release|win32"

-> This seems to build a 32bit igraph.lib file (no DLL!)
Using this in the python build succeeds in compiling but not in linking the final _igraph python lib (errors as in the LP bug linked above)

When I try to build a 64 bit igraph library by changing the following in igrapg.vcproj

<Platforms>
        <Platform
            Name="x64"
        />
    </Platforms>

and

Name="Release|x64"

Calling vcbuild igraph.vcproj "release|x64"a build error comes up:

cl : Command line warning D9035 : option 'Wp64' has been deprecated and will be
removed in a future release
math.c
.\src\math.c(68) : error C4235: nonstandard extension used : '__asm' keyword not
 supported on this architecture
.\src\math.c(68) : error C2065: 'fld' : undeclared identifier
.\src\math.c(68) : error C2109: subscript requires array or pointer type
.\src\math.c(68) : error C2143: syntax error : missing ';' before '}'
.\src\math.c(69) : error C4235: nonstandard extension used : '__asm' keyword not
 supported on this architecture
.\src\math.c(69) : error C2065: 'fxtract' : undeclared identifier
.\src\math.c(69) : error C2143: syntax error : missing ';' before '}'
.\src\math.c(70) : error C4235: nonstandard extension used : '__asm' keyword not
 supported on this architecture
.\src\math.c(70) : error C2065: 'fstp' : undeclared identifier
.\src\math.c(70) : error C2146: syntax error : missing ';' before identifier 'st
'
.\src\math.c(70) : error C2065: 'st' : undeclared identifier
.\src\math.c(70) : error C2143: syntax error : missing ';' before '}'
.\src\math.c(71) : error C4235: nonstandard extension used : '__asm' keyword not
 supported on this architecture
.\src\math.c(71) : error C2065: 'fistp' : undeclared identifier
.\src\math.c(71) : error C2109: subscript requires array or pointer type
.\src\math.c(71) : error C2143: syntax error : missing ';' before '}'
Build log was saved at "file://c:\data\external\igraph-msvc\igraph-0.6.5-msvc\Re
lease\BuildLog.htm"
igraph - 16 error(s), 99 warning(s)

I found the following websites but I'm simple not understanding what this is suggesting (I've never hacked c and assembler before).

http://stackoverflow.com/questions/13146997/converting-inline-asm-to-intrinsic-for-x64-igraph
http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/4dc15026-884c-4f8a-8435-09d0111d708d/

Can you help me compiling igraph for Win64?

There is a build of the python-igraph libs for Win64 by @cgohlke at http://www.lfd.uci.edu/~gohlke/pythonlibs/#python-igraph so it seems possible, but I am simple unable to build it :-(

Repair R help files

See Brian Ripley's email:

It seems that many package authors do not proofread the help installed with their packages. The Rd converter is not a parser, and it will silently produce incorrect results on incorrect input (and some correct input).

Here are a few hints about some common errors:

  1. When you run R CMD check you get a PDF manual at .Rcheck/-manual.pdf. Read through it looking for missing/empty and mis-formatted entries.

  2. Try installing the package under a current R-devel (as of today). This will report on errors of the form

\item{foo} {item text}

with, NB, invalid space between the two arguments. Earlier versions of R assume that the item had no text and so '{item text}' is never processed (not even checked for validity). This results in at best missing information and at worse nonsense.

  1. Grep the installed help for internal constructs, e.g.

grep nornal-bracket /help/*

Three ways I have found such constructs to appear in the processed files:

a) If you see 'eqnnormal-bracket' then you have a one-argument \eqn (or possibly \deqn) command immediately followed by }. This is correct Rd but mis-processed in earlier versions of R. In all the cases I have seen it comes from grammatically incorrect help files of the form

\item{foo}{... \eqn{x}}

where the item should end in ',' or '.'. But if you don't want to do that, at least use a space before the brace. I found this in packages
distrMod, flexclust, geepack, geoR, psychometric, robustbase and uroot.

b) Many packages have help files with 'normal-bracket' at the end of a processed \value section. In all the cases I looked at, this results from using \itemize{} inside \value -- that does not work as \value is implicitly an itemize environment.

c) Using markup in verbatim-like environments will lead to nonsensical output: it seems the most common error is to use \code inside \examples. What markup is allowed where is not very well defined: Duncan Murdoch has started to document this at http://developer.r-project.org/parseRd.pdf but that currently is more a description of what should happen, not what has been implemented.

These issues are not rare (except 3a): about 10% of CRAN packages have them.

Brian D. Ripley,
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595


Imported from Launchpad using lp2gh.

Mysterious freeze in the R interface

The R interface freezes if erdos.renyi.game is called after cohesive block search. It gets stuck in generating a Poisson random number. This bug was already present in the 0.5.1 version and it does not matter which cutset algorithm we use in the cohesive block search.

A simple way to reproduce it:
example(cohesive.blocks)
example(decompose.graph)

(The decompose.graph example calls erdos.renyi.game.)

So far I only reproduced it on Linux, will try on Windows in a minute.


Imported from Launchpad using lp2gh.

Support bipartite networks

First I need to find a way to represent them. Basically you need to use attributes, there is no other way. But that means that at the C level they will look quite nasty, for every function that deals with bipartite networks, there will be an extra argument that gives the vertex types.

This is what is left:

  • Bipartite warnings

Look over all functions and add warnings for the ones that should behave differently for bipartite graphs, but they don't. This is a huge task....

  • Configure bipartite warnings

Add an option, to optionally suppress the warnings introduced in 1. It is not yet decided whether these warnings should be on by default or not.

  • Bipartite layout algorithms #235
  • Bipartite modularity #194
  • Bipartite configuration model samples #341
  • Bipartite transitivity #344
  • Bipartite community detection

1 Module identification in bipartite and directed networks
Roger Guimerà, Marta Sales-Pardo, and Luís A. Nunes Amaral
http://www.pubmedcentral.nih.gov/articlerender.fcgi?tool=pubmed&pubmedid=17930301

2 Michael J Barber: Modularity and community detection in bipartite networks,
Phys Rev E 76 066102
http://pre.aps.org/abstract/PRE/v76/i6/e066102


Imported from Launchpad using lp2gh.

Pagerank Results Suspected Incorrect

For the attached graph, I used an iterative algorithm in Python using NetworkX, as well as the matrix method recommended here:
http://www.cs.princeton.edu/courses/archive/spr08/cos435/Class_notes/pagerank_summary.pdf

Results for both implementations agree, but I get different results using the R igraph library.

Results from iterative method using Python, as well as a matrix method in R (see attached code to reproduce).
0.0980231910231
0.27033395151
0.0492018088851
0.12579642848
0.151486673127
0.0423393402047
0.0394227910156

To reproduce:
Adjacency matrix (need to transpose)
0 1 1 1 0 0 0
1 0 0 1 1 0 0
0 1 0 0 0 1 0
0 1 0 0 1 0 0
0 1 0 0 0 0 0
0 1 0 0 0 0 1
0 0 0 0 0 0 0

Code:
library(igraph)
data <- read.table("path to matrix")
G <- graph.adjacency(data)
page.rank(G)$vector
[1] 0.17938562 0.35482080 0.07525758 0.07525758 0.21269945 0.05563303 0.04694594


Imported from Launchpad using lp2gh.

Minimum s-t cut

The cut itself, not just the value. Basically this means calculating the actual maximum flow in the push-relabel algorithm, not just the flow value.


Imported from Launchpad using lp2gh.

Add normalize parameter in closeness

Just found that the normalize parameter to the closeness function, which is available in the R bindings, is not available in the python bindings.

R interface: "square" vertex shape fails if vertices have different size

Reported by robbie.heremans@

When the shape of all vertices is set to "square" and the size of the vertices is also set, one get following error (commands attached):

Error in l[[which.min(sapply(l, function(p) (p[1] - x0)^2 + (p[2] - y0)^2))]] :
attempt to select less than one element

Is there a way to solve this problem?

Robbie

Load the igraph package

library(igraph)

Create and plot a small graph

g <- graph( c(0,1, 0,2, 1,2, 2,3), n=4, directed = FALSE)
plot(g)

V(g)$size<-c(10,15,20,30)
plot(g) #OK

V(g)$shape<-c("circle","circle","circle","square")
plot(g) #OK

V(g)$shape<-c("circle","circle","square","square")
plot(g) #OK

V(g)$shape<-c("circle","square","square","square")
plot(g) #OK

V(g)$shape<-c("square","square","square","square")
plot(g) #Error in l[[which.min(sapply(l, function(p) (p[1] - x0)^2 + (p[2] - y0)^2))]] :
#attempt to select less than one element

V(g)$shape<-c("square","square","circle","square")
plot(g) #OK

Same without changing size

g <- graph( c(0,1, 0,2, 1,2, 2,3), n=4, directed = FALSE)
V(g)$shape<-c("square","square","square","square")
plot(g) #OK


Imported from Launchpad using lp2gh.

compile error on cygwin/win64

I got the following compile error when I run

./bootstrap.sh
make

on Cygwin (Win7, 64bit, latest cygwin from today)

[...]
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -I/usr/include/libxml2 -I../include -I../include -Wall -I../optional/glpk -g -O2 -I/usr/include/libxml2 -MT libigraph_la-matching.lo -MD -MP -MF .deps/libigraph_la-matching.Tpo -c matching.c  -DDLL_EXPORT -DPIC -o .libs/libigraph_la-matching.o
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -I/usr/include/libxml2 -I../include -I../include -Wall -I../optional/glpk -g -O2 -I/usr/include/libxml2 -MT libigraph_la-matching.lo -MD -MP -MF .deps/libigraph_la-matching.Tpo -c matching.c -o libigraph_la-matching.o >/dev/null 2>&1
mv -f .deps/libigraph_la-matching.Tpo .deps/libigraph_la-matching.Plo
/bin/sh ../libtool  --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I. -I..   -g -O2 -I/usr/include/libxml2 -I../include  -I../include -Wall -I../optional/glpk -g -O2 -I/usr/include/libxml2 -MT libigraph_la-lad.lo -MD -MP -MF .deps/libigraph_la-lad.Tpo -c -o libigraph_la-lad.lo `test -f 'lad.c' || echo './'`lad.c
libtool: compile:  gcc -DHAVE_CONFIG_H -I. -I.. -g -O2 -I/usr/include/libxml2 -I../include -I../include -Wall -I../optional/glpk -g -O2 -I/usr/include/libxml2 -MT libigraph_la-lad.lo -MD -MP -MF .deps/libigraph_la-lad.Tpo -c lad.c  -DDLL_EXPORT -DPIC -o .libs/libigraph_la-lad.o
In file included from lad.c:58:
igraph_interrupt_internal.h:43: warning: `thread' attribute directive ignored
lad.c: In function `igraph_i_lad_createGraph':
lad.c:769: error: prior parameter's size depends on 'nbU'
lad.c:769: error: prior parameter's size depends on 'nbV'
lad.c:795: error: prior parameter's size depends on 'nbU'
lad.c:795: error: prior parameter's size depends on 'nbV'
lad.c:795: error: prior parameter's size depends on 'nbV'
lad.c:795: error: prior parameter's size depends on 'nbU'
lad.c:786: confused by earlier errors, bailing out
Makefile:5165: recipe for target `libigraph_la-lad.lo' failed
make[3]: *** [libigraph_la-lad.lo] Error 1
make[3]: Leaving directory `/cygdrive/c/data/external/igraph/src'
Makefile:1149: recipe for target `all' failed
make[2]: *** [all] Error 2
make[2]: Leaving directory `/cygdrive/c/data/external/igraph/src'
Makefile:418: recipe for target `all-recursive' failed
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/cygdrive/c/data/external/igraph'
Makefile:318: recipe for target `all' failed
make: *** [all] Error 2

[This is still the same comilation error as in https://bugs.launchpad.net/igraph/+bug/1132270]

Flexible random number generator

It should be possible to use alternative generators, e.g. one from GSL, or anything else. Let's check the RNG model in GSL and create a "random number generator table" according to that.


Imported from Launchpad using lp2gh.

Check functions for integer overflow

In particular, all the functions that consider number of geodesics at some point might contain an integer overflow. Let's start with betweenness and edge_betweenness, I am sure that there are more, of course.

In case of integer overflow we just return an error with a new error code, IGRAPH_EINTOVERFLOW or something like that.


Imported from Launchpad using lp2gh.

Union, intersection, etc. (?) based on an attribute

At least, there should be methods for union and intersection, based on a vertex attribute.


Imported from Launchpad using lp2gh.

Code:

  • graph.disjoint.union
  • graph.union
  • graph.intersection
  • graph.difference
  • graph.compose
  • what should "+" do for named graphs? union or disjoint union?
  • warning for non-unique vertex names after a disjoint union

Docs:

  • graph.disjoint.union
  • graph.union
  • graph.intersection
  • graph.difference
  • graph.compose

R: attribute assignment via indexing deletes edges

This is probably not intended.

g <- graph.ring(10)
g1 <- g
g1[from = el[,1], to = el[,2], attr = "rtdev"] <- rep(0,10)
g1

IGRAPH U--- 10 0 -- Ring graph

+ attr: name (g/c), mutual (g/x), circular (g/x)

g1 <- g
g1[from = el[,1], to = el[,2], attr = "rtdev"] <- c(1,2,3,4,5,6,7,8,9,10)
g1

IGRAPH U--- 10 10 -- Ring graph

+ attr: name (g/c), mutual (g/x), circular (g/x), rtdev (e/n)

g1[from = el[,1], to = el[,2], attr = "rtdev"] <- c(0,2,3,4,5,6,7,8,9,10)
g1

IGRAPH U--- 10 0 -- Ring graph

+ attr: name (g/c), mutual (g/x), circular (g/x), rtdev (e/n)

g1 <- g
g1[from = el[,1], to = el[,2], attr = "rtdev"] <- 1
g1

IGRAPH U--- 10 10 -- Ring graph

+ attr: name (g/c), mutual (g/x), circular (g/x), rtdev (e/n)

g1[from = el[2,1], to = el[2,2], attr = "rtdev"] <- 0
g1

IGRAPH U--- 10 9 -- Ring graph

+ attr: name (g/c), mutual (g/x), circular (g/x), rtdev (e/n)


Imported from Launchpad using lp2gh.

R: graph.incidence skips 'directed' argument

See

inc <- matrix(sample(0:1, 15, repl=TRUE), 3, 5)
colnames(inc) <- letters[1:5]
rownames(inc) <- LETTERS[1:3]
i <- graph.incidence(inc, directed=T)
summary(i) # it's not a directed graph

It has to do something with the 'mode' argument, because
i2 <- igraph:::graph.incidence.dense(inc, directed=TRUE, mode="out", multiple=FALSE, weighted=NULL)
works well, but
i2 <- igraph:::graph.incidence.dense(inc, directed=TRUE, mode=1, multiple=FALSE, weighted=NULL)
does not.


Imported from Launchpad using lp2gh.

Negative/overflowing betweenness values in igraph_betweenness

Yong Zou reported that igraph_betweenness returns suspiciously large or negative betweenness values for some graphs. Yong's graphs work perfectly fine on Linux (openSuSE 11.1, gcc 4.3.2, igraph 0.5.2) but they reproduce the error on OS X (gcc 4.0.1, igraph 0.5.2). Apparently some entries in the nrgeo vector in igraph_betweenness_estimate get negative somehow at some point.


Imported from Launchpad using lp2gh.

Some test cases fail

2: Vector (more) (vector_t): FAILED (types.at:31)
18: 2-way heap (igraph_2wheap_t): FAILED (types.at:111)
108: Reading a Pajek file with attributes: FAILED (attributes.at:26)


Imported from Launchpad using lp2gh.

R interface: graph.adjacency.sparse bug, if matrix is dgTMatrix

The triplet representation of matrices in the R Matrix package allows for repetition of elements, which seems to be a problem when converting these matrices into igraph.

the following reproduces the issue

require("Matrix")
M = spMatrix(2,2,c(1,1),c(2,2),c(1,1))
M[1,2] # correct value is 2
summary(M) #notice repetition
2 x 2 sparse Matrix of class "dgTMatrix", with 2 entries
i j x
1 1 2 1
2 1 2 1
require("igraph")
graph.adjacency(M, mode="directed", weighted=TRUE) #repitition carries over
Vertices: 2
Edges: 2
Directed: TRUE
Edges:

[0] 0 -> 1
[1] 0 -> 1

This really is a bug, since the correct weighted value is 2.

Note that this repetition occurs when adding up matrices. I discovered it when adding the transpose of a matrix to itself, and the resulting summary was wrong.

To correct this, this code converts a matrix into the compressed sparse form which does not allow repetition

if(class(matrix)[1] =="dgTMatrix") {
matrix = as(matrix, "CsparseMatrix") #to remove non-redundancies that can persist in a dgtMatrix
}

Sasha Goodman
Doctoral Student, Organizational Behavior


Imported from Launchpad using lp2gh.

Make attribute handler interface more flexible

We need to be able to handle graph, vertex and edge attributes separately. Moreover we need a general indexing function for vertex and edge attributes. Plus maybe an option to call callback functions to calculate the attributes of the new graph. E.g. if two edges are merged into one, a callback function could be called to add/multiply/whatever the corresponding edge attributes.


Imported from Launchpad using lp2gh.

ubuntu debian package wrong directory

The debian packages weren't working for me while using Ubuntu 9.04's netbook remix. My symptom was precisely as this user reported in a ubuntu forum: http://ubuntuforums.org/showthread.php?p=7298407.

I fixed it by moving one directory, as I also recount at the prior link: http://ubuntuforums.org/showthread.php?p=7298407


Imported from Launchpad using lp2gh.

Add Jeroen's request to the "GUI"

[...]
Could you please add the option to choose directed/undirected when importing data, the same as you have when creating data in the GUI itself?
In the current version, if you save as a list of an undirected network, you lose the 'undirectedness', and the next time you import the data, the network is regarded as directed, and if you save as a matrix, you lose the identities.
[...]
Could you then add to the GUI a knob for

plot(degree.distribution(b, mode="in"), log="xy")

and another one for

power.law.fit( degree(b, mode="in"), xmin=10)
[...]


Imported from Launchpad using lp2gh.

R package: clean unload

library.dynam.unload() does work if the OS is cooperative. And if you have your package set up correctly and unload the namespace (and not just detach the package if there is a namespace) then the shared object/DLL will be unloaded. There are examples in several base R packages (grDevices, grid, methods, splines, stats, tools).

However, there are several instances on Windows (tcltk is one) where reloading the package DLL does not work, and this seems to be because dependent DLLs are already loaded and do not run their initializations correctly. I've not seen problems on Linux. On Solaris reloading a different shared object of the same name into a process used not to work (you got the first version under that name): I've not checked recently.

On Fri, 20 Feb 2009, Gábor Csárdi wrote:

Hmmm, I think restarting R is not a very good solution. It is rather
ugly in the first place. But perhaps even more importantly, it can be
rather inconvenient if one has a large data set in the memory and
needs to save/load it just to reload a package that was updated in the
meanwhile.

This happens to me quite often with 20-40Gb of data, so I would really
love to have a solution for proper detach/unload.

Why not use the one already provided?

  • Show quoted text -

    Best,
    Gabor

    On Fri, Feb 20, 2009 at 1:32 AM, Duncan Murdoch wrote:

    On 19/02/2009 6:19 PM, Alex F. Bokov wrote:
    
    
        Hello. To save the hassle of quitting and restarting R every time I
        rebuild the package I'm working on (for the purposes of this question called
        "roots") I would like to write a script cleanly remove the package from my R
        session and then load it again. Of course detach("package:roots") works for
        the native R objects in the package. However, the compiled C library remains
        loaded. Using library.dynam.unload as documented results in:
    
        Error in library.dynam.unload("roots.so",
        "~/R/x86_64-pc-linux-gnu-library/2.8/roots/libs/") :
         shared library 'roots' was not loaded
    
        I also tried the above command with the file extension omitted and the
        last one and two levels of the directory path omitted. In both cases I still
        get the "not loaded" error. I've also Googled the list archives and while
        there were several questions like mine, none of them were answered by the
        list. Am I to believe that this is something hardly anybody does? Does this
        mean everybody sits around waiting for R to start up everytime they make a
        minor change to the C source?
    
        If there is a tutorial for doing this, I'd much appreciate the link.
    
    
    
    This is more of an R-devel question than R-help, so if this doesn't answer
    your question, please follow up there.
    
    On Windows, the following sort of works:
    
        library(rgl)
        .dynLibs()
    
                                             Filename Dynamic.Lookup
    1     F:/R/R-2.8.1/library/methods/libs/methods.dll          FALSE
    2 F:/R/R-2.8.1/library/grDevices/libs/grDevices.dll          FALSE
    3         F:/R/R-2.8.1/library/stats/libs/stats.dll          FALSE
    4             F:/R/R-2.8.1/library/rgl/libs/rgl.dll           TRUE
    
        library.dynam.unload("rgl", "F:/R/R-2.8.1/library/rgl")
    
    
    I say "sort of", in that I get no error messages and the dll is no longer
    locked in use as it normally would be in Windows, but reloading the package
    doesn't function properly. It's possible some combination of detach() and
    unloadNamespace() would get a clean unload, but really, I normally just quit
    R and restart.  It's pretty quick to start up, compared to the recompile
    time for the package.
    
    Duncan Murdoch
    
    ______________________________________________
    <email address hidden> mailing list
    https://stat.ethz.ch/mailman/listinfo/r-help
    PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
    and provide commented, minimal, self-contained, reproducible code.
    

    Gabor Csardi UNIL DGM

    mailing list
    https://stat.ethz.ch/mailman/listinfo/r-help
    PLEASE do read the posting guide http://www.R-project.org/posting-guide.html
    and provide commented, minimal, self-contained, reproducible code.

Brian D. Ripley,
Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/
University of Oxford, Tel: +44 1865 272861 (self)
1 South Parks Road, +44 1865 272866 (PA)
Oxford OX1 3TG, UK Fax: +44 1865 272595


Imported from Launchpad using lp2gh.

negative closeness values?

When using cutoffs, I can produce negative closeness values, which AFAIK shouldn't be possible.

>>> print g_giant.summary()
IGRAPH UN-- 68303 184788 -- 
+ attr: name (v)

>>> _id = 0
>>> for i in range(1,20):
>>>     print str(i) + ": " + str(g_giant.closeness(vertices=[_id], cutoff=i))
>>> print str("oo") + ": " + str(g_giant.closeness(vertices=[_id], cutoff=0))

1: [0.00018463857449137346]
2: [0.00018646324811754687]
3: [0.00019331169771785695]
4: [0.00021734321395232314]
5: [0.00040565599510438034]
6: [-0.00023178404736435846]
7: [-5.625506191677867e-05]
8: [3.432949157412304e-05]
9: [6.243362890574019e-05]
10: [0.00012521807634011635]
11: [0.0002605744451427101]
12: [0.0005577231725167555]
13: [0.001118365372989965]
14: [0.002562406848171298]
15: [0.006123525555601777]
16: [0.019109864514188588]
17: [0.03947058949304026]
18: [0.10707438394840514]
19: [0.11991032445063192]
oo: [0.11991032445063192]

Using other ids, the same happens around cutoff=5-7

Add a 'to' argument to shortest paths calculation

The two things we gain are: 1) we can stop the algorithm as soon as all vertices in 'to' are reached and 2) we can allocate a smaller matrix, less memory is needed for the computation, compared to calculating shortest paths to all vertices and then taking the relevant subset.


Imported from Launchpad using lp2gh.

Use sampling in betweenness centrality

[This description was messed up during the Launchpad -> Github move, but it was restored to what I believe the original description was. (Gabor) ]

This is https://bugs.launchpad.net/igraph/+bug/1090728

The basic idea is to not use the whole graph but just a sample of vertices and compute betweenness based on this sample.

http://www.inf.uni-konstanz.de/algo/publications/bp-celn-06.pdf

I tried implmenting this in python, but it is slower already for a 25% sample, which results in correlation values of ~0.5 to the real betweenness (sample graph: igraph.Graph.Erdos_Renyi(4000,0.05))

def betweeness_estimate(g, p=0.2, normalized=True):
    # Betweeness: how often is the given vertex on the shortest path?
    import collections
    import random
    import itertools
    no_vertices = len(g.vs)
    sample_number = int(no_vertices*p)
    #print("sample# %s; complete: %s" % (sample_number,no_vertices))
    assert sample_number > 2, "Sample too small, specify higher number of vertices"
    sample = random.sample(range(no_vertices), sample_number)
    values = collections.defaultdict(float)
    # first get all the shortest path
    for vertex in sample:
        shortest_paths = g.get_all_shortest_paths(vertex, to=sample)
        _cache = collections.defaultdict(float)
        _cur_last = -1
        _no_paths = 0
        # Now add one for each middle vertex in the result
        for path in shortest_paths:
            if len(path) < 3:
                continue
            _no_paths += 1
            if _cur_last != path[-1]:
                # A change in the endpoint, so 
                # add the no of shortest path to the max_values cache
                for v in _cache.keys():
                    values[v] += float(_cache[v]) / _no_paths
                _cache = collections.defaultdict(float)
                _no_paths = 0
                _cur_last = path[-1]
            for i in path[1:-1]:
                _cache[i] += 1
    result = map(values.__getitem__, range(no_vertices))
    if normalized:
        _min, _max = min(result), max(result)
        result = map(lambda x: (x-_min)/(_max - _min), result)
    return result

This sampling algorithm is also implemented in networkx directly in the betweenness function: https://github.com/networkx/networkx/blob/master/networkx/algorithms/centrality/betweenness.py

There the difference boils down to not iterate over all vertices of the graph in the shortest path finding section but just use the sample:

if k is None:
    nodes = G
else:
    random.seed(seed)
    nodes = random.sample(G.nodes(), k)
for s in nodes:
    [shortest path finding]

and in the end rescaling the values differently.

Would it be possible to also include such a sampling in igraph c layer?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.