Re: [igraph] invertible matrix

[Tamas Nepusz]

Hi Gabor,

igraph-related discussions and support have been moved to the igraph
Discourse group at https://igraph.discourse.group; please ask your question
here as many people are not following the mailing list any more.

All the best,
Tamás


On Fri, 3 Jul 2020 at 01:12, Gabor Toth  wrote:

> Hi,
>
> I am building a markov chain model from different transition matrices; some
> of my matrices are singular and its inverse cannot be retrieved. I am
> wondering if there is any igraph method to import my transition matrix and
> to transform it into a subgraph that is invertible.
>
> Many thanks,
>
> Gabor
>
> P.S.: Just realized that I had earlier sent this message to igraph
> announce mail list, sorry!
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Write Graph with Attributes

[Tamas Nepusz]

Dear Peng,

The Pajek format is a bit problematic as there exists no formal
specification for it so we don't know what is the "official" way to store
any arbitrary vertex or edge attributes in this format.

To complicate matters further, the Pajek file also contains
visualization-related data (e.g. vertex color, font size, edge widths etc).
igraph_read_graph_pajek() processes these and then converts them to vertex
/ edge attributes with more meaningful names; see this page for more
details:

https://igraph.org/c/doc/igraph-Foreign.html#igraph_read_graph_pajek

igraph_write_graph_pajek() recognizes these attributes only and converts
them back to the appropriate fields in the Pajek output.

If storing vertex / edge attributes is important to you, I advise you to
use a more formalized graph format such as GraphML if that's possible in
your project.

Also, please note that the igraph-help mailing list is about to shut down
soon. The discussion forums have been moved to Discourse at
https://igraph.discourse.group -- you are more likely to get responses
there than on the mailing list.

All the best,
T.


On Thu, 18 Jun 2020 at 13:42, Peng He  wrote:

> Dear igraph C library users,
>
> I wonder if any of you knows why igraph_write_graph_pajek can not save
> vertex/edge attributes along with the edge list? Could any one give some
> hints on how to save all the metadata of a graph in igraph C library?
>
> Thanks in advance!
> Peng
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Editing edge attributes in igraph

[Tamas Nepusz]

Dear Faith,

The mailing list is about to shut down soon; all igraph-related discussion
has been moved to our discussion forum at https://igraph.discourse.group.
Please ask your question there (and mention that it probably refers to the
R version of igraph -- the C core of igraph does not do any plotting, and
in general the plotting capabilities of higher level interfaces differ from
each other so it's important to know which language you are using igraph
from).

All the best,
T.


On Tue, 2 Jun 2020 at 11:58, Ebhodaghe Faith 
wrote:

> Dear All,
> I'm attempting to construct an interaction network in *igrap* but not
> clear about how to edit edge attributes, for example, increasing the
> thickness of an edge where organisims interact more frequently and creating
> edges having dots or broken lines where organisms do not interact.
>
> Thanks in advance.
>
> Faith
> *Kenya*
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] igraph R read_graph

[Tamas Nepusz]

Hi,

Judging from the source code of the R interface, it seems like that the
file simply doesn't exist; I get the same error message if I try something
like read_graph("this_file_does_not_exist", "graphml").

Can it be the case that your file is called "Network.graphml" and not
"network.graphml"? At least this is the case for the attachment...

T.


On Mon, 4 May 2020 at 19:53, Narges Zarnaghinaghsh 
wrote:

> Hi,
>
> I want to read the attached graphml file in R using the command:
>
> read_graph("network.graphml", "graphml")
>
> But it shows the following error:
>
> Error in read.graph.graphml(file, ...) :
>   At rinterface.c:6077 : Cannot open GraphML file, File operation error
>
> Do you know what the problem is and how I can solve it?
>
> Regards,
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] igraph for python plotting using pycairo on mac OScatalina (10.15.4)

[Tamas Nepusz]

Hi,

python-igraph simply tries to import pycairo or cairocffi when it
initializes the plotting module. If the import fails, it simply throws a
"plotting not available" exception for all plotting attempts. So, to figure
out what's wrong, try to import pycairo from the same Python session where
you see this error -- this should give you a hint about what's wrong. Most
likely pycairo is not installed correctly.

T.


On Sun, 29 Mar 2020 at 22:11, Siddhartha R Dalal 
wrote:

> Hi Group: I would appreciate if someone can help regarding whak cairo to
> install and how to run with python3. I have successfully installed
> python-igraph and everything works fine. However, as suggested, I installed
> cairo (from Apple App), that didn't work, so I installed  pycairo as
> suggested in
> https://stackoverflow.com/questions/36225410/installing-cairo-and-pycairo-mac-osx
> However, I am still getting error-
> import igraph
> from igraph import *
> g = Graph([(0,1), (0,2), (2,3), (3,4), (4,2), (2,5), (5,0), (6,3), (5,6)])
> layout = g.layout("kk")
> plot(g, layout = layout)
>
> I get the following error:
>
> TypeError Traceback (most recent call 
> last) in ()  7 print(g.degree())
>   8 layout = g.layout("kk")> 9 plot(g, layout = layout)
> ~/anaconda3/lib/python3.6/site-packages/igraph/drawing/__init__.py in 
> plot(obj, target, bbox, *args, **kwds)453 bbox = 
> BoundingBox(bbox)454 --> 455 result = Plot(target, bbox, 
> background=kwds.get("background", "white"))456 457 if "margin" in 
> kwds:
> ~/anaconda3/lib/python3.6/site-packages/igraph/drawing/__init__.py in 
> __init__(self, target, bbox, palette, background)118 """119   
>   self._filename = None--> 120 self._surface_was_created = not 
> isinstance(target, cairo.Surface)121 self._need_tmpfile = False   
>  122
> ~/anaconda3/lib/python3.6/site-packages/igraph/drawing/utils.py in 
> __getattr__(self, _)394 395 def __getattr__(self, _):--> 396  
>raise TypeError("plotting not available")397 def __call__(self, 
> _):398 raise TypeError("plotting not available")
> TypeError: plotting not available
>
> Thank you. Sid
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] (no subject)

[Tamas Nepusz]

>
> So I need to use the  Deep First Search algorithm from a random node and
> stop the algorithm when the sum of node or vertices weights in the DFS
> sub-graph achieve a certain limit.
>
> Could you please help me telling if it is possible with the dfs igraph
> function?
>
Are you working from C? If so, you can use the "in_callback" and
"out_callback" arguments of igraph_dfs to call arbitrary functions when the
DFS starts visiting a node or when the DFS is done with a node and its
subgraph. You can also return a non-zero value from the callback functions
to request igraph to terminate the search.

Documentation here:

https://igraph.org/c/doc/igraph-Visitors.html#igraph_dfs
https://igraph.org/c/doc/igraph-Visitors.html#igraph_dfshandler_t

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] [Possible Bug - python igraph]

[Tamas Nepusz]

> I am writing in reference to a problem with python-graph. When I use the
> motifs_randesu() function, the list returned have nan values, it’s my
> problem this is a bug?
> If it’s a bug, should I report it to igraph/python-igraph or igraph/igraph?
>

This is not a bug; the RANDESU motifs algorithm does not count disconnected
motifs, so we return NaN for these slots (instead of 0, which would
indicate that the motifs were counted and there were zero of them). This is
documented here:

https://igraph.org/c/doc/igraph-Motifs.html#igraph_motifs_randesu

Also, please note that the mailing list will be shut down soon and the
primary support forum for igraph is its Discourse group at
https://igraph.discourse.group

All the best,
T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] weighted random walks with R igraph

[Tamas Nepusz]

For purposes of the mailing list archive: this is now being discussed in
https://github.com/igraph/igraph/issues/981

@vtraag said:

"no it is not yet implemented in the R interface. We are currently working
on updating the R interface to the recently released C core, version 0.8.0,
see igraph/rigraph#372 . If
that is done, the new contributions could start to be added."

T.


On Wed, 26 Feb 2020 at 21:10, Dr Gregory Jefferis <
jeffe...@mrc-lmb.cam.ac.uk> wrote:

> Hello,
>
> I would like to generate weighted random walks i.e. where the transition
> probabilities are proportional to the edge weights leaving a node. I am
> using R. It looks like this is implemented in C but not R. Is this
> correct? See https://github.com/igraph/igraph/issues/981
>
> Would you have any suggestions about how to do this from the R
> interface? Other than implementing the wrapper for
> igraph_random_edge_walk?
>
> With many thanks,
>
> Greg Jefferis.
>
> --
> Gregory Jefferis
> Division of Neurobiology
> MRC Laboratory of Molecular Biology
> Francis Crick Avenue
> Cambridge Biomedical Campus
> Cambridge, CB2 OQH, UK
>
> http://www2.mrc-lmb.cam.ac.uk/group-leaders/h-to-m/g-jefferis
> http://jefferislab.org
> https://www.zoo.cam.ac.uk/research/groups/connectomics
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Walktrap Algorithm

[Tamas Nepusz]

Hello,

"Error in igraph::cluster_walktrap(c, weights = c$weight, steps = 4, merges
> = TRUE,  :
>   Not a graph object!"
>
You cannot pass a graph object from another graph library (qgraph in this
case) to the igraph library. You need to create a graph using igraph's own
functions.

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Hi

[Tamas Nepusz]

>
> Are  the ant colony optimization(ACO) algorithm included in the  (igraph)
> package in the RStudio language?
>
No, it isn't included.

All the best,
T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

[igraph] new igraph forum

[Tamas Nepusz]

Dear All,

With the release of igraph 0.8.0 and the update of the homepage, we have
also decided to move our main igraph support channel from the
igraph-help@nongnu.org mailing list to a Discourse group at the following
URL:

https://igraph.discourse.group

Subscribers of the igraph-help mailing list are now encouraged to register
an account at Discourse and start opening new threads for support
questions, discussions and feature ideas in the Discourse group.

I will keep on responding to emails on the mailing list for the next few
weeks. The planned shutdown date of the mailing list is May 1, 2020. We
will strive to keep the mailing list archives online.

All the best,
Tamás
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

[igraph] igraph 0.8.0

[Tamas Nepusz]

Dear All,

igraph 0.8.0 is finally released!

This release of igraph's C core, coming almost five years after 0.7.1, is a
major improvement with several new features, performance and robustness
improvements, and many bug fixes. New functionality includes additional
graph generators, functions for handling trees, new community detection
methods, improved clique finding, spectral graph embedding, as well as
several other features. Please see the changelog for more details:

https://github.com/igraph/igraph/blob/master/CHANGELOG.md

We would like to thank everyone who reported issues, contributed features
or fixes, or edited the documentation. igraph is an open-source project run
by volunteers. As always, your contributions are very welcome!

Most people use igraph through its high-level interfaces for R, Python or
Mathematica. A new release of the Python interface, incorporating all these
improvements, is expected to be released in a few weeks. The R and
Mathematica interfaces already include some of the improvements, and will
continue to integrate more.

Concurrently with the release of igraph 0.8, we are launching a new
community forum on Discourse, which will replace the mailing list as the
main support channel. If you are a current igraph user or just interested
in the project, please join at:

https://igraph.discourse.group

Best regards,
Tamás
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] personalized pagerank computation issue

[Tamas Nepusz]

Hi Omer,

Your comment rang a bell -- I remembered that this issue has already popped
up back in 2014 when we first switched from ARPACK to PRPACK; see the
following issue in the issue tracker:

https://github.com/igraph/igraph/issues/671

Memories of mine about PRPACK were much fresher by then as I wrote the
following:

   - with the ARPACK implementation, the random walker teleports according
   to the distribution of the reset vector when it encounters a dangling node
   - with the PRPACK implementation, the random walker teleports according
   to a uniform distribution by default.

After reading the thread, it also became apparent that PRPACK is doing some
trickery with sink nodes; the following is from @dgleich, one of the
original authors of PRPACK:

"For the case that you are jumping to nodes that have no outgoing edges,
what happens is you add new edges according to the teleportation set/reset
set or the special set "u"."

So, all in all, the case is probably that your implementation matches the
ARPACK implementation of PRPACK from igraph, and that's why you are seeing
identical results (both your code and igraph's ARPACK implementation
formulates PageRank as an eigenvector problem and solves that). In case of
PRPACK, PageRank is not an eigenvector problem any more; again,
quoting @dgleich:

"PRPACK does decompose the graph into SCCs, but the primary advantage is
that it frames the PageRank problem as a linear system instead of the
eigenvalue problem. This has tremendous numerical advantages."

There was also a PR quite a while ago that attempted to introduce the
possibility of specifying the personalization vector and the reset vector
separately, but it did not get merged in the end:

https://github.com/igraph/igraph/pull/673

Another issue where this question popped up -- maybe it also provides more
insight:

https://github.com/igraph/igraph/issues/1211

Best,
T.


On Mon, 27 Jan 2020 at 23:17, Yalcin, Omer Faruk  wrote:

> Thank you very much for tracking the code! Unfortunately, that doesn't
> work either. I am also fairly certain that allowing the node to stay at the
> same spot would give that node an unwarranted boost in pagerank, so it is
> probably undesirable.
>
> I do have an interesting result though; when I use "arpack" instead of the
> default "prpack", I get the exact same results as my custom written
> function. In other words, when there are nodes that have no outgoing edges,
> "prpack" and "arpack" do the computation differently.
>
> My problem seems to be solved (as long as there is no reason why "arpack"
> is wrong) but this difference between the two algorithms might be of
> interest to you.
>
> Thank you very much.
> Omer
> --
> *From:* Tamas Nepusz 
> *Sent:* Monday, January 27, 2020 4:15 PM
> *To:* Yalcin, Omer Faruk 
> *Cc:* Help for igraph users 
> *Subject:* Re: [igraph] personalized pagerank computation issue
>
>
> That being said, after your question, I set the probability of navigating
> to other nodes from a node that has no outbound links to the
> personalization vector. That doesn't reproduce the igraph result either.
>
> There's also a third option: if there are no outbound nodes, stay at the
> same node with probability equal to 1-damping, _or_ navigate to a randomly
> picked node accoding to the persionalization vector with probability equal
> to damping. Sorry for not being too precise here; the thing is that igraph
> is using an external library (PRPACK) to calculate personalized PageRank
> scores, and I only managed to track the code to a point where I am
> convinced that we are passing down two  vectors to PRPACK; one is a uniform
> vector, and the other one is the personalization vector submitted by the
> user. Based on this, I would assume that PRPACK uses the personalization
> vector when the random walk is reset, and the uniform vector for a random
> teleport (after all, why would PRPACK need two vectors if it used the
> personalization vector for both cases?), but I did not manage to track it
> down further because PRPACK contains at least six different solvers,
> optimized for different use-cases, and I did not manage to figure out which
> one it would use in your particular case. But I'm pretty sure that the
> discrepancy between your results and ours is due to some corner case in the
> handling of sink nodes.
>
> T.
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] question re: sample_traits_callaway()

[Tamas Nepusz]

>
>
> Is the type stored anywhere that I am not thinking of?
>
Judging from the source code of the graph generator in the C layer, I'm
afraid that the vertex types are discarded after the graph is generated, so
you won't be able to retrieve it from the generated graph.

Best regards,
T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] personalized pagerank computation issue

[Tamas Nepusz]

> That being said, after your question, I set the probability of navigating
> to other nodes from a node that has no outbound links to the
> personalization vector. That doesn't reproduce the igraph result either.
>
There's also a third option: if there are no outbound nodes, stay at the
same node with probability equal to 1-damping, _or_ navigate to a randomly
picked node accoding to the persionalization vector with probability equal
to damping. Sorry for not being too precise here; the thing is that igraph
is using an external library (PRPACK) to calculate personalized PageRank
scores, and I only managed to track the code to a point where I am
convinced that we are passing down two  vectors to PRPACK; one is a uniform
vector, and the other one is the personalization vector submitted by the
user. Based on this, I would assume that PRPACK uses the personalization
vector when the random walk is reset, and the uniform vector for a random
teleport (after all, why would PRPACK need two vectors if it used the
personalization vector for both cases?), but I did not manage to track it
down further because PRPACK contains at least six different solvers,
optimized for different use-cases, and I did not manage to figure out which
one it would use in your particular case. But I'm pretty sure that the
discrepancy between your results and ours is due to some corner case in the
handling of sink nodes.

T.

>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] personalized pagerank computation issue

[Tamas Nepusz]

>
>
>- However, if I use personalized but some nodes have no outgoing
>edges, *then the results differ*.
>
> How does your algorithm handle nodes with no outbound edges? When your
random walker reaches such a node, does it jump randomly to any other node
in the graph chosen from a uniform distribution, does it jump back to the
starting point, does it jump back to some random node based on the
personalization vector, or some other option?

All the best,
T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Is it possible to change the font of labels in Python?

[Tamas Nepusz]

> Distance between vertex and label, size of label font and angle of label
> can be defined using keywords, but font of labels doesnt seem to be able to
> be defined. It seems that in igraph in R, fonts can be defined,but in
> Python the keyword seems useless.
>
The plotting backends in R and Python are completely different, so it is
not guaranteed that the same keywords work for both backends.
For what it's worth, changing the font in Python is not supported because
the underlying drawing backend (Cairo) has no standardized way of dealing
with fonts on different platforms. You might be able to get around with a
workaround posted in this answer on Stack Overflow (but this might or might
not work on your platform, depending on what the Cairo implementation
supports there):

https://stackoverflow.com/a/24231607/156771

All the best,
T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] igraph installation issue in Linux server

[Tamas Nepusz]

Hi,

I'm not sure what the compiler complains about here; in my version,
refine_equal_to_first in bliss/graph.hh is not initialized to anything, and
neither it is in the official tarball of the igraph package.

Can you try updating your compiler to a newer version, or, alternatively,
try installing the development version of the R package of igraph from
Github? It can be done like this:

devtools::install_github("gaborcsardi/pkgconfig")

devtools::install_github("igraph/rigraph")


T.


On Tue, 10 Dec 2019 at 02:40, Dineshkumar Subbu <
dineshkumarsubb...@gmail.com> wrote:

> Hi Team,
>
> While installing igrpah in my linux server I'm getting the following the
> error.  Currently my server have (gcc version 4.4.7 20120313 (Red Hat
> 4.4.7-4) (GCC)).
>
> Please help me how to install igraph package.
>
> In file included from bliss.cc:20:
> bliss/graph.hh:326: error: ISO C++ forbids initialization of member
> ârefine_equal_to_firstâ
> bliss/graph.hh:326: error: making ârefine_equal_to_firstâ static
> bliss/graph.hh:326: error: ISO C++ forbids in-class initialization of
> non-const static member ârefine_equal_to_firstâ
> make: *** [bliss.o] Error 1
> ERROR: compilation failed for package âigraphâ
> * removing â/home/orsspoc1/r_local_installation/igraphâ
>
> The downloaded source packages are in
> â/tmp/Rtmp5t6KpB/downloaded_packagesâ
> Warning message:
> In install.packages("igraph", repos = "http://cran.rstudio.com";,  :
>   installation of package âigraphâ had non-zero exit status
>
> Regards,
> Dinesh
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] igraph issue with massive matrices

[Tamas Nepusz]

> I am not sure why this happens.  On one hand, I may be running into a
> memory limit in R, but the other behaviours may be related to limits within
> igraph.
>
>
>
> Would you have some insight or advice on this issue?
>
It's hard to say anything at this stage; it could well be a bug on igraph's
side, but the only way I could test it is if I could reproduce it on my
side. Is there some small, self-contained example that reproduces the bug
and that you could share with us?

All the best,
Tamás
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] R: vertex attributes in bipartite graphs for only one vertex type

[Tamas Nepusz]

> Many thanks for your reply! Also thank you for explaining that igraph
> does not check whether the topology is really bipartite. I had been
> wondering about that too.
>

Note that if you need to check whether the topology is bipartite (or
_could_ be bipartite with an appropriate mapping), you can use
bipartite_mapping():

https://www.rdocumentation.org/packages/igraph/versions/1.2.4/topics/bipartite_mapping

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] R: vertex attributes in bipartite graphs for only one vertex type

[Tamas Nepusz]

> Is there some way to create a vertex attribute that is only attached
> to one vertex type in a bipartite graph (in this example the vertices
> for which V(g)$type == FALSE)?
>
Unfortunately there's no way to do that; this is because bipartite graphs
in igraph are simply "normal" graphs with a "type" vertex attribute and an
additional property that edges never go between vertices of the same type.
(But this is not even enforced; you can create such an edge if you really
want to). So, for the time being you need to settle with having NA as the
"gender" for the company vertices. Try to think about NA as "not
applicable", which actually sort-of-makes sense for companies :)

All the best,
Tamas
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] vertex attribute in bipartite network

[Tamas Nepusz]

> how to create igraph bipartite network that has vertex attribute?
>

V(g)$attribute.name <- attribute.values

E.g.:

V(g)$name = sapply(1:vcount(g), function (x) { paste("Node", x) })

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] fruchterman reingold

[Tamas Nepusz]

>  In python igraph version, g=Graph();
> g.layout_fruchterman_reingold(weights=edgeweightlist) function in igraph
> produces different layout of graph each time for same graph nodes and same
> edgeweightlist. How to turn off this randomness to produce the same graph
> each time?
>

Just set the seed of the random number generator to an arbitrary fixed
value before calling the layout function:

>>> from random import seed
>>> from igraph import Graph
>>> g=Graph.GRG(100, 0.2)
>>> seed(1234)
>>> lo=g.layout("fr")
>>> lo[:10]
[[-7.319725822182468, -2.5222146293950525], [-6.042515482711504,
6.60729011892673], [-7.766841439471336, -1.072218029492348],
[-7.868509175067755, -6.519283541476223], [-6.607952925294913,
-5.512660296266184], [-6.89603463832, 3.5033722770007247],
[-7.439334008796665, -0.18725281663352827], [-6.568594470049888,
-6.971425023807268], [-7.610905586198632, -6.89027915495],
[-7.220889614908134, -1.5430061492566187]]
>>> seed(1234)
>>> lo=g.layout("fr")
>>> lo[:10]
[[-7.319725822182468, -2.5222146293950525], [-6.042515482711504,
6.60729011892673], [-7.766841439471336, -1.072218029492348],
[-7.868509175067755, -6.519283541476223], [-6.607952925294913,
-5.512660296266184], [-6.89603463832, 3.5033722770007247],
[-7.439334008796665, -0.18725281663352827], [-6.568594470049888,
-6.971425023807268], [-7.610905586198632, -6.89027915495],
[-7.220889614908134, -1.5430061492566187]]

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Using R igraph to create round arcs

[Tamas Nepusz]

> I like to know if you can have round arcs and straight arcs under one
> graph using igraph.
>
Yes; edge.curved=... may be a vector containing one item for each edge.
TRUE means curved edge, FALSE means straight edge; you may also pass
numbers to control how curved the edges should be.

Quoting the documentation:

"First the vector is replicated to have the same length as the number of
edges in the graph. Then it is interpreted for each edge separately. A
numeric value specifies the curvature of the edge; zero curvature means
straight edges, negative values means the edge bends clockwise, positive
values the opposite. TRUE means curvature 0.5, FALSE means curvature zero."

See https://igraph.org/r/doc/plot.common.html

Second, ggplot2 allows me to add lines to existing plot, can igraph
> provides this option?
>
Sorry, I don't know, I'm not that familiar with R.

All the best,
Tamas
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Using R igraph to create round arcs

[Tamas Nepusz]

Hi,

I think you need to use the edge.curved=... parameter when plotting:

plot(g, edge.curved=T)

See also here:

https://igraph.org/r/doc/plot.common.html (search for "curved")

T.


On Tue, 29 Oct 2019 at 02:03, Alon Friedman via igraph-help <
igraph-help@nongnu.org> wrote:

> Hello
> I like to know if I can create round arcs instead of straight line arcs
> using igraph R package?
> If so, can you provide more information or examples?
> Thank you
> Alon
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Interpretation of edge weights in the calculation of weighted diameter and weighted betweenness

[Tamas Nepusz]

> My 'raw' adjacency matrices have as values these numbers of co-occurrences
> (as you say: the number of interactions) between each pair of birds.
> However for constructing my networks I do not use these absolute values
> (nr. of occurrences) as edge weights but a standardized value. This
> standardized value is actually the number of co-occurences 2 birds have
> divided by the sum of all co-occurrences both of these 2 birds had with
> other birds (including with each other) during that day.
>

In this case the weights behave very much like "probabilities" for a random
walker that traverses the graph (the sum of weights of each outbound edge
incident on a node is 1); your best bet is a measure that has an underlying
random-walker-like assumption like eigenvector centrality or PageRank.

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Scale free graphs -best option?

[Tamas Nepusz]

> Which is the difference between these two functions?
>
> static.power.law.game
> barabasi.game
>
static.power.law.game is a non-growing model; you give it the desired
number of nodes and edges and then it will generate a graph for you whose
degree distribution should be a power-law _in the infinite limit_. (It
won't be if the number of nodes is relatively small, or if the number of
edges is relatively large compared to the number of nodes). Under the hood,
it assigns each node a "stickiness score" and creates edges between nodes
with a probability that is proportional to the "stickiness" of their
endpoints.

barabasi.game is a growing-model. It also generates power-law degree
distributions in the infinite limit, but:

1) the out-degree of each node will be the same (in the canonical form of
the model)
2) you need to specify the number of nodes and the number of outbound edges
_per node_ in advance
3) since it's a growing model and nodes are added along with their edges
one by one, each edge will point from a node that was added _later_ towards
a node that was added _earlier_. In other words, there will be a
topological ordering between the nodes and the generated graph will be
acyclic

Which would be best for this purpose?
>
It depends on the process that you want to model. If your process is a
growing one, the BA model is probably a better choice. If your process is
non-growing and / or there is no directionality in the relations, use the
static power-law model.

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Possible error in documentation of KS.p for R/igraph fit_power_law (or in my understanding)

[Tamas Nepusz]

>
> The ‘plfit’ implementation also uses the maximum likelihood principle to
> determine alpha for a given xmin; When xmin is not given in advance, the
> algorithm will attempt to find itsoptimal value *for which the p-value of
> a Kolmogorov-Smirnov test between the fitted distribution and the original
> sample is the largest.*
>
> This is not true; plfit does the opposite and looks for the _smallest_
value of the _KS test statistic_ instead (not the p-value); see this line
in the plfit code:

https://github.com/ntamas/plfit/blob/master/src/plfit.c#L1155

Basically, the test statistic of the Kolmogorov-Smirnov test is the largest
absolute difference between the observed and the fitted CDF along the Y
axis. A small test statistic means a good fit. However, it is probably true
that a smaller test statistic means a larger p-value, so in some sense the
documentation is correct, but it does not describe exactly what's going on
behind the scenes in the algorithm.

KS.pNumeric scalar, the p-value of the Kolmogorov-Smirnov test. *Small
> p-values (less than 0.05) indicate that the test rejected the hypothesis
> that the original data could have been drawn from the fitted power-law
> distribution*.
>
> This suggests that large KS.p means greater likelihood that the
> distribution could have come from the power-law distribution.
>

Let me explain what the underlined part means; I think it is correct.

The KS test goes like this. You have a null hypothesis that the observed
sample was drawn from a certain power-law distribution (whose parameters we
have determined with the fitting process). You calculate the test statistic
D, which is constructed in a way that smaller D values mean that the
observed sample is "more similar" to the CDF of the fitted power law.

The p-value is then the probability that, given that the null hypothesis is
true, the test statistic is larger than or equal to the test statistic that
we have observed. So, if you test statistic is, say, 0.02 and the
corresponding p-value is, say 0.04, it means that _if_ I draw a sample from
the fitted distribution, the probability of seeing a test statistic that is
larger than or equal to 0.02 is less than 0.04 (in other words, unlikely).
It does _not_ say anything about whether the sample was really drawn from
the fitted distribution; in other words, it does _not_ say anything about
whether the fitted distribution is correct or not. It simply says: _if_ the
null hypothesis is true, it is unlikely that you would have achieved a
result that is at least as extreme as the one that you have seen.

The typical interpretation of the p-value is that small p-values mean that
your null hypothesis is most likely not true (it was "disproven" by the
test), while large p-values mean that your null hypothesis could either be
true or false, and the test could not disprove it. A statistical test can
never "confirm" your null hypothesis, but usually it is not the goal anyway
because the null hypothesis usually tends to be something "uninteresting".

The power-law fit is an odd beast, though: here, first you perform a
_fitting_ of the parameters of the power-law distribution to your observed
data, and _then_ perform a test where the null hypothesis is that the fit
is good. In this case, the null hypothesis is _exactly_ what you are
looking for, and a small p-value mean that the test "refuted" the null
hypothesis, hence your fit is not good. Large p-values are good. Small
p-values mean that no matter how hard you try to fit a power-law to your
observed sample, it is most likely not a power-law distributed sample.

In a complete graph, each of N vertices has degree N-1; definitely not a
> power-law. Yet: [...]
>
> $KS.p
> [1] 1
>
> If the explanation of KS.p is correct, this suggests a strong fit to power
> law,
>
No, it does not. Large p-values do not mean anything; it is as if the test
was throwing its hands in the air and say something like "I have no idea
whether your data is a power-law or not".


> However, looking at the other extreme, let's generate a distribution
> expected to follow the power law:
>
> sfp <- sample_fitness_pl(1000, 5, 2.2)
>
1000 vertices is probably too small to observe a "real" power law; your
sample will suffer from finite size effects, and I think that's why the
test says that it is probably not a power-law. Another problem could be the
number of edges; it means that your mean degree will be around 50, which is
not very typical for "real" power-laws. Discrete power-law distributions
like the Yule-Simon or the zeta distribution have means closer to 1; for
instance, for the Yule-Simon distribution, it is (s-1) / s where s is its
shape parameter.

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Performance doubt

[Tamas Nepusz]

Hi,

The difference should be negligible according to my measurements:

>>> from igraph import Graph
>>> from timeit import timeit
>>> g = Graph.GRG(1, 0.002)
>>> vs = g.vs
>>> timeit("g.degree()", setup="from __main__ import g", number=1)
0.8931419849395752
>>> timeit("g.degree(vs)", setup="from __main__ import g, vs", number=1)
0.8965861797332764

T.


On Mon, 19 Aug 2019 at 17:53, Fernando Barraza 
wrote:

> Hello,
>
> I want to know your opinion if should be there a significant performance
> difference between calling the method Graph.degree() and
> Graph.degree(myVertexSeq) when myVertexSeq contain the whole graph. I'm
> calculating on a graph with more than a million of vertexes.
>
> Regards,
>
> Fdo.
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Issues with read.graph in graphml format

[Tamas Nepusz]

Hello,

The "GraphML support is disabled" error message is shown when the
development versions of the libraries required to _parse_ a GraphML file
(libxml2 and libiconv) were not installed on the machine where the igraph
extension for R was compiled. Writing still works in this case because we
don't use these libraries for producing the output, only for reading it.

The bottom line is that you need to remove the igraph extension and then
install it again _after_ installing libxml2-dev and libiconv-dev (these are
the development packages in Ubuntu for these libraries).

T.


On Mon, 12 Aug 2019 at 17:05, Nirupama Benis 
wrote:

> Hello,
>
> I have been using the R package igraph for quite a while and have used
> write.graph to save my graphs as GraphML files for further use in R itself
> or in Cytoscape.
> Now I am using the latest version of R (on RStudio Version 1.2.1335)
>
> R version 3.6.1 (2019-07-05) -- "Action of the Toes"
>
> And the igraph package version
>
> > packageVersion("igraph")[1] ‘1.2.4.1’
>
> On Ubuntu 18.04.2 LTS.
> Now I am not able to read in GraphML files that I wrote using the igraph
> function write.graph.
> The function write.graph works with format as 'graphml'
> > write.graph(graph = netgraph, file = "myNetwork.graphml", format =
> "graphml")
> But when I read the file in with read.graph
> > netgraph <- read.graph(file = "myNetwork.graphml", format =
> "graphml")
>
> Error in read.graph.graphml(file, ...) :
>   At foreign-graphml.c:1361 : GraphML support is disabled, Unimplemented 
> function call
>
>
> The function does work on a virtual machine that has R version 3.6.0 and
> Ubuntu 18.04.2.
> Is there something I am missing?
> I can temporarily work around this by using the package RCy3 to store the
> graphs and download it in graphml format to save the graph. But I would
> prefer to put it in the script. Do you suggest any other format that
> perhaps works better?
>
> Regards,
> Nirupama Benis.
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Local assortativity

[Tamas Nepusz]

There is no such function yet; all the assortativity functions implemented
in the C core of the library return a single number based on the whole
graph.

T.


On Thu, 8 Aug 2019 at 17:37, Fernando Barraza 
wrote:

> Dear colleagues,
>
> Is there any method to calculate the local assortativity in igraph? I mean
> if there is an additional parameter in the assortativity method (or
> assortativity_nominal). Going further, could this parameter be a list of
> vertices?
>
> I'm using python.
>
> Thanks in advance,
>
> Fdo.
>
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Remaining degree estimation

[Tamas Nepusz]

> I was wondering if there is a method to estimate the pdf of the remaining
> degree of a graph. My first idea subtracts 1 to the degree for each vertex
> (in an unaddressed graph) and to use numpy to do the rest. I am using
> python igraph.
>
Sounds like a standard kernel density estimation problem (
https://www.wikiwand.com/en/Kernel_density_estimation); I would probably do
the same as you did (i.e. subtract 1 from each vertex degree and then feed
it into a kernel density estimation algorithm. igraph does not have
anything built-in for this purpose as there are other libraries specialized
for kernel density estimation that do this better.

All the best,
Tamas
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] igraph R: fit_power_law

[Tamas Nepusz]

Dear Sander
.

>
>1. The igraph documentation suggests that the bfgs function is used to
>estimate the power law alpha, but I think the C implementation relies on
>the  Broyden-Fletcher-Goldfarb-Shanno optimization function of the
>lbfgs library instead. Is that correct?
>
> This is the exact implementation of the BFGS optimization that we use in
power law fitting:

https://github.com/ntamas/plfit/blob/master/src/lbfgs.c

As far as I know this is the C port of the limited memory variant of the
Broyden-Fletcher-Goldfarb-Shanno method, originally written in FORTRAN. The
license notes in the source code might give you more clues.


>1. The fit_power_law function relies on the MLE function of the stat4
>package. I am curious why this was deprecated, given the availability of
>plfit and MLE parameters. Is this simply a memory issue?
>
> I don't know; this is purely in the domain of the R interface of igraph;
the C core uses the L-BFGS method and my "plfit" library:

https://github.com/ntamas/plfit

The plfit library is an efficient implementation of the method published by
Clauset, Shalizi and Newman:

Clauset A, Shalizi CR and Newman MEJ: Power-law distributions in empirical
data. SIAM Review 51, 661-703 (2009).


>
>1. How to interpret the p-value of the Kolmogorov-Smirnov test?
>
> See the paper cited above for more details.


>
>1. The igraph help file states: "Small p-values (less than 0.05)
>indicate that the test rejected the hypothesis that the original data could
>have been drawn from the fitted power-law distribution" . The C
>implementation of the KS test in igraph uses the Hurwitz Zeta function.
>Shouldn't this mean that *high *p-values indicate a good model fit, as
>suggested by Clauset et al (2009:678)?
>
> Well, tests based on p-values are not really about whether a model is a
"good fit" or a "bad fit"; a low p-value _roughly_ says that "it is very
unlikely that the data could have been generated from the hypothesized
distribution" (in our case, a power-law). A high p-value _roughly_ means
that "the data may have come from the hypothesized distribution"; however,
there could be alternative distributions that can describe the data just as
well.

So, in a nutshell:

low p-value --> null hypothesis (power-law) rejected --> data is likely not
a power-law
high p-value --> null hypothese (power-law) _not_ rejected --> data could
come from a power-law, or maybe from something else, we don't know, we just
could not _exclude_ the power-law

All the best,
T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] igraph C library installation failure macOS

[Tamas Nepusz]

Hi,

Try replacing "abs" with "fabs" in examples/simple/spmatrix.c and
examples/simple/igraph_sparsemat4.c -- there are compiler warnings related
to these files in testsuite.log and I suspect that's the reason why the
tests are failing.

All the best,
T.


On Wed, 19 Jun 2019 at 12:18, He, Peng  wrote:

> Dear igraph C library users,
>
> I failed to install the igraph C library on my Mac, and still have no
> clues to identify and solve the problem.
> I followed the instruction (the 'regular Unix way
> ’)
> for all the installations.
> I can install the library on Ubuntu system, but never succeeded on Mac.
> I’d like to ask you for hints on what’s the problem and how to handle it.
> I’d also like to attach the test results (testsuite.log) to show all the
> details.
> Thank you very much in advance!
>
> Best wishes,
> Peng
>
>  brief results
> ## - ##
> ## Test results. ##
> ## - ##
>
> ERROR: All 234 tests were run,
> 2 failed unexpectedly.
> ## -- ##
> ## testsuite.log was created. ##
> ## -- ##
>
> Please send `tests/testsuite.log' and all information you think might help:
>
>To: 
>Subject: [igraph 0.7.1] testsuite: 25 32 failed
>
> You may investigate any problem if you feel able to do so, in which
> case the test suite provides a good starting point.  Its output may
> be found below `tests/testsuite.dir'.
>
> make[2]: *** [check-local] Error 1
> make[1]: *** [check-am] Error 2
> make: *** [check-recursive] Error 1
> 
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Saving .tif graph

[Tamas Nepusz]

As the error message says, saving into TIF is not supported. Save the plot
into PNG and then convert the output into TIF. (PNG files are significantly
smaller than TIFs anyway).

T.


On Thu, 13 Jun 2019 at 13:06, Roaa Soloh  wrote:

> Kindly I'm getting this error when trying to save the output graph into
> .tif format
> 
> Traceback (most recent call last):
>   File "/home/roaa/PycharmProjects/PhD/Coding.py", line 26, in 
> plot(g, "/home/roaa/Desktop/PhD/Output/dinosaur.tif")
>   File
> "/home/roaa/anaconda3/envs/PhD/lib/python3.7/site-packages/igraph/drawing/__init__.py",
> line 449, in plot
> result = Plot(target, bbox, background=kwds.get("background", "white"))
>   File
> "/home/roaa/anaconda3/envs/PhD/lib/python3.7/site-packages/igraph/drawing/__init__.py",
> line 160, in __init__
> raise ValueError("image format not handled by Cairo: %s" % ext)
> ValueError: image format not handled by Cairo: .tif```
> -
>
> Best Regards,
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] dominator_tree in the Python version

[Tamas Nepusz]

Hi Geoff,

Sorry, this function is not implemented in the Python interface of igraph
yet.

All the best,
T.


On Sun, 26 May 2019 at 09:41, Geoff Langdale 
wrote:

> Hi all,
>
> Sorry if this is a dumb question but I can find no documentation for
> dominator_tree operations in the Python version (python3 if that's
> significant), nor any evidence that the functions are there but
> undocumented. Using version 0.7.1 on Ubuntu.
>
> Regards,
> Geoff.
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Read in dataframe as graph, simplifying network while keep edge weights

[Tamas Nepusz]

Hello,

simplify() has an argument named edge.attr.comb=... with which you can
specify how the edge attributes should be combined when replacing multiple
edges with a single one. Type "?attribute.combination" in R for more
details.

T.


On Tue, 7 May 2019 at 13:01, Tao ZHAO  wrote:

> Hi,
>
> I have a dataframe with 8 columns, the first two columns creates the
> edgelist (source and target, undirected). The other columns are edge
> descriptions, which are important information for my following analysis.
>
> My next step is to simplify the network and perform clustering.  However
> after simplify(network), I got a graph with only edgelist (2 columns).
>
> I wonder is there an easier way within the package to attach the pairwise
> edge information to the simplified network.
> Or I have to write a script myself for the mapping.  It would be very
> helpful for my following analysis.
>
> Thank you very much!
>
>
> *Tao Zhao* - Postdoctoral fellow
> Bioinformatics
>
> *VIB-UGent Center for Plant Systems Biology*
> Ghent University
> Technologiepark-Zwijnaarde 71 - 9052 Ghent - Belgium
> Tel. +32(0)9 331 38 23
> www.psb.ugent.be
>
> *Genome editing, cutting-edge technology for a sustainable agriculture*
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Vertices, Edges, Attributes & Values

[Tamas Nepusz]

> How can we iterate through vertices, vertex attributes and attribute
>>> values, and same for the edges?
>>>
>> graph.vs["attr"] gives you the values of the "attr" vertex attribute for
all the vertices in a Python list. You can then iterate over it like normal.
graph.es["attr"] is the same for edge attributes
g.vertex_attributes() gives you the list of all vertex attributes.
g.edge_attributes() gives you the list of all edge attributes.

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Vertices, Edges, Attributes & Values

[Tamas Nepusz]

Hello,

Is it C, Python or R?

T.


On Fri, 29 Mar 2019 at 01:47, Gokce Dilek  wrote:

> Hello,
>
> How can we iterate through vertices, vertex attributes and attribute
> values, and same for the edges?
>
> Thank you!
> Gokce Dilek
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Maximum_independent_vertex_sets() function question

[Tamas Nepusz]

Hi,

Unfortunately it's not possible yet and it would need significant
modifications in the underlying C layer. Right now the core igraph library
has a function that takes a graph and puts all the independent sets in a
vector; this is then translated back to Python lists. The C core would
require a function instead that takes a graph and a callback function
instead, and it would then call the callback function for each found
independent vertex set.

All the best,
Tamás


On Mon, 25 Mar 2019 at 22:51, Jesse Alloy  wrote:

> Hi,
>
> Is there an easy way to find one instance of an independent set of a
> certain size in a graph (using the Python implementation)?
>
> largest_independent_vertex_sets() gives me all of them, but I know what
> the largest size is in my problem, I just need to find one of them. If I
> find them all, then the algorithm takes too long. Breaking after the first
> instance might save me enough time to make this implementation usable.
>
> Thank you for the help.
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Apparent memory corruption in R

[Tamas Nepusz]

Hi Luka,

I have managed to reproduce the problem on my machine with R version
3.5.2 and igraph installed with install.packages('igraph"). In my
case, the error message looked slightly different, though:

Error in head.default("2623", c(1L, 1L)) : length(n) == 1L is not TRUE
Calls: lapply ... contract.vertices -> head -> head.default -> stopifnot
R(33662,0x1198925c0) malloc: *** error for object 0x7fb6eddc8720:
pointer being freed was not allocated
R(33662,0x1198925c0) malloc: *** set a breakpoint in malloc_error_break to debug

I am not the developer of the R interface so I am not really familiar
with the internals -- plus, a large chunk of the glue code between R
and the C core of igraph is auto-generated so some things may go wrong
there. I suspect a double-free issue that happens when
contract.vertices() (from the C layer) calls back into R code to
perform the merging of some vertex or edge attributes during
contractions.

Judging from the call to "head" I also suspect that the crash is
somehow related to the usage of "first" in vertex.attr.comb=... as
"first" requires a call to head() internally. My theory is that the
call to head() in the vertex attribute combination phase throws an
error (this is what we see above), which accidentally triggers igraph
to double-free something (and that things would be solved if I managed
to fix that error). I tried to confirm this by removing "first" from
vertex.attr.comb=... to see if that would resolve the problem, but
unfortunately the code stops with the following error message:

Error in findInterval(t$pos, vec = compress$pos) :
  'vec' must be sorted non-decreasingly and not contain NAs

As I don't know what findInterval() is supposed to do, I'm a bit at a
loss here. Can you help me with this?

All the best,


T.

On Sat, 19 Jan 2019 at 01:23, Luka Culibrk  wrote:
>
> Hi Tamas,
>
> Thank you for your reply. I've packaged the data required to replicate the 
> crash and a script which replicates the crash on my machine. It can be 
> downloaded from 
> https://drive.google.com/file/d/1csjRW-ftIYmJdI_LdadUCHOk9-Tz1btp/view?usp=sharing
>  .
> This can be run with:
>
> tar -xvf igraph_debug.tar.gz; cd igraph_debug; Rscript debug_igraph_crash.R
>
> Required packages are dplyr and igraph.
>
> Thanks,
> Luka
>
> On Thu, Jan 17, 2019 at 1:45 AM Tamas Nepusz  wrote:
>>
>> Dear Luka,
>>
>> Unfortunately we can't really help without seeing a minimal,
>> reproducible example code that causes the crash. Here are some
>> instructions on providing such an example that we can start debugging
>> on our side:
>>
>> https://stackoverflow.com/a/5963610/156771
>>
>> All the best,
>> Tamás
>>
>> On Tue, 15 Jan 2019 at 21:57, Luka Culibrk  wrote:
>> >
>> > Dearest igraph users,
>> >
>> > I'm running into some issues with igraph in R.
>> >
>> > I've posted this same issue to Stack Overflow 
>> > (https://stackoverflow.com/posts/54155455) and was recommeded to come here.
>> >
>> > Context: I have a path graph that I wish to contract iteratively; ie. at 
>> > each iteration, take a set of adjacent vertices in the path graph that fit 
>> > some critera, contract them together, and repeat iteratively until no 
>> > remaining vertices fit the criteria. Each path graph represents a 
>> > biological chromosome (this is biological data that I'm working with). The 
>> > path graph to contract is roughly 5,000 vertices long, and the program 
>> > iterates roughly 20 times at most per graph. Each sample case has 22 path 
>> > graphs to contract. Prototyping via Rstudio worked just fine (and still 
>> > works fine), however when running this as an Rscript it's throwing some 
>> > errors, and in a different iteration each time (ie. this seems to be 
>> > happening at random)
>> >
>> > The first time I encountered the issue, it would throw a double free 
>> > error. Again, this would occur unpredictably. I tried running on a 
>> > different machine, however this threw a different memory-related error 
>> > which I don't remember. I made a new miniconda virtual environment and 
>> > reinstalled all of the requisite R packages, including igraph and tried 
>> > again. Now I'm getting another error, here:
>> > ```
>> > Error in head.default("2616", 1L) : length(n) == 1L is not TRUE
>> > Calls: write.table ... contract.vertices -> head -> head.default -> 
>> > stopifnot
>> > In addition: There were 28 warnings (use warnings() to see them)
>> &

Re: [igraph] memory leaking during the plotting

[Tamas Nepusz]

Hi,

Please post the code that you use for plotting. It could be the case
that you are trying to create a plot with a very large resolution, or
you might have 10 million edges for 200 nodes -- it's hard to tell
without seeing the code.

T.

On Tue, 29 Jan 2019 at 11:08, Вадим Семенов  wrote:
>
> Hi all,
>
> could you please help me with clearing memory of my Virtual Machine after 
> plotting of a graph with 200 nodes. Actually, it takes more than 2Gb during 
> the plotting and 1.5Gb RAM left after plotting. Could you please say how I 
> can deal with it?
> https://i.imgur.com/iOQJ0DO.gifv -GIF which demonstrates the amount of memory 
> after plotting
> Thanks in advance for any help.
>
> --
> With regards,
> Semenov Vadim.
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help

___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Find six degrees of separation in Actor-Actor Network

[Tamas Nepusz]

> 3) This was a Movie-Actor bipartite network. When I project into Actor-Actor 
> network, edges are Movie names. The edges in Actor-Actor network such as 
> Actor01--Actor02 but I need to get it like that Actor01-MoiveA-Actor02 or 
> Actor01-MovieA/MovieB-Actor02.

I am afraid that this is currently not supported in igraph. You need
to use the original network and the all_shortest_paths() function to
find the movies that connect two actors.

T.

___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Chinese Postman Problem with igraph?

[Tamas Nepusz]

Hi,

Unfortunately we cannot include plain R code in the C core of the
igraph library because those functions would not be usable from the
Python and Mathematica interfaces. Ideally, we would need similar
functions implemented in pure C. Using subgraph isomorphism is
probably overkill for the _efficient_ detection of cycles, although it
could work for smaller graphs.

Also, in most practical cases there are far too many cycles in a
network to enumerate all of them in an array. A better approach is to
find and return a cycle basis of the network; with m nodes, n edges
and c connected components, there are only m - n + c cycles in a cycle
basis, and every cycle of the graph can be composed from the cycles in
the cycle basis using symmetric difference operations only. So, if I
were to implement something like this in the C core, I would probably
start with a cycle basis construction.

All the best,
Tamás

On Sat, 19 Jan 2019 at 02:01, lookman sanni  wrote:
>
> Hi Tamas,
>
> In line with this, here is a proposal for detecting unique set of vertices in 
> a graph cycle for your review. It only detects cycles with 4 or more vertices 
> and removes duplicates. igraph already incorporate functions to deal with 
> triangles. It's a first draft and I believe it can potentially be optimized.
>
> library(igraph)
>
> #-
> #Flags all edges within a graph, part of a cycle  
> |
> # Approach: subgraph_isomorphisms(make_ring())
> |
> #-
> find_cycles <- function(g) {
>   E(g)$cycle = 0
>   # Simplify & decompose graph in disconnected components
>   simplg = simplify(g, remove.multiple=TRUE, remove.loops = TRUE)
>   list_cycles <- list()
>   componentSet <- decompose(simplg, min.vertices = 4)
>   print(length(componentSet))
>   l = 1
>   #list cycles through subgraph isomorphism to ring(>4) mapping
>   for (i in 1:length(componentSet))
>   {
> print(sprintf("component: %i of size %i", i, 
> length(V(componentSet[[i]]
> for(j in 4:length(V(componentSet[[i]])))
> {
>   print(sprintf("Trying to match against ring of size: %i", j))
>   a = subgraph_isomorphisms(make_ring(j), componentSet[[i]], 
> method=c("vf2"))
>   print("Isomorphism count: ")
>   print(length(a))
>   if(length(a) != 0)
> for(k in 1:length(a))
> {
>   list_cycles[[l]] = a[[k]]$name
>   l = l+1
>   #print(sprintf("cycle item: %i", length(list_cycles)))
> }
> }
>   }
>   #Dedup Cycles
>   list_cycles_dedup <- list()
>   list_cycles_dedup[[1]] = sort(list_cycles[[1]])
>   z = 2
>   for(x in 2:length(list_cycles))
>   {
> a = sort(list_cycles[[x]])
> found_flag = FALSE
> print(sprintf("x = %i; checking...", x))
> print(a)
> for(y in 1:length(list_cycles_dedup))
> {
>   print("against")
>   print(list_cycles_dedup[[y]])
>   if(all(a == list_cycles_dedup[[y]]))
>   {
> found_flag = TRUE
> break
>   }
> }
> if(found_flag==FALSE)
> {
>   print("not found")
>   list_cycles_dedup[[z]] = a
>   z = z + 1
> }
>   }
>
>   return(list_cycles_dedup)
>   #return(list_cycles)
> }
>
> And to test it:
>  a = make_ring(5)
>  b = make_star(10, mode="undirected", center="5")
>  c = union(a,b,byname="auto")
>  V(c)$name = c("A","B","C","D","E","F","G","H","I","J")
>  d = find_cycles(c)
>
> Only constraint so far is to define vertices names.
>
> Please let me know how it goes.
>
> Lookman
>
>
> On Tue, Jan 8, 2019 at 6:25 PM Tamas Nepusz  wrote:
>>
>> > Out of curiosity... There is an extensive set of functions in igraph 
>> > dealing with paths but not with circuits. Why is that?
>> Well, igraph's development direction was always partly determined by
>> the personal needs of Gábor Csárdi and me when we were working as
>> researchers in network science. We did not really have many use-cases
>> for circuits, so these parts of graph theory were mostly left
>> untouched. Feel free to contribute implementations if you can dedicate
>> the time and effort to do it -- I'll be happy to review code addition
>> proposals.
>>
>> All the best,
>> Tamás
>>
>> ___
>> igraph-help mailing list
>> igraph-help@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
>
> --
>
> Lookman SANNI
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help

___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Find six degrees of separation in Actor-Actor Network

[Tamas Nepusz]

> - In igraph weight is considered as a cost or close relation
It depends on the algorithm; for shortest path calculations, weights
represents distances (i.e. the larger the weight, the longer the edge
is).

> Even though there are many edges between Actor01 and Actor02 , the length of 
> path will be one! Is this right?
You could set it to 1, or you could set it to 1/K if K was the
original weight, or you can use any other transformation that fits
your purposes. It is entirely up to you.

> - When I calculate the total shortest path between all nodes, there are three 
> nodes have same value. In this case should I look for eigenvector centrality 
> to find right node that will be considered the center node or starting point.
Again, it's up to you which other centrality measures you use to
augment the shortest path analysis.

> -  When I projected the bipartite network into Actor-Actor network, I'am 
> losing the the names of edges that are important for me. How can I get assign 
> edge name into Actor-Actor network.

What are the names of the edges in your case? The input data frame
contains node names only.

T.

___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Apparent memory corruption in R

[Tamas Nepusz]

Dear Luka,

Unfortunately we can't really help without seeing a minimal,
reproducible example code that causes the crash. Here are some
instructions on providing such an example that we can start debugging
on our side:

https://stackoverflow.com/a/5963610/156771

All the best,
Tamás

On Tue, 15 Jan 2019 at 21:57, Luka Culibrk  wrote:
>
> Dearest igraph users,
>
> I'm running into some issues with igraph in R.
>
> I've posted this same issue to Stack Overflow 
> (https://stackoverflow.com/posts/54155455) and was recommeded to come here.
>
> Context: I have a path graph that I wish to contract iteratively; ie. at each 
> iteration, take a set of adjacent vertices in the path graph that fit some 
> critera, contract them together, and repeat iteratively until no remaining 
> vertices fit the criteria. Each path graph represents a biological chromosome 
> (this is biological data that I'm working with). The path graph to contract 
> is roughly 5,000 vertices long, and the program iterates roughly 20 times at 
> most per graph. Each sample case has 22 path graphs to contract. Prototyping 
> via Rstudio worked just fine (and still works fine), however when running 
> this as an Rscript it's throwing some errors, and in a different iteration 
> each time (ie. this seems to be happening at random)
>
> The first time I encountered the issue, it would throw a double free error. 
> Again, this would occur unpredictably. I tried running on a different 
> machine, however this threw a different memory-related error which I don't 
> remember. I made a new miniconda virtual environment and reinstalled all of 
> the requisite R packages, including igraph and tried again. Now I'm getting 
> another error, here:
> ```
> Error in head.default("2616", 1L) : length(n) == 1L is not TRUE
> Calls: write.table ... contract.vertices -> head -> head.default -> stopifnot
> In addition: There were 28 warnings (use warnings() to see them)
> Error in contract.vertices(toy, mapping = vertices, vertex.attr.comb = 
> list(new_residual = "sum",  :
>   VECTOR_ELT() can only be applied to a 'list', not a 'double'
> Calls: write.table ... compressdata -> %>% -> eval -> eval -> 
> contract.vertices -> .Call
> Execution halted
> ```
> Note that in "head.default("2616", 1L)", the number (here "2616") is always 
> different every time I run the code. I have no idea what is actually calling 
> head.default() since I don't see it anywhere in the contract.vertices() 
> source code that I can get using edit(getAnywhere(contract.vertices())). I've 
> also scoured the C source code on github which hasn't gotten me anywhere.
>
> I'm running this on CentOS 7 machines with 1tb of memory each.
>
> Here is the double free error with a few lines of the memory dump, note that 
> the ```Error: length(n) == 1L is not TRUE``` is being thrown inside an igraph 
> function (```contract_vertices()```) rather than my script. I see this error 
> when I run it from a different anaconda environment that I have for another 
> project.
>
> ```
> Error: length(n) == 1L is not TRUE
> In addition: There were 29 warnings (use warnings() to see them)
> *** glibc detected *** 
> /home/lculibrk/miniconda3/envs/lukonda/lib/R/bin/exec/R: double free or 
> corruption (out): 0x7b3ea4a0 ***
> === Backtrace: =
> /lib64/libc.so.6[0x3e9f275f4e]
> /lib64/libc.so.6[0x3e9f278cf0]
> /home/lculibrk/R/x86_64-pc-linux-gnu-library/3.4/igraph/libs/igraph.so(igraph_vector_destroy+0x27)[0x7f8ccac45337]
> /home/lculibrk/R/x86_64-pc-linux-gnu-library/3.4/igraph/libs/igraph.so(IGRAPH_FINALLY_FREE+0x63)[0x7f8ccab5b24d]
> /home/lculibrk/R/x86_64-pc-linux-gnu-library/3.4/igraph/libs/igraph.so(R_igraph_finalizer+0xc1)[0x7f8ccac90976]
> ```
>
> The consistent thing about the double free error above is it seems to occur 
> in the same memory address each time; 0x7b3ea4a0. Still, it occurs in 
> a different iteration each time, and on different path graphs each time.
>
> I'm quite lost as to where exactly I can start the process of trying to debug 
> this issue, as I'm sure it must be on my end somewhere.
>
> Thanks for any help you might be able to provide. Let me know if I need to 
> clarify anything or provide more information.
>
> Best regards,
> Luka Culibrk
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help

___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Chinese Postman Problem with igraph?

[Tamas Nepusz]

> Out of curiosity... There is an extensive set of functions in igraph dealing 
> with paths but not with circuits. Why is that?
Well, igraph's development direction was always partly determined by
the personal needs of Gábor Csárdi and me when we were working as
researchers in network science. We did not really have many use-cases
for circuits, so these parts of graph theory were mostly left
untouched. Feel free to contribute implementations if you can dedicate
the time and effort to do it -- I'll be happy to review code addition
proposals.

All the best,
Tamás

___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Chinese Postman Problem with igraph?

[Tamas Nepusz]

> 6: Modify the graph by adding all the edges that  have been found in step 5.
> SD: igraph_add_vertices()
igraph_add_edges(), most likely

> 8: Print Euler Circuit of the modified graph. This Euler Circuit is Chinese 
> Postman Tour.
> SD: I cannot find any functions that, given a starting vertex, calculate a 
> circuit, a tour, or a closed path. Recommendations?
There is no such function, but if there is an Euler circuit in the
graph, all you need to do is to start from anywhere, and keep on
following any unvisited edge going outwards from the current vertex,
marking the edge as "visited" while doing so. If you get stuck
somewhere, then you have found the Euler circuit of the connected
component containing the start vertex. (If there are multiple
connected components, proceed with the next one).

T.

___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] persisting graph and cross-process igraph

[Tamas Nepusz]

Hi,

GraphML seems to be your best bet in that case -- it can preserve
graph, vertex and edge attributes as long as they can be represented
as standard GraphML types. Integers, floats, booleans, strings should
be okay. Anything more complicated (such as a complex Python object)
needs special treatment.

T.

On Sat, 15 Dec 2018 at 00:58, Eric Jonas  wrote:
>
> Is there a recommended serial format for saving graphs to disk or passing 
> them over the wire, especially if I have python-igraph on one side and the c 
> library on the other? I'm especially interested in preserving a lot of the 
> node and edge label information.
>
> ...Eric
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help

___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Passability of nodes

[Tamas Nepusz]

You can use Graph.TupleList() to construct a graph from named vertex tuples.

All the best,
T.

On Mon, 26 Nov 2018 at 20:06, Johannes Radinger
 wrote:
>>
>> How about replacing each barrier node V with two nodes VA and VB?
>> Assuming that edges point downstream, you can then rewire the head of
>> all incoming edges of V to VA and the tails of all outgoing edges of V
>> to VB, then place an edge from VA to VB if V is passable in the
>> downstream direction, or from VB to VA if it is passable in the
>> upstream direction.
>>
> Thanks Tamas, that sounds like a great idea. I'll test this ASAP. However, I 
> am just struggling with creating a graph from a list of named vertex-pairs. 
> So far I have always been using plain integer values starting with 0 which 
> represent my vertex IDs...but now since I want to replace each barrier node V 
> with two nodes VA and VB, I have created a list of named node-pairs like 
> edge_list = [["v1","v2"],"v2","v3"],["v3","v4A"],["v4B","v5"],["v4A","v4B“]]. 
> It seems that the igraph R libarry has such a function 
> (https://igraph.org/r/doc/graph_from_edgelist.html) that accepts a list of 
> names. However, is there a corresponding function in the python igraph 
> library?
>
> cheers,
> Johannes
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help

___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Passability of nodes

[Tamas Nepusz]

> Some of the nodes, i.e. barriers have varying passability. This means a 
> barrier can be e.g. impassable in upstream direction but passable in 
> downstream direction. Now, I'd like to calculated shortest distances/path 
> from one set of nodes to another set of nodes along the directed river 
> network, however, by also considering the passability of the barrier-nodes, 
> i.e. to consider that some barriers "break" the graph and are impassible but 
> only when approached from a specific direction. How could this be achieve 
> with the igraph library?

How about replacing each barrier node V with two nodes VA and VB?
Assuming that edges point downstream, you can then rewire the head of
all incoming edges of V to VA and the tails of all outgoing edges of V
to VB, then place an edge from VA to VB if V is passable in the
downstream direction, or from VB to VA if it is passable in the
upstream direction.

T.

___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Retrieving edges weight

[Tamas Nepusz]

> but now I cannot retrieve edges weight from the tree. More generally, how do 
> I get an edge attribute from a given graph ? I was expecting Graph interface 
> to have an edges attribute.
> I only have a list of edges (given by a get_edgelist() method above and this 
> returns tuple, not an edge object).
Internally, the edges are identified by integers from 0 to M-1, where
M is the number of edges. If you only have the two endpoints of an
edge, you need to use get_eid() to get the numeric ID, then you can
use that to index into g.es["weight"]:

>>> edge_indices = [g.get_eid(*pair) for pair in tree.get_edgelist()]
>>> print(g.es[edge_indices]["weight"])
[1, 1, 2, 3, 2]

T.

___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] igraph-help Digest, Vol 130, Issue 8

[Tamas Nepusz]

Hi,

In that case, please send me a short, self-contained example (code and the
corresponding graph) that reproduces the problem so I can check it on my
side. (Please send it to my private email address; the mailing list will
not allow attachments of arbitrary size).

All the best,

T.

On Sun, Jun 11, 2017 at 9:02 PM, 闵超  wrote:

> I did set the value of mode to "OUT". That's why I feel the result is so
> strange.
> >
> > Message: 2
> > Date: Sat, 10 Jun 2017 21:50:25 +0200
> > From: Tamas Nepusz 
> > To: Help for igraph users 
> > Subject: Re: [igraph] Suspicious results produced by the function
> >neighborhood_size
> > Message-ID:
> >
> > Content-Type: text/plain; charset="utf-8"
> >
> > Hi,
> >
> > Did you set the value of the "mode" argument to "OUT"? Note that the
> > default value is "ALL", meaning that directed edges will be followed in
> > both directions.
> >
> > T.
> >
> >> On Sat, Jun 10, 2017 at 9:40 PM, ??  wrote:
> >>
> >> Hi all!
> >>
> >> I came across some suspicious results by the igraph function
> >> neighborhood_size:
> >>
> >> neighborhood_size
> >> <http://igraph.org/python/doc/igraph.GraphBase-class.html#
> neighborhood_size>
> >> (vertices=None, order=1, mode=ALL)
> >>
> >> For each vertex specified by vertices, this function should return the
> >> number of vertices reachable from that vertex in at most *order *steps.
> >> My network is a directed citation network containing 531, 480 vertices
> >> (each is a paper) and their citation relationships (about 6 million
> edges).
> >> I used neighborhood_size to calculate the number of vertices reachable
> from
> >> a vertex in at most 50 steps and it returned a result of 506, 255. I am
> >> quite sure there couldn't be so many vertices reachable from that
> vertex.
> >> So I used Networkx to calculate the same thing and it returned a result
> >> of 17, 564, which seems to be more reasonable.
> >>
> >> All the output about my current research is based on igraph. But I found
> >> so many suspicious results of this kind. Can anyone help me find out
> what
> >> the problem is?
> >>
> >> Thanks!
> >> Chao
> >> --
> >> Chao MIN, ??
> >> Visiting PhD student, School of Informatics and Computing, Indiana
> >> University Bloomington
> >> PhD candidate, School of Information Management, Nanjing University
> >>
> >> ___
> >> igraph-help mailing list
> >> igraph-help@nongnu.org
> >> https://lists.nongnu.org/mailman/listinfo/igraph-help
> >>
> >>
> > -- next part --
> > An HTML attachment was scrubbed...
> > URL: <http://lists.nongnu.org/archive/html/igraph-help/
> attachments/20170610/d8438935/attachment.html>
> >
> > --
> >
> > Subject: Digest Footer
> >
> > ___
> > igraph-help mailing list
> > igraph-help@nongnu.org
> > https://lists.nongnu.org/mailman/listinfo/igraph-help
> >
> >
> > --
> >
> > End of igraph-help Digest, Vol 130, Issue 8
> > ***
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Suspicious results produced by the function neighborhood_size

[Tamas Nepusz]

Hi,

Did you set the value of the "mode" argument to "OUT"? Note that the
default value is "ALL", meaning that directed edges will be followed in
both directions.

T.

On Sat, Jun 10, 2017 at 9:40 PM, 闵超  wrote:

> Hi all!
>
> I came across some suspicious results by the igraph function
> neighborhood_size:
>
> neighborhood_size
> 
> (vertices=None, order=1, mode=ALL)
>
> For each vertex specified by vertices, this function should return the
> number of vertices reachable from that vertex in at most *order *steps.
> My network is a directed citation network containing 531, 480 vertices
> (each is a paper) and their citation relationships (about 6 million edges).
> I used neighborhood_size to calculate the number of vertices reachable from
> a vertex in at most 50 steps and it returned a result of 506, 255. I am
> quite sure there couldn't be so many vertices reachable from that vertex.
> So I used Networkx to calculate the same thing and it returned a result
> of 17, 564, which seems to be more reasonable.
>
> All the output about my current research is based on igraph. But I found
> so many suspicious results of this kind. Can anyone help me find out what
> the problem is?
>
> Thanks!
> Chao
> --
> Chao MIN, 闵超
> Visiting PhD student, School of Informatics and Computing, Indiana
> University Bloomington
> PhD candidate, School of Information Management, Nanjing University
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Error in igraph trying to plot a co-ocurrence network

[Tamas Nepusz]

Hi,

The plot_network() function is not part of igraph so we cannot help here.
Please contact the authors of the package that implements the
plot_network() function for help -- I suspect that the function is part of
the phyloseq package.

T.

On Fri, Jun 9, 2017 at 1:29 PM, Miguel Angel Fernández Martínez <
mafernan...@cab.inta-csic.es> wrote:

> Hi there!
>
> I am very very new at igraph package and just a little more than a rookie
> in R, so maybe my questions are a bit trivial. I apologize for that.
>
> I am triying to run a script that combines the package 'Spiec-Easi' with
> 'igraph' to perform a netwowork analysis and its plot.
>
> I have encountered some problems with my data format, but most of them has
> been overcome. However, I am now facing one that I cannot solve by myself.
> I copy my whole script and I attach the data in .csv file format just in
> case you want to have a look at it:
>
> *library(devtools)*
> *library(SpiecEasi)*
> *library(igraph)*
> *library(phyloseq) *
>
> *tabla <- read.csv("tabla_prueba.txt")*
>
> *rownames(tabla) <- tabla[,1]*
> *tabla <- tabla[,-1] *
> *tabla <- t(tabla)*
>
> *se.tabla <- spiec.easi(tabla, method='mb', lambda.min.ratio=1e-2,
> nlambda=20, icov.select.params=list(rep.num=20))*
>
> *se.tabla <- unlist(se.tabla)*
>
> *ig.tabla <- adj2igraph(se.tabla$refit)*
>
> *plot_network(ig.tabla, tabla)*
>
> Everything seems to work properly until the very last command, when I get
> the following:
>
> *Error in `$<-.data.frame`(`*tmp*`, "id", value = c(1L, 0L)) :
>   replacement has 2 rows, data has 0*
>
>  Although it seems to be a very common issue, I have not found any viable
> solution on Internet.
>
> Can anyone help with this problem?
>
> Thanks a lot!
> --
> *Miguel Ángel Fernández Martínez*
> PostDoctoral Researcher
> Dept. Evolución Molecular, Despacho 10
> Tlf.: 91 520 64 33 - Ext. 5415
> Centro de Astrobiología (CAB), INTA-CSIC
> Madrid, Spain
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Permeability

[Tamas Nepusz]

I'm afraid that there isn't a ready-made implementation for this measure in
R yet. I have written a command-line tool for controllability analysis a
while ago (see https://ntamas.github.io/netctrl/ ) -- I think this could
potentially be invoked from R and then its results could be used in
implementing the permeability measure described in the paper.

T.

On Thu, Jun 8, 2017 at 10:13 PM, Buddenhagen,Christopher <
cbuddenha...@ufl.edu> wrote:

> Does anyone know if there is an R function to do this permeability measure
> or one similar to it?
>
> Lo Iudice, Francesco, Franco Garofalo, and Francesco Sorrentino.
> "Structural permeability of complex networks to control signals." *Nature
> Communications* 6 (2015): 8349.
>
> https://www.nature.com/articles/ncomms9349.pdf
>
> Hopefully,
>
> --
>
> Chris Buddenhagen
>
> Post-doctoral Associate
>
> Plant Pathology Department
>
> Institute for Sustainable Food Systems
>
> University of Florida
>
> Garrett Lab
>
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] How to avoid indexing issues with "which" fuction

[Tamas Nepusz]

>
> By the way, I probably exposed the algorithm in a wrong way (I don't speak
> english very well).
> A given percentage of the whole vertices, are selected at the beginning of
> the algorithm to be "IMMUNE", and they will be immune all the time, so I
> expect to have the same percentage of nodes to be immune at the end of the
> algorithm, but some of these nodes passed from "immune" to "spreader"
> during the process.
>
I understand that, but the best that you can do at this stage is to print
the state of each vertex and the set of relevant variables after each
iteration of the loop, and then stop immediately when you find that one of
your vertices went into the wrong state. Then you can look at the variables
right before the incorrect state change and figure out what goes wrong
where. This is what I would do anyway if I were you.

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Modularity Methods in iGraph (python)

[Tamas Nepusz]

Hi,

I am finding ways of divide my network into modules and I saw that the
> package in python comes with several alternatives. I wanted to implement
> the Modularity (Q) as defined by Newman on 2006
>
"Modularity" is only a measure that tries to quantify how "good" a
partition is; Newman's paper defines one possible method to maximize
modularity (heuristically), but it is only one of many possible methods,
some of which work better in certain types of networks and perform worse on
others. That's why igraph implements multiple possible heuristics for
finding modules in a network.


> It seems that the same formula shown on PNAS was used in the
> “community_leading_eigenvector” method, that is based on
> https://arxiv.org/pdf/physics/0605087.pdf.
>  Is this correct?
>
Yes, I believe this is the same method.


> Also, for large sparse matrices, would you rather recommend this method or
> the “community_fastgreedy” optimization?
>
Well, I don't recommend any particular method because all these methods
have their strengths and weaknesses, and there are entire papers dedicated
to the meta-analysis of all the methods that have been proposed in the
literature for modularity maximization (see, e.g.,
https://arxiv.org/abs/0906.0612, which is 103 pages on its own).
Personally, I usually try "community_multilevel" first, but that's just a
matter of taste. I also like "community_infomap" because it has a
scientifically solid theoretical background. The advantage of
"community_infomap" is that it does not try to maximize modularity itself
but a different measure; the reason why it is an advantage is because you
don't fall into the trap of circular reasoning (which you would do by using
a method to find a clustering that has a high modularity, and then claiming
that your findings are relevant _because_ the clustering has a high
modularity).

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] degree centrality in 2-mode network

[Tamas Nepusz]

>
> The suggested code works out and I also checked the named reference for
> further information, but I couldn't find anything about the ratio of
> bipartite network density. It either doesn't seem to be the 0-1 ratio of
> one-mode networks or I did something wrong, because I get results about
> 1.0 for the 2-mode-networks?
>
You are probably doing something wrong because the measure should be
between 0 and 1. It is actually simply the ratio of the total number of
edges and the total number of _possible_ edges between the "top" and the
"bottom" vertices. If you get a result close to 1.0, it means that almost
all of the possible edges between the top and the bottom vertices are
present -- assuming that there are no edges between top-top or
bottom-bottom, which should be the case anyway if it is a bipartite network.

One possible catch is if your network is directed; in that case, you should
multiply the denominator of the fraction (i.e. the number of possible
edges) by 2.

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Common neighbors

[Tamas Nepusz]

>
> Is there an igraph C function to compute the common neighbors of two
> vertices v1, v2?
>
No, there isn't. Sorting the neighbor vectors in O(d log(d)) and comparing
the sorted lists in O(d) is the way to go if you are using the library from
C. Python, R and Mathematica all have built-in set functions that make this
a whole lot easier.

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] How to avoid indexing issues with "which" fuction

[Tamas Nepusz]

>
> How can I solve this problem with the algorithm, do you have any idea or
> advice?
>
Try printing the key variables of your algorithm once for every iteration
of your main loop to check where it is not doing what it should do. This is
a pretty standard debugging technique; I guess I would do the same if I had
time to track this down on behalf of you ;)

By the way, using unique() on the set of adjacent vertices in your code
might be conceptually wrong. By doing so, basically you are saying that it
does not matter how many neighbors of a particular node are spreaders, a
node will still have only one "chance" to become a spreader if it was
immune before. In an extreme case, suppose that there are only two immune
nodes in your network. One has ten thousand spreader neighbors, and the
other one has only one. Which one is more likely to become a spreader in
the next iteration?

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Color of nodes and edges according to numbers

[Tamas Nepusz]

Hi,

This question was already answered here on the mailing list:

https://lists.nongnu.org/archive/html/igraph-help/2017-05/msg00042.html

T.

On Tue, May 30, 2017 at 12:34 PM, Daniele Notarmuzi <
daniele.notarm...@gmail.com> wrote:

> Good morning,
>
> I use python 2.7.5 on ubuntu 14.04 and python-igraph 0.6.5
>
> I have the following problem: I have a network with N nodes and and array
> of N numbers, each between O and 1.
> I need:
>
> 1) the color of nodes i and j has to be the same if array[i] == array[j]
> 2) the color of edge ij has to be given according to this criterion:
> if( array[i] <= array[j] ):
> color_of_edge_ij = color_of_node_j
> else:
> color_of_egde_ij = color of node_j
>
> About the first question I was suggested here (
> https://lists.nongnu.org/archive/html/igraph-help/2011-04/msg00043.html)
> to assign manually the color to each node:
>
> g.vs[0]["color"] = "red"
> g.vs[1]["color"] = "blue"
> .
> .
> .
> g.vs[N]["color"] = "black"
>
> then I can do
>
> for i in (0,N):
>   for j in (i+1,N):
>  if (array[i] == array[j]):
>g.vs[i]["color"] = g.vs[j]["color"]
>
> This works but if N is a big number is not practicable to assign manually
> a color to each node.
>
> About the second question, I'vs tried to adapt the code in
> https://stackoverflow.com/questions/10067721/can-i-change-
> the-colour-of-edges-containing-specific-vertices-in-igraph-python
> to my case but the best I obtained was two different colors.
>
> In practice, I need a way to have univocal correspondence between numbers
> in [0,1] and colors. How can I obtain this? (maybe using palette?)
>
> thanks in advance.
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Ways to identify the origin of a network which comprises sequential edges

[Tamas Nepusz]

Hello,

Find the vertices with no inbound edges, i.e. vertices with an in-degree of
zero:

which(degree(g, mode="in") == 0)


T.

On Mon, May 29, 2017 at 7:27 AM, Adrian Dwiputra <
f.adrian.dwipu...@gmail.com> wrote:

> Hello there,
>
> Currently I've been trying to identify the vertice from which a complex
> directed network begins using igraph package in R. I already tried
> 'head_of' and 'tail_of' but the functions only return the heads and tails
> of the individual edges, not the network. Does anybody have any advice on
> the issue? Is there any way to achieve my objective?
>
> Many thanks in advance
>
> Best,
> Adrian
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Graph Clustering

[Tamas Nepusz]

Hi,

A common trick is to construct the line graph of the original graph, do the
clustering on the line graph (where each node corresponds to a single edge
from the original graph), and then map the obtained clustering back to the
edges of the original graph.


T.

On Fri, May 26, 2017 at 10:53 PM, lookman sanni 
wrote:

> Hi all,
>
> I am currently investigating graph clustering techniques/algorithms for
> the purpose of anomaly detection in static, edge attributed and
> disconnected graphs.
>
> From what I have seen so far, most of the graph clustering algorithms for
> anomaly detection output either a binary *node *classification or a *node
> *anomaly score.
>
> To the best of your knowledge, is there any algorithm rather providing
> either a binary *edge* classification or an *edge* anomaly score ?
>
> Thank you.
>
>
> --
>
> Lookman SANNI
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] color of nodes according to a number

[Tamas Nepusz]

>
> 1) the color of nodes i and j has to be the same if array[i] == array[j]
>
 Use a ClusterColoringPalette and a UniqueIdGenerator -- the
UniqueIdGenerator will be used to assign numeric identifiers to each of the
groups of items in 'array', while the ClusterColoringPalette will be used
to generate colors for them:

>>> id_gen = UniqueIdGenerator()
>>> color_indices = [id_gen.add(value) for value in array]
>>> palette = ClusterColoringPalette(len(id_gen))
>>> colors = [palette[index] for index in color_indices]
>>> graph.vs["color"] = colors

2) the color of edge ij has to be given according to this criterion:
> if( array[i] <= array[j] ):
> color_of_edge_ij = color_of_node_j
> else:
> color_of_egde_ij = color of node_j
>
for edge in graph.es:
u, v = edge.tuple
edge["color"] = colors[u if array[u] <= array[v] else v]

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] .graph_format

[Tamas Nepusz]

>
> 1- Is there a neat way of reading a METIS file with .graph extension as in
> http://www.cc.gatech.edu/dimacs10/archive/clustering.shtml data sets
> using igraph?
>
No, as far as I know -- you'll need to convert the file manually into
something that igraph can digest.


> vertices for all vertices starting from 1 to the number of vertices. I
> could not construct an igraph graph from this list. graph.adj.list()
> function does not work with such type of adjacency lists?
>
It should work, but note that the list is expected to be 0-indexed, i.e.
neighboring vertices should be numbered from 0 and not 1. What is the error
message that you see?

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Fwd: Regarding compare() in igraph

[Tamas Nepusz]

>
> If i want to compare two communities with compare() and both are
> hierarchical with overlapping communities so few vertices may have multiple
> memberships. but communities object has single membership for each vertex.
> how will compare work in such case.
>
It won't work; the methods that compare() use are all designed for
community structures where each node is a member of exactly one community.
There are alternative methods for comparing overlapping community
structures, but you'll have to implement these on your own.

Also if i have a graph with 6 nodes and community is #1 - { 1-2-3 }  #2 -
> {4-5-6}
> but some community detection algo finds #1-{4-5-6} and #2-{1-2-3}. on same
> graph. how will compare() work as communities are same but id are
> different.
>
The methods that compare() implement are not sensitive to the labeling of
the communities -- they will work just fine. (You can try it yourself -- in
your particular example, the two community structures will be considered
identical).

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Rewire probabilities question

[Tamas Nepusz]

Hi,

Q1:  Does the code below identify properly the new edges in the rewired
> graph in comparison to the original?
>
Well, the code is more or less correct -- it does not account for corner
cases like when an edge ends up being rewired twice or more (in such cases,
the edge may even end up being identical with some other edge from the
original one), but for large graphs, the probability of such corner cases
is negligible. Also, the function currently relies on the fact that the
order of edges is not changed during rewire, i.e. edge i in the original
graph ends up being edge i in the rewired graph -- the documentation does
not guarantee this so it may break in future releases.

Q2:  Why is it that, with a rewire of approx p=.30, I get approx 50% new
> edges (given the way I’ve defined new below).
>
It is because p is not equal to the probability of selecting an edge for
rewiring. I am not sure about the documentation of the R interface of
igraph; it may not be stated there, but the documentation of the C core
says that "each endpoint of each edge is rewired to a uniformly randomly
chosen vertex with constant probability". Since an edge in an undirected
graph has two endpoints, each edge gets *two* chances to be rewired --
therefore, the probability of an edge _not_ being rewired is equal to (1 -
0.3) * (1 - 0.3) = 0.49.

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] node overlapping in simplified network graph

[Tamas Nepusz]

Hi,

Try a different graph layout algorithm when calling plot(), e.g.:

plot(g2, layout=layout_with_fr)
plot(g2, layout=layout_with_kk)
plot(g2, layout=layout_with_graphopt)
plot(g2, layout=layout_with_gem)


T.

On Wed, May 10, 2017 at 11:44 AM, Piotr Wojciechowski <
p.wojciechow...@hta.pl> wrote:

> Dear igraph developers,
>
>
>
> I’m relatively new user of R and igraph, so please excuse me if my
> question is naive. I found igraph very useful in my work however I
> experienced a problem with plotting the graph, which I cannot overcome
> easily.
>
>
>
> I worked on following vertex vector:
>
>
>
> g1 <- graph ( edges=c(
>
> 1, 12,
>
> 1, 10,
>
> 1, 9,
>
> 9, 2,
>
> 9, 2,
>
> 1, 3,
>
> 1, 4,
>
> 9, 8,
>
> 1, 6,
>
> 9, 5,
>
> 1, 6,
>
> 1, 7,
>
> 1, 7,
>
> 1, 9,
>
> 9, 11,
>
> 9, 11,
>
> 1, 5,
>
> 1, 13,
>
> 1, 13), n=13,  directed=T)
>
>
>
> Then Iafter simplification I received following graph (see below). The
> problem is that on this graph I cannot distinguish 9->5 and 1->5 from 1->9,
> since they are overlapping each other (see below). From the graphical point
> of view problem solves when I reverse one of two 1->9 nodes to 9->1,
> however in my case directions are crucial. Is there a simple method to
> improve this graph without manipulation in the data vector?
>
>
>
> g2 <-simplify (g1)plot
>
>
>
> Thank you in advance,
>
> Piotr Wojciechowski
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] confused about vector pointer memory management

[Tamas Nepusz]

Hi,

In particular, I do not understand why igraph_vector_ptr_destroy_all()
> will both destroy and free all items, but igraph_vector_ptr_clear()
> will destroy them without freeing.
>
You are totally right -- igraph_vector_ptr_clear() should probably call the
element destructors AND free the items. The problem is that when we have
originally implemented pointer vectors, it did not have any item
destructors at all; they were added later as an "afterthought", and we did
not get this part right.

Actually, for me it seems like igraph_vector_ptr_destroy_all() and
igraph_vector_ptr_free_all() should not have been necessary in the first
place if we had item destructors from the very beginning. In that case, we
could have simply said that igraph_vector_ptr_t vectors do not "own" their
pointers and will not ever free them on their own -- all they could do is
to call a "destructor" function on them when the items get out of the
vector somehow. This way the user could have attached igraph_free as a
destructor function for pointer vectors that claim ownership for any
pointer added to them, and if the user needed something more complicated
than free() (i.e. igraph_*_destroy() followed by igraph_free()), then this
should have been done in a specialized destructor function on a
case-by-case basis.

The best way to avoid confusion for the time being is probably not to use
item destructors at all, or at least ensure that whenever you pass an
igraph_vector_ptr_t to some part of the code that you don't control, then
ensure that the vector does not have an item destructor and that the vector
is empty. This way you won't run into any unexpected side effects.

I am leaning towards trying to fix this by ensuring that the item
destructors get called when the items are removed from the vector using
igraph_vector_ptr_clear(), but I'm not sure how this would affect
third-party code. Personally, I don't use item destructors in the Python
interface and the C interface also uses them sparingly and only in places
where the pointer vectors equipped with destructors are not exposed to the
user, so this shouldn't cause too much problems for the end users, except
those who have been using the C interface directly and have used item
destructors before.

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Community detect error in iGraph R

[Tamas Nepusz]

Hi,

Which version of igraph are you using?

T.

On Sat, May 6, 2017 at 12:35 AM, Rodrigo Matus Nicodemos <
rodrigo.nicodemo...@gmail.com> wrote:

> Hello,
>
> I have a simple network I have generated on data I have.
>
> g <- graph.formula(A-D:M, C-B:D:G:K, C-B:E, D-A:B:F:H:L, E-C:I:O, F-D:M,
> G-B:J:K, H-D:I, I-E:H, J-G, K:B:N, L-D:M:N, M-A:F:L, N-K:L:O, O-E:N, P)
>
>  I have made the graph with this data and plotted it in R.
>
> However, I get an error message when I try to determine the communities in
> this network.
>
> eb <- cluster_edge_betweeness(g)
> Error: could not find function "cluster_edge_betweeness"
>
> or
>
> wc <- cluster_walktrap(g)
> Error: could not find function "cluster_walktrap"
>
> Why is this happening?
>
> Can I also plot the communities manually in R?
>
> Thank you.
>
> Rodrigo
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Understanding Barabasi Function and how to simulate a scale free()

[Tamas Nepusz]

>
> varies consistenyl. As of an example, I'll post here the results obtained
> using a network of 84 nodes and 221 edges and an alpha estimated on
> 2.614071596
>

That's too small a network to make any meaningful estimation of an
exponent. At small sample sizes, power laws, exponential distributions and
many other distributions are practically indistinguishable from each other.
Also, when testing, turn off the finite size correction:

>>> g=Graph.Static_Power_Law(n=10, m=25,
exponent_out=2.61407159636724, multiple=False, loops=False,
finite_size_correction=False)
>>> power_law_fit(g.degree()).alpha
2.677378126993507

That's much closer.

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Understanding Barabasi Function and how to simulate a scale free()

[Tamas Nepusz]

>
> I have one question regarding the Barabasi Function in GraphBase (python).
> The "m" parameter states [...]
> It isn't clear whether this m implies the average degree of the scale free
> network or something else.

Additionally, since it clearly states "outgoing edges", do I need to
> convert the network to undirect after calling the Barabasi() method?
>
No, simply use the directed=... keyword argument of the Graph.Barabasi()
constructor to decide whether you want an undirected or a directed network
in the end. However, note that the _generation process_ of the
Barabasi-Albert model assumes a _directed_ graph, i.e. the graph "stays"
directed during the whole generation process, and the arrowheads of the
edges are dropped only at the end of the generation process if you use
directed=False (which is also the default). That's why the "m" parameter
refers to the number of "outgoing edges" to generate because the edge
directions are distinguished while the graph is being generated.

This also ties into your other question regarding the relation of "m" to
the average degree. When the generated graph is directed, m is the
out-degree of each vertex except the first few where there are not enough
other vertices to connect to:

>>> g = Graph.Barabasi(n=20, m=2, directed=True)
>>> g.outdegree()
[0, 1, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2, 2]

So, in this case, the average out-degree tends to m as the graph becomes
large (i.e. n tends to infinity).

When the graph is undirected, the arrowheads are dropped at the end, but
this does not influence the outcome:

>>> g = Graph.Barabasi(n=2, m=2, directed=False)
>>> g.ecount() / float(g.vcount())
1.99985

So, yes, m is "almost" the average degree.

Moreover, I need to simulate several scale free networks  that "mirrors"
> real networks I'm studying. To this extent, I was searching for a function
> or an algorithm to infer the exponential parameter for the power law. does
> igraph for python offer something like this?

Yes; see the power_law_fit() function.


> Alternatively, could I use the average degree of the real networks  and
> give it to the Barabasi() function when defining "m"?
>
No, because the Barabasi-Albert model always generates networks with an
exponent of alpha=3 -- but only in the infinite limit, so don't expect that
power_law_fit() would return a fitted exponent of 3 for a finite graph that
you have generated with Graph.Barabasi().

Anyway, if you need to generate scale-free networks with a degree
distribution that follows a given exponent, then Graph.Barabasi() is not
the way to go. You need Graph.Static_Power_Law() instead:

>>> g = Graph.Static_Power_Law(n=10, m=20, exponent=3)
>>> fit = power_law_fit(g.degree())
>>> fit.alpha
3.0757961750805816

Static_Power_Law() is essentially a variation of the Static_Fitness()
method where each node is given a "fitness" value and the generation
process tries to ensure that the degrees of nodes are proportional to their
fitness values. Static_Power_Law() simply pre-generates a power-law degree
distribution and feeds it into Static_Fitness().

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Error pickling (very) large graphs: OSError: [Errno 22] Invalid argument

[Tamas Nepusz]

Hi,

Thanks Tamas! I had no idea that pickling was less efficient than a string
> format -- I'd assumed the efficiencies of storing in binary trumped the
> issues with references.
>
It's more efficient space-wise but probably less efficient time-wise and in
terms of peak memory usage (due to the reference checking). it is up to you
to decide which ones costs more in the long run. JSON does not have to
check references but it wastes space on the disk, so that's why running it
through gzip is probably a good idea.

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Error pickling (very) large graphs: OSError: [Errno 22] Invalid argument

[Tamas Nepusz]

Hi,

This could be a bug in the pickle implementation (not in igraph, but in
Python itself):

https://stackoverflow.com/questions/31468117/python-3-can-pickle-handle-byte-objects-larger-than-4gb
https://bugs.python.org/issue24658

The workaround is to pickle the object into a string, and then write that
string in chunks less than 2^31 bytes into a file.

However, note that pickling is not a terribly efficient format -- since it
needs to support serializing an arbitrary set of Python objects that may
link to each other and form cycles in any conceivable configuration, it has
to do a lot of extra bookkeeping so that object cycles and objects embedded
within themselves do not trip up the implementation. That's why the memory
usage rockets up to 35 GB during pickling. If you only have a name and an
additional attribute for each vertex, you could potentially gain some speed
(and cut down on the memory usage) if you brew your custom format -- for
instance, you could get the edge list and the two vertex attributes, stuff
them into a Python dict, and then save the dict in JSON format:

def graph_as_json(graph):
return {
"vertices": {
"name": graph.vs["name"],
"pt": graph.vs["pt"]
},
"edges": graph.get_edgelist()
}

with open("output.json", "w") as fp:
json.dump(graph_as_json(graph), fp)

You could also use gzip.open() instead of open() to compress the saved data
on-the-fly. You'll also need a json_as_graph() function to perform the
conversion in the opposite direction.


T.

On Tue, Apr 18, 2017 at 9:25 PM, Nick Eubank  wrote:

> Hello all,
>
> I'm trying to pickle a very large graph (23 million vertices, 152 million
> edges, two vertex attributes), but keep getting an `OSError: [Errno 22]
> Invalid argument` error. However, I think that's erroneous, as if I
> subsample the graph and save with exact same code I have no problems.
> Here's the traceback:
>
>
> g.summary()
> Out[8]: 'IGRAPH UN-- 23331862 152099394 -- \n+ attr: name (v), pt (v)'
>
> g.write_pickle(fname='graphs/with_inferred/vz_inferred3_sms{}_voz{}.pkl'.format(sms,
> voz))
> Traceback (most recent call last):
>
>  File "", line 1, in 
>
> g.write_pickle(fname='graphs/with_inferred/vz_inferred3_sms{}_voz{}.pkl'.format(sms,
> voz))
>
>  File "/Users/Nick/anaconda/lib/python3.5/site-packages/igraph/__init__.py",
> line 1778, in write_pickle
>result=pickle.dump(self, fname, version)
>
> OSError: [Errno 22] Invalid argument
>
>
> g=g.vs[range(3331862)].subgraph()
>
> g.write_pickle(fname='graphs/with_inferred/vz_inferred3_sms{}_voz{}.pkl'.format(sms,
> voz))
>
> [success]
>
> The graph takes up about 10gb in memory, and the pickle command expands
> Python's memory footprint to about 35gb before the exception gets thrown,
> but I'm on a machine with 80gb ram, so that's not the constraint.
>
> Any suggestions as to what might be going on / is there a work around for
> saving?
>
> Thanks!
>
> Nick
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] igraph for R: label nodes in the Main Component

[Tamas Nepusz]

Hi,

Something like this should do the trick:

cl <- clusters(g)
V(g)$in.giant <- membership(cl) == which.max(sizes(cl))


T.

On Sun, Apr 16, 2017 at 9:10 PM, Richard Benton 
wrote:

> Hi All,
> Apologies for forgetting to note the platform. I'm using igraph in R and
> I'm trying to construct a vertex level attribute that just flags TRUE or
> FALSE for whether the vertex is in the graph's giant component.
> Thank you,
> Richard
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Not finding http://nexus.igraph.org server

[Tamas Nepusz]

Hi,

Unfortunately I don't have the data at hand -- maybe Gabor does.

All the best,

T.

On Fri, Apr 14, 2017 at 10:05 PM, Szabolcs Horvát 
wrote:

> Until this is fixed, is the nexus data available somewhere else (even if
> in static, unsearchable form)?
>
> On 10 March 2017 at 21:22, Gábor Csárdi  wrote:
>
>> Unfortunately I forgot about it when I migrated the igraph website to
>> GitHub Pages. So it is down now.
>> I'll need to find it a new home, hopefully soon.
>>
>> Gabor
>>
>> On Fri, Mar 10, 2017 at 7:23 PM, Timothy Holzmann 
>> wrote:
>> > Hello,
>> > I can't seem to access the igraph nexus server.  When I browse to
>> > http://nexus.igraph.org, I get an error because my browser can't find
>> the
>> > server.  Similarly, I cannot access it from within the python graph
>> module.
>> >
>> > I don't see anything about the server being taken offline.  Is it still
>> up?
>> >
>> > Thanks,
>> > Tim
>> >
>> > --
>> > Tim Holzmann
>> > PhD Student, Industrial Engineering Dept
>> > Clemson University
>> >
>> > ___
>> > igraph-help mailing list
>> > igraph-help@nongnu.org
>> > https://lists.nongnu.org/mailman/listinfo/igraph-help
>> >
>>
>> ___
>> igraph-help mailing list
>> igraph-help@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/igraph-help
>>
>
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Label Nodes in the Main Component.

[Tamas Nepusz]

Hi,

Is this question about igraph in R, igraph in Python, or igraph in
Mathematica?

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Python iGraph: Create graph from numpy / pandas dataframe

[Tamas Nepusz]

Hi,

Graph.DictList() and Graph.TupleList() are meant to be used in cases when
the graph is already in memory in some format and you can cast the input
data into either a list-of-dictionaries representation or a list-of-tuples
representation. I believe in your case the list-of-tuples representation is
more natural. So, basically, you need to figure out a way to cast a pandas
DataFrame into a list (or iterable) where each element is a triplet
containing the source ID, the target ID and the weight, and then call
Graph.TupleList(your_list, weights=True).

All the best,

T.

On Sat, Apr 15, 2017 at 11:30 PM, Nick Eubank  wrote:

> Hell All,
>
> I'm trying to figure out the most efficient way of creating an igraph
> object form an edgelist stored in a numpy array (or rather, technically, a
> pandas DataFrame).
>
> The DataFrame looks something like:
>
> ab   weight
> 100101   1
> 100102   5
> 101103   1
> 101104   4
>
> The numbers in a and b are NOT sequential integers, though I can write
> code to make those conversion if necessary.
>
> One option is obviously to write out the data frame as a text file, then
> re-import as an ncol or such. But my dataset is very large (the edgelist
> has about 400,000,000 entries), which means that's a massively slow
> process, and I think loading the text file when importing into igraph may
> be requiring more ram than I have.
>
> I've found resources on importing adjacency matrices
> ,
> but nothing on edgelists.
>
> Anyone run into this before / have any suggestions?
>
> Thanks!
>
> Nick
>
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Igraph, how to get a scale free network with a given vertex average degree

[Tamas Nepusz]

Hi,

See my earlier answer from the mailing list:

https://lists.nongnu.org/archive/html/igraph-help/2017-03/msg8.html


T.

On Tue, Apr 4, 2017 at 3:46 PM, giorgio delzeri 
wrote:

> Hi guys of the (R) igraph community.
> I have a question for you, I already read several manuals but I still
> don't understand how to get, on igraph, an Undirected scale free network
> with n vertices and a given  average degree (for example, average degree of
> all vertexes = 8).
> Do you have any suggestions?
> Another way to get it, I think, is to force the network to have a given
> number of edges, since the average degree is 2M/N, where M is the total
> number of edges and N is the total number of vertices.
> Thank you, and sorry for my bad english, I am from Italy.
> Giorgio
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Igraph, how to get a scale free network with a given vertex average degree

[Tamas Nepusz]

Hi,

If the average degree is k and k is even, you can use sample_pa(n=..., m=k,
directed=FALSE). If the average degree is not even, you can use
sample_fitness_pl() instead, e.g.:

N <- 1
k <- 5
g <- sample_fitness_pl(N, k*N/2, 2)


T.

On Thu, Mar 30, 2017 at 10:21 PM, giorgio delzeri  wrote:

> Hi guys of the (R) igraph community.
> I have a question for you, I already read several manuals but I still
> don't understand how to give, on igraph, an Undirected scale free network
> with n vertices and a given  average degree (for example, average degree of
> all vertexes = 8).
> Do you have any suggestions?
> Thank you, and sorry for my bad english, I am from Italy.
>
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Sensitivity and FDR

[Tamas Nepusz]

Hello,

Are there sensitivity functions in igraph? Possibly for edge recovery in
> simulations?
>
No, there aren't any, as far as I know.

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] igraph layouts

[Tamas Nepusz]

Hi,

As far as I know, the Fruchterman-Reingold layout was re-written to make it
identical to the algorithm that was originally outlined in the paper of
Fruchterman and Reingold. The old implementation was something different,
and it was removed from the igraph codebase. You should simply use a
different layout if you are not satisfied with the output of the FR layout;
GraphOpt or Kamada-Kawai is usually okay.

T.

On Wed, Feb 22, 2017 at 6:07 PM, shailesh tripathi <
shailesh.tripa...@gmail.com> wrote:

> Hi,
>
> I am using igraph a lot and visualizing graphs as well. The newer version
> of igraph plotiing functions are not that better in their visualization as
> they were in older version
> specially layout.fruchterman.reingold function. can you make available
> older version of this function to the newest version or is there any
> parameter settings required to get
> the same old look layout.
>
>
> looking forward to your reply.
>
> Best,
> Shailesh
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] create graph object

[Tamas Nepusz]

Hi,

You need to create a graph from the data frame first using
graph_from_data_frame.

T.

On Wed, Feb 22, 2017 at 3:37 PM, Dieunel Derilus 
wrote:

> Dear  Igraph develpppers and memebers
>
>  I am facing some difficulties to remove redundancy from anetwork
> using  'simplify' in 'igraph' package. My network is in a table file,
> firstly my data frame as an object and secondly I run the command
> line: simplify(g, remove.multiple = TRUE), and have an output error saying
>  created object is   not  an igraph object . My question is how I can
> convert a text file  to a graph object  to avoid this error message ?
>
> Here is   my input and the output in R :
> > g <- read.table("data.txt")
> > g
>   V1 V2
> 1  a  b
> 2  b  a
> 3  d  o
> 4  d  l
> > g <- read.table("data.txt")
> > simplify(g, remove.multiple = TRUE)
> Error in simplify(g, remove.multiple = TRUE) : Not a graph object
>
>
> Thanks in advance
>
> DD
> --
> Derilus Dieunel
> Graduate Student
> Department of Environmental Sciences
> University of Puerto Rico, Río Piedras
>
>
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Global efficiency igraph Python

[Tamas Nepusz]

>
> Do I do something wrong?
>
Yes; the argument of subgraph() is the IDs of the nodes to be included in
the subgraph. Neighbors are not included. You need
g.subgraph(g.neighborhood(5)) instead.

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Global efficiency igraph Python

[Tamas Nepusz]

Hello,

I'm pretty sure that you can calculate it, but there is no built-in
function for it. You need to calculate the shortest path lengths using
igraph and then just follow the formula in the paper.

T.

On Wed, Feb 22, 2017 at 10:17 AM, Serafeim Loukas 
wrote:

> Dear all,
>
> I would like to ask if there is a way to calculate the *Global Efficiency
> *of each node in a graph as defined by Achard 2007, Latora 2001).
>
>
> Thank you,
> S
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] List triangles

[Tamas Nepusz]

Hi,

triangles has to be initialized before calling igraph_list_triangles with
igraph_vector_int_init(). Just initialize it to a size of zero and
igraph_list_triangles() will resize it as needed.

T.

On Tue, Feb 21, 2017 at 5:32 PM, Perrone, Alexander G. <
alexander.perr...@jhuapl.edu> wrote:

> ​How can one list all the triangles in igraph C? I could not find an
> example in documentation. I'd like the same output as triangles(g) in R. I
> tried the following as an example but I cannot get it to work. Error
> is Segmentation fault (core dumped). Any help would be much appreciated.
>
>
> #include 
>
> int main(void) {
>   igraph_vector_t v;
>   igraph_vector_int_t triangles;
>   igraph_t graph;
>
>   igraph_real_t edges[] = { 0, 1, 0, 2, 1, 2, 2, 3, 2, 4, 3, 4 };
>   igraph_vector_view(&v, edges, sizeof(edges)/sizeof(double));
>   igraph_create(&graph, &v, 0, IGRAPH_UNDIRECTED);
>
>   igraph_list_triangles(&graph, &triangles);
>   igraph_vector_int_destroy(&triangles);
> }
>
>
> Alex
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Plotting --> AttributeError: 'bytes' object has no attribute 'encode'

[Tamas Nepusz]

Hi,

This is a known issue with python-igraph 0.7.1 and Python 3.x:

https://github.com/igraph/python-igraph/issues/88

You need to apply this patch manually to the source code to fix it:

https://github.com/igraph/python-igraph/commit/8864b46849b031a3013764d03e167222963c0f5d


T.

On Sun, Jan 29, 2017 at 9:45 PM, roberto franceschini <
franceschini.robe...@gmail.com> wrote:

> Hello, in python I am doing
>
> G = igraph.Graph.Full(10)
> igraph.plot(G, bbox = (400,400), layout = G.layout('kk'))
>
> and I get
>
> AttributeErrorTraceback (most recent call 
> last)/usr/local/lib/python3.6/site-packages/IPython/core/formatters.py in 
> __call__(self, obj)309 method = get_real_method(obj, 
> self.print_method)310 if method is not None:--> 311   
>   return method()312 return None313 else:
> /usr/local/lib/python3.6/site-packages/igraph/drawing/__init__.py in 
> _repr_svg_(self)352 surface.finish()353 # Return the 
> raw SVG representation--> 354 return io.getvalue().encode("utf-8")
> 355 356 @property
> AttributeError: 'bytes' object has no attribute 'encode'
>
>
> I cannot find a match for this in google or stackoverflow. Since I have never 
> used plots of iGraph before in Python I thought was best to ask.
>
> Thanks for helping,
>
> Roberto
>
>
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Selecting edges if a node is present

[Tamas Nepusz]

>
> I presume this is a very simple question. If I have a directed network,
> how do I select edges that have a given node as sink?
>
Use incident(graph, vertex, mode="in") to get the indices of all the edges
that terminate in a given node. Alternatively, you may use the [[ operator
(see http://igraph.org/r/doc/sub-sub-.igraph.html):

graph[[, v, edges=TRUE]]


> Further, how do I generate a subgraph comprised of all the edges that have
> a given node as sink?
>
Use subgraph.edges(); see: http://igraph.org/r/doc/subgraph.html

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Selecting edges if a node is present

[Tamas Nepusz]

Hi,

Are you working with R, Python or C?

T.

On Fri, Jan 27, 2017 at 6:30 PM, David Gelvez Alvarez  wrote:

> Dear all,
>
> I presume this is a very simple question. If I have a directed network,
> how do I select edges that have a given node as sink?
>
> Further, how do I generate a subgraph comprised of all the edges that have
> a given node as sink?
>
> Kind regards,
>
> D
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] undefined symbol: xmlStrEqual when import igraph.Graph

[Tamas Nepusz]

For the record: we have managed to solve the issue. The problem was that
there was another copy of libxml2 installed on the system in
/usr/local/lib, and this was somehow unsuitable for dynamic linking.
Removing the extra copy of libxml2 fixed the problem.

T.

On Wed, Jan 25, 2017 at 10:33 AM, Tamas Nepusz  wrote:

> Hi Andrew,
>
> Can you post me (in private) the full install log of "pip install
> python-igraph" when starting from scratch? You can get the install log with
> the following command:
>
> pip install python-igraph 2>&1 >pip.log
>
> Thanks,
>
> T.
>
> On Wed, Jan 25, 2017 at 10:00 AM, Andrew O'Harney 
> wrote:
>
>> I gave that ago, but to no avail. I'm at a bit of a loss as to what could
>> be going on.
>> ᐧ
>>
>> On 23 January 2017 at 20:40, Tamas Nepusz  wrote:
>>
>>> Hi Andrew,
>>>
>>> This is weird -- it should not have been able to compile and link the
>>> Python interface to igraph without libxml2 at all.
>>>
>>> You mentioned that you installed python-igraph from pip -- this almost
>>> surely means that igraph itself was compiled on your machine locally. The
>>> only thing that I can think of right now is that you have libxml2 on your
>>> machine but not libxml2-dev; the latter package is needed to _compile_
>>> packages that link to libxml2. So, I would probably try this:
>>>
>>> - ensure that libxml2-dev and pkg-config are both installed
>>> - uninstall python-igraph (either destroy the venv and start from
>>> scratch, or run pip uninstall python-igraph)
>>> - reinstall python-igraph with "pip install python-igraph"
>>>
>>> All the best,
>>>
>>> T.
>>>
>>> On Mon, Jan 23, 2017 at 11:44 AM, Andrew O'Harney 
>>> wrote:
>>>
>>>> This gives
>>>>
>>>> linux-vdso.so.1 =>  (0x7ffdd33b8000)
>>>> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
>>>> (0x7f7ce24c5000)
>>>> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>>>> (0x7f7ce2143000)
>>>> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
>>>> (0x7f7ce1f2c000)
>>>> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
>>>> (0x7f7ce1d0f000)
>>>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
>>>> (0x7f7ce1946000)
>>>> /lib64/ld-linux-x86-64.so.2 (0x55e56299f000)
>>>>
>>>> I can't see a mention of libxml there. How can I add it and is there a
>>>> reason it wasn't linked with pip?
>>>>
>>>> -Andy
>>>>
>>>> ___
>>>> igraph-help mailing list
>>>> igraph-help@nongnu.org
>>>> https://lists.nongnu.org/mailman/listinfo/igraph-help
>>>>
>>>>
>>>
>>> ___
>>> igraph-help mailing list
>>> igraph-help@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/igraph-help
>>>
>>>
>>
>> ___
>> igraph-help mailing list
>> igraph-help@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/igraph-help
>>
>>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] undefined symbol: xmlStrEqual when import igraph.Graph

[Tamas Nepusz]

Hi Andrew,

Can you post me (in private) the full install log of "pip install
python-igraph" when starting from scratch? You can get the install log with
the following command:

pip install python-igraph 2>&1 >pip.log

Thanks,

T.

On Wed, Jan 25, 2017 at 10:00 AM, Andrew O'Harney  wrote:

> I gave that ago, but to no avail. I'm at a bit of a loss as to what could
> be going on.
> ᐧ
>
> On 23 January 2017 at 20:40, Tamas Nepusz  wrote:
>
>> Hi Andrew,
>>
>> This is weird -- it should not have been able to compile and link the
>> Python interface to igraph without libxml2 at all.
>>
>> You mentioned that you installed python-igraph from pip -- this almost
>> surely means that igraph itself was compiled on your machine locally. The
>> only thing that I can think of right now is that you have libxml2 on your
>> machine but not libxml2-dev; the latter package is needed to _compile_
>> packages that link to libxml2. So, I would probably try this:
>>
>> - ensure that libxml2-dev and pkg-config are both installed
>> - uninstall python-igraph (either destroy the venv and start from
>> scratch, or run pip uninstall python-igraph)
>> - reinstall python-igraph with "pip install python-igraph"
>>
>> All the best,
>>
>> T.
>>
>> On Mon, Jan 23, 2017 at 11:44 AM, Andrew O'Harney 
>> wrote:
>>
>>> This gives
>>>
>>> linux-vdso.so.1 =>  (0x7ffdd33b8000)
>>> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6
>>> (0x7f7ce24c5000)
>>> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
>>> (0x7f7ce2143000)
>>> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
>>> (0x7f7ce1f2c000)
>>> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
>>> (0x7f7ce1d0f000)
>>> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
>>> (0x7f7ce1946000)
>>> /lib64/ld-linux-x86-64.so.2 (0x55e56299f000)
>>>
>>> I can't see a mention of libxml there. How can I add it and is there a
>>> reason it wasn't linked with pip?
>>>
>>> -Andy
>>>
>>> ___
>>> igraph-help mailing list
>>> igraph-help@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/igraph-help
>>>
>>>
>>
>> ___
>> igraph-help mailing list
>> igraph-help@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/igraph-help
>>
>>
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] igraph R: vertices and attributes do not match

[Tamas Nepusz]

Hi Yvonne,

The easiest would be to create a dataframe that already contains the edge
attributes, and then pass that data frame to graph.data.frame(). Would that
work for you? You can use merge() to merge the original data frame with the
edge list and the additional data frame containing the attributes. See the
documentation of ?merge for more details.


T.

On Tue, Jan 24, 2017 at 4:21 PM, Yvonne Hegele <
yvonne.heg...@uni-konstanz.de> wrote:

> Hello everyone,
>
> I have a problem which seems easy but I could absolutly not find a
> solution for it, so I would very much appreciate your help:
>
> I have an edgelist containing a number of edges with named IDs. I imported
> this data ("edgelist") and created a igraph object in R  using the code:
> network <- graph.data.frame(edgelist)
>
> Second, I imported a matrix of attributes ("attributes") into R containing
> the IDs of the edges (as used in edgelist) as first column and further
> columns with other attributes. To attache these attributes, I used the code
> (from https://sna.stanford.edu/lab.php?l=1)
>
> for (i in V(network)) {
>   for (j in names(attributes)) {
> network <- set.vertex.attribute(network,
>j,
>index = i,
>attributes[i, j])
>   }
> }
>
> Unfortunately, in the edgelist some edges are not senders but R sorted the
> edges according to their appearence in the edgelist which now differs from
> the order in the attributes matrix. Hence my problem is now that the
> attributes are not matched correctly upon the vertices in the igraph
> network. Unfortunately, there is no easy way how to sort the attribute
> matrix in the same order than the igraph network did automatically (Or is
> this the easieast way and you know one?)
>
> So I tried to create an empty graph and fill in the information one after
> the other:
> network <- graph.empty()
> First the 171 vertices as their IDs
> add.vertices(network,171,"name", attr = list(as.character(attributes$ID)))
> This however produces the following error message:
>
> Error in add.vertices(network, 171, "name", attr = 
> list(as.character(attributes$ID))) :
>   please supply names for attributes
>
>
> In the next step I hoped to include the edges as in edgelist into this
> listing of edges with add.edges. But I am not sure if this was successful
> in recognizing the correct IDs for the edges and attributes.
>
> Could you please help me working around this problem?
>
> Many thanks!
> Yvonne
>
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] undefined symbol: xmlStrEqual when import igraph.Graph

[Tamas Nepusz]

Hi Andrew,

This is weird -- it should not have been able to compile and link the
Python interface to igraph without libxml2 at all.

You mentioned that you installed python-igraph from pip -- this almost
surely means that igraph itself was compiled on your machine locally. The
only thing that I can think of right now is that you have libxml2 on your
machine but not libxml2-dev; the latter package is needed to _compile_
packages that link to libxml2. So, I would probably try this:

- ensure that libxml2-dev and pkg-config are both installed
- uninstall python-igraph (either destroy the venv and start from scratch,
or run pip uninstall python-igraph)
- reinstall python-igraph with "pip install python-igraph"

All the best,

T.

On Mon, Jan 23, 2017 at 11:44 AM, Andrew O'Harney  wrote:

> This gives
>
> linux-vdso.so.1 =>  (0x7ffdd33b8000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x7f7ce24c5000)
> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> (0x7f7ce2143000)
> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1
> (0x7f7ce1f2c000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x7f7ce1d0f000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x7f7ce1946000)
> /lib64/ld-linux-x86-64.so.2 (0x55e56299f000)
>
> I can't see a mention of libxml there. How can I add it and is there a
> reason it wasn't linked with pip?
>
> -Andy
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] undefined symbol: xmlStrEqual when import igraph.Graph

[Tamas Nepusz]

Hi,

Please try this:

$ ldd /home/ubuntu/djangoproject/env/lib/python3.5/site-packages/i
graph/_igraph*.so

This should tell you which libraries _igraph.so is trying to link to; in my
case, it includes a line like this:

libxml2.so.2 => /usr/lib/x86_64-linux-gnu/libxml2.so.2

If you have a line like the one above, check the .so file that it refers to
and verify that it exists and is not a dangling symlink.


T.

On Mon, Jan 23, 2017 at 11:21 AM, Andrew O'Harney  wrote:

> From fresh the commands were:
>
> virtualenv -p python3
> source env/bin/activate
> pip install python-igraph==0.7.1.post6
>
> On 23 January 2017 at 10:17, Tamas Nepusz  wrote:
>
>> How did you install the Python interface for igraph? Is this a
>> pre-compiled package that you have downloaded from somewhere, or did you
>> compile the Python interface on your own? It could be the case that the
>> Python interface is trying to link to a different version of libxml2 than
>> the one on your system.
>>
>> T.
>>
>> On Mon, Jan 23, 2017 at 11:15 AM, Andrew O'Harney 
>> wrote:
>>
>>> I believe it is.
>>> apt-get install libxml2 gives:
>>> libxml2 is already the newest version (2.9.3+dfsg1-1ubuntu0.1).
>>>
>>> On 23 January 2017 at 10:10, Gábor Csárdi 
>>> wrote:
>>>
>>>> I think the libxml2 package is not installed on your system.
>>>>
>>>> G.
>>>>
>>>> On Mon, Jan 23, 2017 at 10:09 AM, Andrew O'Harney 
>>>> wrote:
>>>>
>>>>> I am trying to import igraph.Graph in python 3.5.0 on Ubuntu 16.04.1
>>>>> LT however get the following error:
>>>>>
>>>>> from igraph._igraph import *
>>>>>
>>>>> ImportError: /home/ubuntu/djangoproject/env
>>>>> /lib/python3.5/site-packages/igraph/_igraph.cpython-35m-x86_
>>>>> 64-linux-gnu.so: undefined symbol: xmlStrEqual
>>>>>
>>>>> I am using a virtualenv and the requirement is
>>>>> python-igraph==0.7.1.post6
>>>>>
>>>>> Does anyone have an idea how this can be resolved?
>>>>>
>>>>> Thanks,
>>>>> Andy
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> igraph-help mailing list
>>>>> igraph-help@nongnu.org
>>>>> https://lists.nongnu.org/mailman/listinfo/igraph-help
>>>>>
>>>>>
>>>>
>>>> ___
>>>> igraph-help mailing list
>>>> igraph-help@nongnu.org
>>>> https://lists.nongnu.org/mailman/listinfo/igraph-help
>>>>
>>>>
>>>
>>> ___
>>> igraph-help mailing list
>>> igraph-help@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/igraph-help
>>>
>>>
>>
>> ___
>> igraph-help mailing list
>> igraph-help@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/igraph-help
>>
>>
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] undefined symbol: xmlStrEqual when import igraph.Graph

[Tamas Nepusz]

How did you install the Python interface for igraph? Is this a pre-compiled
package that you have downloaded from somewhere, or did you compile the
Python interface on your own? It could be the case that the Python
interface is trying to link to a different version of libxml2 than the one
on your system.

T.

On Mon, Jan 23, 2017 at 11:15 AM, Andrew O'Harney  wrote:

> I believe it is.
> apt-get install libxml2 gives:
> libxml2 is already the newest version (2.9.3+dfsg1-1ubuntu0.1).
>
> On 23 January 2017 at 10:10, Gábor Csárdi  wrote:
>
>> I think the libxml2 package is not installed on your system.
>>
>> G.
>>
>> On Mon, Jan 23, 2017 at 10:09 AM, Andrew O'Harney 
>> wrote:
>>
>>> I am trying to import igraph.Graph in python 3.5.0 on Ubuntu 16.04.1 LT
>>> however get the following error:
>>>
>>> from igraph._igraph import *
>>>
>>> ImportError: /home/ubuntu/djangoproject/env
>>> /lib/python3.5/site-packages/igraph/_igraph.cpython-35m-x86_
>>> 64-linux-gnu.so: undefined symbol: xmlStrEqual
>>>
>>> I am using a virtualenv and the requirement is python-igraph==0.7.1.post6
>>>
>>> Does anyone have an idea how this can be resolved?
>>>
>>> Thanks,
>>> Andy
>>>
>>>
>>>
>>>
>>> ___
>>> igraph-help mailing list
>>> igraph-help@nongnu.org
>>> https://lists.nongnu.org/mailman/listinfo/igraph-help
>>>
>>>
>>
>> ___
>> igraph-help mailing list
>> igraph-help@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/igraph-help
>>
>>
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Creation of Directed Graph

[Tamas Nepusz]

Hi Lorenzo,

How about this:

- Create a graph using graph.data.frame just like you did.
- Assign 1 as the weight of each edge (ie.. E(g)$weight <- rep.int(1,
ecount(g))
- Use simplify(g, edge.attr.comb=list(weight="sum")) -- this gives you a
graph with at most two edges between two nodes (in the two possible
directions) and their weights will contain the total number of agents
moving in that direction. So we have reached point 2) here.

Getting to point 1) is somewhat more complex; I would probably convert the
graph obtained above back to a weighted adjacency matrix (possibly sparse
if the graph is large), multiply the cells below the main diagonal by -1,
add the matrix to its own transpose, drop all the matrix cells with
negative weights, and create a weighted directed graph out of it again.


T.

On Wed, Jan 4, 2017 at 4:18 PM, Lorenzo Isella 
wrote:

> Dear All,
> Please have a look at the snippet at the end of the email.
> I explain in some detail what I need and why I am struggling.
> I need to generate a *directed* graph starting from data like
>
>
> UK  FR
> BE  UK
> UK  FR
> FR  UK
>
> where each line indicates the movement of one agent from the country
> on the left to the one on the right.
>
> In the example before, 2 agents left the United Kingdom (UK) for
> France (FR), one left Belgium (BE) for the UK, and another one left France
> for the UK.
> Starting from that, there are 2 things I am after:
> 1) I would like to generate a directed network in
> which the weight of each edge is the net flux of agents.
> E.g. in the example above, the due to the agent movements, I would
> have an edge from UK to FR with weight 1 (2 agents left the UK for FR
> and 1 left FR for the UK). I also would like to have the weight of
> each node as the total influx of agents (which could be negative,
> e.g. in the case of BE above 1 agent leaves BE and no one gets there)
> 2) Could I actually have 2 edges between different countries (which
> are nodes)? For instance, have one edge with weight 2 from UK to FR
> and one with weight 1 from FR to UK.
>
> A larger numerical example is given below, but the idea is the same.
> I try to get the edge weight based on their multiplicity, but
> obviously I am doing something wrong.
> Any help is appreciated.
> Cheers
>
> Lorenzo
>
>
>
>
>
>
> 
> 
>
> tab<-structure(c("NZ", "AU", "RU", "AU", "FR", "AU", "AR", "AU", "UY",
> "IN", "US", "FR", "FR", "RU", "ES", "BE", "FR", "ES", "FR", "US",
> "DE", "CA", "PL", "IT", "FR", "AU", "DE", "JP", "SE", "PL", "FR",
> "ES", "NL", "IE", "HU", "BR", "CH", "NL", "JP", "HU", "CZ", "ES",
> "IN", "IL", "AU", "CH", "PL", "FR", "PL", "FR", "HU", "ES", "IT",
> "UK", "FR", "SE", "DE", "FR", "DE", "ES", "NL", "UK", "ES", "CH",
> "UK", "DE", "FR", "UK", "US", "DE", "AU", "FR", "IT", "IT", "US",
> "JP", "ES", "SE", "ES", "AR", "HU", "AT", "US", "IN", "AU", "NZ",
> "MX", "AU", "CA", "PL", "IN", "UK", "CA", "FR", "BE", "IN", "ES",
> "PL", "IE", "BE", "UK", "IT", "JP", "US", "ES", "FR", "EL", "IE",
> "UK", "NL", "SI", "DE", "DE", "IT", "EG", "ES", "IT", "UA", "IT",
> "AT", "ES", "IT", "ES", "ES", "PL", "FR", "NL", "IE", "US", "IT",
> "HU", "CA", "DE", "DE", "CL", "PT", "NL", "PL", "PL", "IT", "PL",
> "CA", "PL", "FR", "AR", "NL", "ES", "CY", "TN", "DE", "ES", "DE",
> "NL", "ES", "DE", "ES", "TR", "RO", "HU", "ES", "KH", "ES", "FR",
> "UK", "IT", "CH", "FR", "FR", "US", "IT", "SI", "ES", "DE", "NZ",
> "TR", "FR", "SE", "IN", "FR", "FR", "BE", "BE", "US", "IT", "IT",
> "IT", "FI", "DE", "UK", "IL", "IS", "FR", "FI", "IN", "FI", "SK",
> "DE", "ES", "UK", "DK", "FR", "FR", "DE", "NL", "ES", "ES", "SY",
> "FR", "DE", "JP", "FR", "ES", "US", "ES", "SE", "US", "ES", "CY",
> "SE", "MX", "IT", "NL", "CA", "BE", "IL", "IE", "UK", "FR", "PT",
> "ES", "DE", "SE", "IT", "HU", "IT", "PT", "NL", "AT", "ES", "DE",
> "US", "CH", "NL", "DE", "IN", "RU", "NL", "FR", "NL", "ES", "US",
> "SE", "FR", "FR", "IL", "US", "DE", "US", "IT", "FR", "DE", "IE",
> "AU", "SE", "JP", "FR", "IT", "IT", "AR", "FR", "ES", "HU", "SK",
> "IT", "BE", "UK", "DE", "FR", "UK", "UK", "UK", "CH", "IE", "IT",
> "FI", "DE", "FR", "FR", "RU", "ES", "BE", "FR", "FR", "DE", "UK",
> "UK", "DK", "UK", "FR", "DE", "SE", "AT", "DE", "UK", "SE", "BE",
> "IT", "NO", "CH", "HU", "ES", "FR", "UK", "UK", "FR", "UK", "UK",
> "CH", "IL", "UK", "UK", "DE", "SE", "UK", "FR", "PT", "UK", "FR",
> "SE", "UK", "UK", "ES", "UK", "SE", "UK", "NL", "DE", "UK", "DE",
> "ES", "DK", "CH", "ES", "FR", "UK", "UK", "UK", "ES", "IT", "FR",
> "UK", "UK", "UK", "UK", "BE", "FR", "BE", "UK", "UK", "ES", "NO",
> "ES", "FR", "UK", "UK", "UK", "ES", "UK", "UK", "CH", "IE", "UK",
> "DE", "UK", "NL", "UK", "UK", "CZ", "SE", "UK", "UK", "DE", "DK",
> "UK", "CH", "ES", "IL", "UK", "CH", "FI", "UK", "FR", "SE", "UK",
> "DE", "ES", "FR", "UK", "DE", "UK", "DE", "FR", "UK", "CH", "UK",
> "FI", "FR", "FR", "UK", "IT", "PT", "CH", "ES", "CH", "NO", "CH",
> "NL", "UK", "C

Re: [igraph] Graph-level weighted degree, betweeeness, closeness?

[Tamas Nepusz]

>
> However, is the weight edge attribute of the graph automatically detected
> when calculating the graph-level versions of these three metrics?
>
I guess not because the output seems to be blissfully ignorant of weights:

> g <- make_ring(10)
> centr_betw(g)
$res
 [1] 8 8 8 8 8 8 8 8 8 8

$centralization
[1] 0

$theoretical_max
[1] 324
> E(g)$weight <- c(100, rep(1, 9))
> centr_betw(g)
$res
 [1] 8 8 8 8 8 8 8 8 8 8

$centralization
[1] 0

$theoretical_max
[1] 324

I think the reason is that the graph-level cenrality metrics require the
"theoretical maximum" of the centrality score across all possible connected
networks with the same node count, and this is not well-defined for
weighted graphs (because we don't know what we shall do with the weight --
shall we consider all possible permutations of the original weight set, or
shall we consider weights uniformly distributed within a certain bounded or
unbounded range?). If you can come up with or show us a formal definition
of the centralization (i.e. graph-level centrality) score for weighted
graphs, maybe we can come up with a solution using igraph.

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Igraph With Bo Result for Big Dataset

[Tamas Nepusz]

>
> What is the problem ? Is igraph not adapted for huge community ?
>
The walktrap method is not suitable for graphs of this size. Try a
different algorithm; I would probably take a shot with cluster_louvain()
first.

T.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Position edge labels in python

[Tamas Nepusz]

Hi,

Edge drawing is implemented in specialized edge drawer classes in
igraph/drawing/edge.py. They all derive from an abstract base class called
AbstractEdgeDrawer, which defines a function named get_label_position()
that returns the position of the label for an edge. The default edge drawer
used by igraph is called ArrowEdgeDrawer.

You can therefore simply implement a new class derived from
ArrowEdgeDrawer, override its get_label_position() method, and then use
this custom edge drawer when plotting the graph as follows:

from igraph.drawing.edge import ArrowEdgeDrawer
from igraph.drawing.graph import DefaultGraphDrawer
from functools import partial

class CustomEdgeDrawer(ArrowEdgeDrawer):
# do your magic here
pass

my_drawer = partial(DefaultGraphDrawer,
edge_drawer_factory=CustomEdgeDrawer)
plot(graph, drawer_factory=my_drawer)

(Haven't tested it, but it should work).

All the best,

T.

On Wed, Dec 21, 2016 at 10:03 AM, José Juan Almagro Armenteros <
jjalma...@gmail.com> wrote:

> Hello,
>
> Thank you for the info. Could you indicate which function defines the
> position of the edge labels? At least I would like to change the default
> positions for all the labels.
>
> Best,
> Jose
>
> On 20/12/2016 21:10, Tamas Nepusz wrote:
>
> Hi,
>
> Unfortunately it is not possible to change the position of edge labels
> with the current plotting engine.
>
> All the best,
>
> T.
>
> On Tue, Dec 20, 2016 at 6:23 PM, José Juan Almagro Armenteros <
> jjalma...@gmail.com> wrote:
>
>> Hello,
>>
>> I have just started using this packages and I have generated a nice tree
>> plot. However, I haven't been able to change the position of the edge
>> labels and there is no documentation about it. Do you know how could I do
>> this?
>>
>> Best,
>> Jose
>>
>>
>> ___
>> igraph-help mailing list
>> igraph-help@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/igraph-help
>>
>
>
>
> ___
> igraph-help mailing 
> listigraph-help@nongnu.orghttps://lists.nongnu.org/mailman/listinfo/igraph-help
>
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help