Re: [igraph] trees

[Szabolcs Horvát]

Hello Keith,

This mailing list will shut down soon. Please use the forum instead:

https://igraph.discourse.group/

The python-igraph documentation has a short tutorial on visualization,
which should be helpful:

https://igraph.org/python/doc/tutorial/tutorial.html#layouts-and-plotting

For trees, look at the Reingold-Tilford layout method.

On Fri, 31 Jul 2020 at 16:20, Keith Paton  wrote:
>
> Hello igraph,
>
> I am interested in how to draw a tree, as discussed below. Who can help?
>
> Thanks,
>
> Keith Paton
>
> Independent researcher
>
> ---
>
> A tree is a connected graph without cycles; it can be drawn in the plane in 
> many different ways. Somewhat remarkably, the drawings of all the trees with 
> up to ten nodes published by Harary and by Schlick are remarkably similar; 
> the former were drawn by Harary’s artist, the latter by the program 
> Python.igraph.
>
> How does that come about? Harary wrote in 1969 so did not have access to 
> Python.igraph. What rules are used by Python.igraph and how does it come 
> about that the drawings it generates are identicalto those in Haray, even 
> down to the five cases where IMHO both systems make a mistake and draw the 
> tree wrongly.
>
> Harary F (1969) Graph Theory Chapman & Hall
>
> Tamar Schlick runs the RNA research group at NYU. Her group maintains a 
> database of trees with up to ten nodes, all drawn by Python.igraph
>
> ___
> 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] betweenness non-integer values for vertex?

[Szabolcs Horvát]

Dear Thomas,

This mailing list will be shut down soon. Please use
https://igraph.discourse.group/ instead.

What you quote is a good intuitive handle for understanding
betweenness, but if you look at the mathematical definition,

https://en.wikipedia.org/wiki/Betweenness_centrality#Definition

you will see that if there is a pair of vertices between which there
is more than one minimum length path, the betweenness value may not be
integer.

On Fri, 24 Jul 2020 at 11:58, Scherngell Thomas
 wrote:
>
> Dear colleagues,
>
>
>
> I have a network of 130 countries with weighted interactions between them. I 
> am calculating vertex betweenness to rank countries by betweenness, and get 
> back non-integer values for each vertex (both in the weighted and unweighted 
> case). Reading that “The vertex and edge betweenness are (roughly) defined by 
> the number of geodesics (shortest paths) going through a vertex or an edge” I 
> would expect integer values as result, or do I get something wrong?
>
>
>
> Best,
>
> Thomas
>
> ___
> 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] Help seeking on calculating betweenness centrality with valued ties

[Szabolcs Horvát]

Dear Chuding,

This mailing list will close soon. Support for igraph is now provided
through the forum: https://igraph.discourse.group/  Please post the
question there.

Szabolcs

On Sat, 6 Jun 2020 at 16:23, CHU-DING LING  wrote:

> Dear all,
>
>
>
> I am trying to calculate the betweenness centrality with valued ties, but
> I do not figure it out. Here are the dataset and codes.
>
>
>
> 1. This is an example dataset with only four nodes/individuals. When
> collecting the network data, I asked the participants to answer the
> question about friendship tie on a 7-point Likert scale. So, this is a
> *directed* and *valued* network. Moreover, when inputting the network
> data, I adopted the edge list format and saved it into a CSV file. The
> details of the data are as follows:
>
>
>
> Actor Target   Friend
>
> 1001  1002  5
>
> 1001  1003  6
>
> 1001  1004  5
>
> 1002  1001  6
>
> 1002  1003  6
>
> 1002  1004  6
>
> 1003  1001  4
>
> 1003  1002  4
>
> 1003  1004  4
>
> 1004  1001  6
>
> 1004  1002  6
>
> 1004  1003  6
>
>
>
> 2. Then I ran the following codes to calculate the betweenness centrality:
>
>
>
> library(igraph)
>
>
>
> #Step 1. read the edgelist format dataset into R
>
> Mydata <- read.table("Example.csv", header=TRUE, sep=",")
>
>
>
> #Step 2. convert an edgelist matrix with valued edges/ties into a graph
>
> Mygraph <- graph_from_data_frame(Mydata, directed=TRUE)
>
>
>
> #Step 3. calculate betweenness centrality but fail to account for the
> value/weight of the tie
>
> betweenness (Mygraph, directed = T, normalized = T)
>
>
>
> 3. The results came out are as follows:
>
>
>
> 1001  1002  1003  1004
>
> 0  0  0  0
>
>
>
> It seems that the package treated the dataset as that the four members
> mutually nominated each other as friends while ignored the strength of the
> tie. Therefore, each of them was connected to the others and no one had the
> opportunity to be a broker.
>
>
>
> I have searched archival of the list, but I failed to locate the
> information that can completely solve my problem. So, I am wondering
> whether any colleagues here could share with me any information about this.
> I would be grateful if you can provide me any suggestions or references.
> Many thanks in advance!
>
>
>
> Best,
>
> Chuding
> ___
> 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

[Szabolcs Horvát]

Hello Narges,

This mailing list is planned to be closed soon. I recommend you post on
https://igraph.discourse.group/, which is the replacement for the mailing
list.

Szabolcs

On Mon, 4 May 2020 at 19:54, 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)

[Szabolcs Horvát]

For readers who are not aware, this question was cross-posted (and
answered) at:

https://igraph.discourse.group/t/igraph-for-python3-plotting-using-pycairo-on-mac-oscatalina-10-15-4/162

Please use https://igraph.discourse.group/ for future questions.

On Mon, 30 Mar 2020 at 09:59, serafim loukas  wrote:

> Hi Sid,
>
> Have a look here: https://stackoverflow.com/a/45416251/5025009
>
> Makis
>
> On 30 Mar 2020, at 09:56, Tamas Nepusz  wrote:
>
> import pycairo from
>
>
> ___
> 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] Modularity (Q) based on the Louvain split, unexpected values

[Szabolcs Horvát]

I would recommend posting the question on https://igraph.discourse.group/ as
that forum is meant to replace this mailing list, and provides a nicer
discussion environment.

On Sun, 29 Mar 2020 at 15:08, serafim loukas  wrote:

> Just to add that I just found the *python* version of BCT (the Matlab
> toolbox that I used to benchmark igraph).
>
> Using this:
> https://github.com/aestrivex/bctpy/blob/f9526a693a9af57051762442d8490dcdf2ebf4e3/bct/algorithms/modularity.py#L71,
> again I get approx. 0.1466 that matches the Matlab based results but is far
> from the python output (Q).
>
> Makis
>
> On 29 Mar 2020, at 14:56, serafim loukas  wrote:
>
> Hi igraph community,
>
>
> I have a graph and I want to estimate the modularity (Q) based on the
> Louvain split of the graph.
>
> In python I used igraph and to compare, I also estimated Q in Matlab.
> Based on igraph, the Q is negative (weird) whereas the Q based on the
> Matlab estimation is possitive.
>
> I would expect differences in the values but not by so far (+ shows
> modularity, - shows anti-modularity).
> Any idea why this happens?
>
> Makis
>
> ———
>
> My code and data:
>
>
> PYTHON
>
> ```
> import numpy as np
> import scipy.io
> from igraph import *
>
> A = scipy.io.loadmat('A.mat')['A']
>
> graph = Graph.Weighted_Adjacency(A.tolist(), mode=ADJ_UNDIRECTED,
> attr="weight", loops=False)
> Louvain = graph.community_multilevel(weights=graph.es['weight'],
> return_levels=False)
> Q = graph.modularity(Louvain)
> print(Q)
>
> -0.001847596203445795
> ```
>
>
> MATLAB (https://sites.google.com/site/bctnet/measures/list)
> using community_louvain.m: Louvain community detection algorithm
>
> ```
> clear all
> load('A.mat')
> [M,Q]=community_louvain(A);
>
> Q =
>
>0.1466
> ```
>
> ___
> 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] question re: sample_traits_callaway()

[Szabolcs Horvát]

Hello Jeff,

All of igraph's source code is available at https://github.com/igraph/ .
There is a link at the top of https://igraph.org/

Contributions of new functionality or enhancements are very welcome, but be
warned that doing so is not a trivial undertaking. If you'd like to work on
this, we are happy to give guidance. Probably the best place to discuss it
is the newly launched forum: https://igraph.discourse.group/

Best regards,
Szabolcs

On Wed, 29 Jan 2020 at 18:26, Jeff Hanes  wrote:

> Tamas,
>
> Thank you for the response:  I suspected that might be the case.
>
> If I want to customize the graph generator, how do I get access to the
> underlying C code?
>
> thanks,
> Jeff
>
>
> Date: Mon, 27 Jan 2020 23:08:00 +0100
> From: Tamas Nepusz 
> To: Help for igraph users 
> Subject: Re: [igraph] question re: sample_traits_callaway()
> Message-ID:
>  mpaoydbjukqzu+awy_ap182rq...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> >
> >
> > 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
>
___
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

[Szabolcs Horvát]

Hello Brenn,

All functions in igraph which are based on the concept of paths /
paths lengths / shortest paths interpret weights as distances. The
length of a path is the sum of the edge weights along the path.

On Mon, 14 Oct 2019 at 17:57, Brenn Poppe  wrote:
>
> Dear all,
>
> For my masterthesis I'm constructing and analyzing animal social networks. In 
> these networks individual Great Tits (Parus major) and Blue Tits (Cyanistes 
> caeruleus) are represented by nodes. I construct a set of daily networks that 
> are undirected and weighted starting from adjacency matrices. The values in 
> these adjacency matrices are used as the edge weights of the links between 
> nodes in my graphs. These values represent an interaction strength: the more 
> 2 individuals interacted (co-occurring on garden feeders) the higher their 
> interaction strength and the higher the edge weight between these individuals 
> in the graph.
>
> I use igraph in R to construct and analyse these daily networks.
>
> Now for each of these daily networks I calculate (among others) 2 metrics 
> namely: the diameter (graph-level) and the betweenness centrality 
> (node-level). Because I have weighted networks I also use the weights when 
> implementing these functions.
>
> Now based on my interpretation of the edge weights, being interaction 
> strengths, I would expect the diameter to be the path that has the lowest sum 
> of edge weights and thus a path along which all interactions are weak.

That is not how "diameter" is defined in graph theory. The diameter is
the length of the longest shortest-path.

Of course we can talk about the shortest shortest path too, regardless
of what we call it. However, you may not find that to be a useful
concept. THe shortest shortest path consists of the edge with the
smallest weight.

> Assuming that for example information travels slower along a path with weak 
> connections opposed to a path with strong connections. However I have noticed 
> that the calculated diameter actually gives the 'opposite' result being the 
> path with the highest sum of edge weights and thus a path with overall strong 
> connections. This is a path that I would consider to be the shortest rather 
> than the longest. In some occassions the diameter is exactly the same as the 
> highest edge weight in a network. It looks as if the edge weights are 
> interpreted as costs/distances/resistance.
>
> Because of this 'problem' with the calculation of diameter according to my 
> interpretation I also have similar concerns about the calculation of weighted 
> betweenness. I have seen this issue (a confusing interpretation of edge 
> weights by igraph) pop up several times on this mailing list.
>
> Although this issue has popped up several times, I have not found a clear 
> solution in the answers as to what I should do with my data or my script to 
> get diameter and betweenness to be interpretable according to my 
> interpretation of the edge weights:

This is because there is no general solution to this problem.
Betweenness centrality is just one of many graph metrics that can
characterize each vertex (or each edge) in a graph. It is a useful
concept for some applications, but not for others.  It is up to you to
decide whether betweenness carries anything meaningful in your
network. It is true that the interpretation is not trivial,
and—sadly—not very well-founded in many published papers. Many people
will simply transform the weights with a monotonically decreasing
functions (e.g. taking the inverse), then compute the betweenness with
these new weights. Does this make any sense? In my opinion, this is
often debatable. The results you get will depend on the specific
monotonic transformation you chose. In some applications, such as when
agents are moving along the shortest paths in the network (think e.g.
travelling on roads), betweenness can be connected to an actual
physical process happening on the network. In a social network where
people pass information to each other, there is again a way to connect
it to something physical (sociological?) Is there anything tangible
(ethological?) you can connect it to? I don't know.

It is good to note that if the "strength of connection" in your
network represents the number of interactions between the bird, then
you can also use a multigraph. The number of edges is the number of
interactions. The betweenness computed in this network is yet another
different thing.

>
> Do I have to use a different function or do I have to specify certain 
> arguments in the functions diameter() and betweenness()
> Or can I simple take the inverse (1/edge weight) of the edge weights before 
> calling the specified functions?
> Or.
>
> Note: all the edge weights range between 0 and 1.
>
> Thanks in advance,
>
> Brenn Poppe
> Masterstudent MSc in Biology (University of Ghent)
>
> ___
> igraph-help mailing list
> igraph-help@nongnu.org
> 

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

[Szabolcs Horvát]

On Mon, 7 Oct 2019 at 12:05, Frederico Mestre 
wrote:

> Hello everybody,
>
> I'm using  igraph to generate scale free graphs (I need to generate scale
> free graphs with a given number of nodes and links),
>

A "scale-free network" is one that has a power-law degree distribution.


> but I have one question:
>
> Which is the difference between these two functions?
>
> static.power.law.game
> barabasi.game
>
> Which would be best for this purpose?
>

Most of the models you find, such as preferential attachment, are based on
a *process* that creates the network, and not on the *kind of network*
(i.e. scale-free) that we want to create. Any given process might create
networks which are scale-free, but it may not be able to create *all*
scale-free networks with a given exponent, or it might create some of them
with much lower probability than others.  For example, the preferential
attachment model will only create connected networks.  Most networks with
the same degrees will not be connected.

Thus you need to think about what you really need.

If you take one such process, and obtain some results networks created by
it, you cannot claim that result for *all* scale-free networks.

To try to cover all such networks, you can try one of two things:

 - Generate one network and rewire it while keeping its degree sequence.
This will sample *approximately uniformly* from the set of graphs with the
same degrees.
 - Use static.power.law.game, which creates graphs where the *expected*
degrees have a power-law distribution (the individual graphs may not).

To sum up, you need to think carefully why you want to do this. As Tamás
said, the specific application will decide what the most reasonable
approach is.


>
> --
> Frederico Mestre
> ᐧ
> ___
> 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] Floyd-Warshall

[Szabolcs Horvát]

On Fri, 23 Aug 2019 at 10:59, elastica--- via igraph-help <
igraph-help@nongnu.org> wrote:

> Hi
>
> igraph doesn't implement Floyd-Warshall algorithm?
>

It implements the Bellman-Ford and Johnson algorithms, which can be used
for shortest path finding in graphs with negative edge weights.

See here:

https://igraph.org/c/doc/igraph-Structural.html#idm231921766032


>
> ___
> 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

[Szabolcs Horvát]

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

> Dear colleagues,
>
> 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.
>

Can you explain what you mean by "remaining degree of a graph"?


>
> 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] largest independent vertex sets

[Szabolcs Horvát]

I created a new issue with a feature request to solve this:

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

On Wed, 17 Jul 2019 at 15:46,  wrote:
>
> Hi,
>
>
>
> I am trying to find out a largest independent vertex set for a graph that 
> represents a randomly generated crystal lattice, then I came across igraph. 
> My program is written with Python. I managed to get a list of the largest 
> independent vertex sets using the largest_independent_vertex_sets() method of 
> the Graph class. However, that’s not quite what I want. All I need is just a 
> single largest independent vertex set, instead of a list of all 
> possibilities. There are thousands of vertices in my graph, therefore it 
> takes a very long time to calculate the complete list. I know it is a 
> NP-complete problem, but I think generating just one such set instead of 
> generating the complete list and then taking one from it would cut down the 
> runtime significantly. I looked at the source code written in C but was kind 
> of getting lost there. I am not sure whether this can be easily done by 
> modifying the source code. Could anybody help me with this issue?
>
>
>
> Best regards,
>
>
>
> Yu Xiang
>
> PhD Candidate
>
> Dept. of Physics, Applied Physics & Astronomy
>
> Rensselaer Polytechnic Institute
>
> Jonsson-Rowland Science Center 2W19
>
> Email: xia...@rpi.edu
>
> Phone: (518) 833-4710
>
>
>
> ___
> 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] largest independent vertex sets

[Szabolcs Horvát]

Hello Yu,

How big is your lattice? Is it reasonable to keep the complement graph
in memory?

Szabolcs

On Wed, 17 Jul 2019 at 15:46,  wrote:
>
> Hi,
>
>
>
> I am trying to find out a largest independent vertex set for a graph that 
> represents a randomly generated crystal lattice, then I came across igraph. 
> My program is written with Python. I managed to get a list of the largest 
> independent vertex sets using the largest_independent_vertex_sets() method of 
> the Graph class. However, that’s not quite what I want. All I need is just a 
> single largest independent vertex set, instead of a list of all 
> possibilities. There are thousands of vertices in my graph, therefore it 
> takes a very long time to calculate the complete list. I know it is a 
> NP-complete problem, but I think generating just one such set instead of 
> generating the complete list and then taking one from it would cut down the 
> runtime significantly. I looked at the source code written in C but was kind 
> of getting lost there. I am not sure whether this can be easily done by 
> modifying the source code. Could anybody help me with this issue?
>
>
>
> Best regards,
>
>
>
> Yu Xiang
>
> PhD Candidate
>
> Dept. of Physics, Applied Physics & Astronomy
>
> Rensselaer Polytechnic Institute
>
> Jonsson-Rowland Science Center 2W19
>
> Email: xia...@rpi.edu
>
> Phone: (518) 833-4710
>
>
>
> ___
> 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 C library installation failure macOS

[Szabolcs Horvát]

You might also want to try the latest development version from GitHub,
which should be free of this problem.

On Wed, 19 Jun 2019 at 13:01, Tamas Nepusz  wrote:

> 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
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] igraph on HPC

[Szabolcs Horvát]

On Sat, 15 Jun 2019 at 10:05, Szabolcs Horvát  wrote:

> Take a look at the installation instructions here:
>
> https://igraph.org/c/
>
> You can see the available options to the configure script and their
> default values with
>
> ./configure
>

This should, of course, have been

./configure --help

It will list the available options.


>
> The installation location is controlled by the --prefix option. I believe
> the default is /usr/local, which you won't be able to write to without
> administrative access. If you are working on a HPC cluster, I suggest you
> install the library somewhere within your home directory. For example, to
> install into ~/local, use
>
> ./configure --prefix=$HOME/local
>
>
>
> On Sat, 15 Jun 2019 at 00:18, Peng He  wrote:
>
>> Dear igraph users,
>>
>> I want to use igraph C library on high-performance computing
>> (HPC)clusters (Linux), but have no idea of how to install it. Does anyone
>> has experience about this? If any, could you please give me some hints?
>> Thank you in advance.
>>
>> Best
>> 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] igraph on HPC

[Szabolcs Horvát]

Take a look at the installation instructions here:

https://igraph.org/c/

You can see the available options to the configure script and their default
values with

./configure

The installation location is controlled by the --prefix option. I believe
the default is /usr/local, which you won't be able to write to without
administrative access. If you are working on a HPC cluster, I suggest you
install the library somewhere within your home directory. For example, to
install into ~/local, use

./configure --prefix=$HOME/local



On Sat, 15 Jun 2019 at 00:18, Peng He  wrote:

> Dear igraph users,
>
> I want to use igraph C library on high-performance computing (HPC)clusters
> (Linux), but have no idea of how to install it. Does anyone has experience
> about this? If any, could you please give me some hints? Thank you in
> advance.
>
> Best
> 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] Fwd: Package ‘igraph’ - Methods degree and betweness

[Szabolcs Horvát]

Can you share the data?

On Tue, 4 Jun 2019 at 15:57, Alexandre Souza 
wrote:

>
> Hello Gabor,
> How are you!?
>
> I would like to understand with you about methods degree e betweness.
>
> I am compare this methods with sna methods for the same graph and the
> result are differents.
>
> This is my single graph:
>
> rede4 <- read.table("c:/temp/Exemplo Rede_4_vertices.csv",header=TRUE,sep
> = ";", dec=",")
> # Adaptando o data.frame rede para que possa servir para a montagem da rede
> grede4 <- rede4[,2:5]
> rownames(grede4) <- rede4[,1]
> rownames(grede4)
>
> Look my results about SNA:
>
> > sna::degree(grede4,gmode="graph",cmode="indegree")
> [1] 2 2 2 2
> > sna::closeness(grede4,gmode="graph")
> [1] 0.75 0.75 0.75 0.75
> > sna::betweenness(grede4,gmode="graph")
> [1] 0.5 0.5 0.5 0.5
>
> Look my results about igraph:
>
> library("igraph")
> #transformando  one-mode network matrix into an igraph object,
> a = as.matrix(as.data.frame(lapply(grede4, as.numeric)))
> a
> net1 <- graph_from_adjacency_matrix(a, mode="undirected", weighted=NULL)
> net1
>
> > degree(net1, mode="out")
> A B C D
> 4 4 4 4
> > closeness(net1, mode="all")
>ABCD
> 0.25 0.25 0.25 0.25
> > betweenness(net1)
>   A   B   C   D
> 0.5 0.5 0.5 0.5
>
> Can you help-me understand why the results about degree is different?
>
> grown up my graph, another differences show on.
>
> thanks very much.
>
> best regards.
>
> Att.
>
>
>
>
> 
>  Livre
> de vírus. www.avg.com
> .
> <#m_4287662025395222475_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> 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

[Szabolcs Horvát]

See here for connected components:
https://igraph.org/python/doc/igraph.Graph-class.html#clusters

On Fri, 29 Mar 2019 at 18:02, Gokce Dilek  wrote:

> Thank you for your reply! Also, how can we get the connected components of
> a graph? Should we do it with vertex clustering?
>
> On Fri, 29 Mar 2019 at 08:06, Tamas Nepusz  wrote:
>
>> 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
>>
> ___
> 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?

[Szabolcs Horvát]

On Tue, 8 Jan 2019 at 14:34, Victor Snesarev  wrote:
>
> Out of curiosity... There is an extensive set of functions in igraph dealing 
> with paths but not with circuits. Why is that? Is it simply because circuits 
> are not very useful for problems people use igraph to solve?
>

You are very welcome to contribute implementations if you are
interested in this topic. I think it is a good fit for igraph.

Personally, I am happy to help you (or anyone else) get started if you
are not yet familiar with the code base.

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

Re: [igraph] Efficient way to predict a network outage after a node deleting

[Szabolcs Horvát]

There are functions to compute minimum or minimal vertex separators.
Separators are vertex sets whose removal disconnects the graph (or
increases the number of connected components).  You may find these
functions useful.

https://igraph.org/r/doc/min_st_separators.html
https://igraph.org/r/doc/min_separators.html



On Sat, 29 Dec 2018 at 11:47, Вадим Семенов 
wrote:

> Dear igraph administrators,
>
> recently, I started to use the igraph and just fallen in love with this
> tool. This is what I'm looking for =) Thank's for your job.
> I'm writing to you for asking for advice about the most efficient way to
> calculate how many nodes in the graph lost their connection with other
> nodes if we delete some node. Just for now I have only brute force
> solution: make a routine through all nodes and check g.are_connected(node1,
> node2), then we delete some node and repeat the routine once again in order
> to check node connection once again. I realize that my solution is
> dramatically inefficient. Probably you could help me with a better approach.
> I'm looking forward to your reply.
>
> --
> 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] Error in stCuts function

[Szabolcs Horvát]

Hello Jorden,

I believe this is a bug in the igraph C core.

I have reported this bug on May 28.

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

Szabolcs

On Tue, 13 Nov 2018 at 09:57, Joren Kreuzberg <
j.a.kreuzb...@student.utwente.nl> wrote:

> Dear Igraph mailinglist members,
>
> The following error occurs when using the stCuts function: "Error in
> stCuts(g1, source = V[7], target = V[8]) : At st-cuts.c:415 : Invalid root
> vertex id for dominator tree, Invalid value".
>
> For the matrix I use in graph.adjacency and the code I use before running
> the stCuts function, please observe the stack.exchange post or the code
> below.
>
> https://stackoverflow.com/questions/53264231/why-does-the-error-at-st-cuts-c415-invalid-root-vertex-id-for-dominator-tree
>
> I hope someone can help me.
>
> Best regards,
> Jorden
>
> [1,] 0 0 0 0 0 0 0 0 0  0  0  0  0
>  [2,] 0 0 0 1 0 0 0 0 0  0  0  0  0
>  [3,] 0 0 0 0 0 0 0 0 0  0  0  0  0
>  [4,] 0 1 0 0 0 0 0 0 0  0  0  0  0
>  [5,] 0 0 0 0 0 1 0 0 1  1  1  0  0
>  [6,] 0 0 0 0 1 0 1 0 0  0  0  0  0
>  [7,] 0 0 0 0 0 1 0 0 0  0  1  0  0
>  [8,] 0 0 0 0 0 0 0 0 0  1  1  1  0
>  [9,] 0 0 0 0 1 0 0 0 0  1  0  0  0[10,] 0 0 0 0 1 0 0 1 1  0  1  0  0[11,] 0 
> 0 0 0 1 0 1 1 0  1  0  0  0[12,] 0 0 0 0 0 0 0 1 0  0  0  0  0[13,] 0 0 0 0 0 
> 0 0 0 0  0  0  0  0
>
> EdgesGroep <- as.matrix(EdgesGroep)
> colnames(EdgesGroep) <- 1:dim(EdgesGroep)[1]
> g1 <- graph.adjacency(EdgesGroep, mode="directed", weighted=NULL)
> tkplot(g1)
> V <- V(g1)
> E <- get.edgelist(g1)
> mode(E) <- "integer"
> stCuts(g1, source=V[7], target=V[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] average local transitivity

[Szabolcs Horvát]

Actually, I believe that this is a bug.  I reported it a while ago (but I
could not recall this immediately).

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

I do not consider it a bug in the C interface function, as when programming
in C, it is typically the user who is expected to supply valid input (and
it is not the function that is expected to check validity).

But in R it is definitely a bug. A high-level interface should just not
accept invalid input.

On Sat, 27 Oct 2018 at 10:33, Szabolcs Horvát  wrote:

> This happens because this is not a simple graph. It has multi-edges.  The
> "average" computation ignores these, the "local" computation does not. I
> did not verify if the "local" computation gives reasonable results for
> multigraphs, though.
>
> On Sat, 27 Oct 2018 at 09:57, Raigo Aljand  wrote:
>
>> I added to the attachment the graph that gives me these results. It is
>> saved in edgelist format.
>>
>> 27.10.18 10:42 Gábor Csárdi kirjutas:
>> > Please provide a reproducible example.
>> >
>> > Gabor
>> > On Sat, Oct 27, 2018 at 7:13 AM Raigo Aljand  wrote:
>> >> Hello,
>> >>
>> >> I have a simple question. I looked at the archives, but it doesn't seem
>> >> anyone has asked this nor does it seem to be written in the
>> documentation.
>> >>
>> >> Why do these two give me different results?
>> >>
>> >> transitivity(graph, type = "average")
>> >> 0.3772343
>> >> mean(transitivity(graph, type = "local"), na.rm = TRUE))
>> >> 0.2014909
>> >>
>> >> I understand the difference between global and local transitivity and
>> >> what I read from the internet type="average" should give me the average
>> >> local transitivity. Then why does the igraph average give me a
>> different
>> >> result from when I calculate the average with R. What is also strange
>> is
>> >> that type="average" is either no longer or has never been documented in
>> >> the official documentation.
>> >>
>> >> If it helps, my graph is directed, but as I understand it, igraph
>> >> ignores the direction of the edges.
>> >>
>> >> My version of igraph is Ubuntu 18.04 package r-cran-igraph with version
>> >> 1.1.2 and R is from the package r-base with version 3.4.4
>> >>
>> >> Thank you for your 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] average local transitivity

[Szabolcs Horvát]

This happens because this is not a simple graph. It has multi-edges.  The
"average" computation ignores these, the "local" computation does not. I
did not verify if the "local" computation gives reasonable results for
multigraphs, though.

On Sat, 27 Oct 2018 at 09:57, Raigo Aljand  wrote:

> I added to the attachment the graph that gives me these results. It is
> saved in edgelist format.
>
> 27.10.18 10:42 Gábor Csárdi kirjutas:
> > Please provide a reproducible example.
> >
> > Gabor
> > On Sat, Oct 27, 2018 at 7:13 AM Raigo Aljand  wrote:
> >> Hello,
> >>
> >> I have a simple question. I looked at the archives, but it doesn't seem
> >> anyone has asked this nor does it seem to be written in the
> documentation.
> >>
> >> Why do these two give me different results?
> >>
> >> transitivity(graph, type = "average")
> >> 0.3772343
> >> mean(transitivity(graph, type = "local"), na.rm = TRUE))
> >> 0.2014909
> >>
> >> I understand the difference between global and local transitivity and
> >> what I read from the internet type="average" should give me the average
> >> local transitivity. Then why does the igraph average give me a different
> >> result from when I calculate the average with R. What is also strange is
> >> that type="average" is either no longer or has never been documented in
> >> the official documentation.
> >>
> >> If it helps, my graph is directed, but as I understand it, igraph
> >> ignores the direction of the edges.
> >>
> >> My version of igraph is Ubuntu 18.04 package r-cran-igraph with version
> >> 1.1.2 and R is from the package r-base with version 3.4.4
> >>
> >> Thank you for your 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] Motifs in igraph

[Szabolcs Horvát]

You can use subgraph_isomorphisms with the lad method and induced=TRUE

http://igraph.org/r/doc/subgraph_isomorphisms.html

It will tell you where exactly the motif (i.e. induced subgraph)
appears in the graph.
On Fri, 19 Oct 2018 at 01:15, Stuart Kininmonth
 wrote:
>
>
>
> Hi Igraphers’,
>
>
>
> Has anybody developed code in R or python that can find motifs of various 
> configurations (from 3 and 4 node motifs) that also keeps a list of the node 
> identities?
>
> This would then enable me to see the relationship of the node to the other 
> nodes via the shared motifs.
>
>
>
> With thanks
>
>
>
> Stuart
>
>
>
>
>
> Stuart Kininmonth PhD
>
> Deputy Head of School
> Senior Lecturer
>
>   :Coral Reef Ecology and Management
>   :Marine Spatial Planning
>
>   :Marine Geology
> School of Marine Studies
> Faculty of Science, Technology & Environment
> The University of South Pacific
> Laucala Bay Road, Suva, Fiji Islands
> Tel: (+679) 32 32943  Ext.: 32943
>
> stuart.kininmo...@usp.ac.fj
>
> M: +679 8660103
>
>
>
>
>
>
>
>
>
> ___
> 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 union function in igraph

[Szabolcs Horvát]

Hello Fan,

Are you looking for the disjoint_union function?

http://igraph.org/r/doc/disjoint_union.html

Szabolcs

On Wed, 10 Oct 2018 at 03:33, 杨帆  wrote:

> Dear igraph developers,
> I am Fan. I have a question about merging two graphs in igraph when
> using the union function. When I merge two graphs which contain the
> same vertices, there should be some name clashing issues with that.
> But actually the plot just combines vertices from these two graphs and
> remove all the duplicate edges due to the same vertices. I was
> wondering how to deal with that situation and how to avoid the name
> clash. I have attached my output file.  Please be free to take a look
> at that.
> I am looking forward to receiving your reply!
> Best,
> Fan
> ___
> 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] Identifying vertices belonging to fully closed triads in large graph

[Szabolcs Horvát]

I am not familiar with the term "fully closed triad", but I assume it
means a complete directed graph on 3 vertices.

If so, you can first convert the graph to undirected in such a way
that only reciprocal edges are kept (as.undirected() function), then
find all triangles. There are multiple way to do this, e.g.
count_triangles() to find triangle adjacent to each vertex (and thus
find all triangles), or finding cliques of size 3 using cliques() with
min=3 and max=3.

An alternative (and likely slower) way is to use one of the subgraph
finder functions to find the specific 3-vertex subgraph you want.
Check subgraph_isomorphic(), in particular the LAD method. This can be
directly used on the directed graph.

On Tue, 12 Jun 2018 at 22:50, Wagner, Stefan  wrote:
>
> Dear igraph-list,
>
>
>
> I am trying to identify all fully closed triads in large directed graphs as 
> well as the vertices belonging to them.
>
>
>
> I am aware that triad.census provides a count of all fully closed triads. 
> However, I am looking for a way to identify all individual fully closed 
> triads in a graph. Ideally, I get a matrix with 3 columns (for each vertice 
> in a triad) and n lines for the each fully closed triad in my directed graph.
>
>
>
> I found the following solution in 
> https://stackoverflow.com/questions/40597315/igraph-finding-all-subgraphs-of-specified-shape:
>  Generate all possible combinations of 3 vertices and use sna’s 
> triad.classify to identify the fully closed triads within these combinations. 
> However, the number of different vertices in my graphs is too big, to 
> generate all possible combinations using the combn command. (At least, I get 
> an error message when trying.)
>
>
>
> Is there an alternative approach?
>
>
>
> Thanks for your help,
>
>
>
> Stefan
>
>
>
> ___
> 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] Help with drawing a graph

[Szabolcs Horvát]

igraph has many layout algorithms that can be tuned with various
options. Experiment with them, and try the various options.  Have you
looked at e.g. graphopt?

http://igraph.org/r/doc/layout_.html

Otherwise, can you link to the dataset that is visualized with your
link so people have something concrete to go on?
On Mon, 11 Jun 2018 at 15:47, Christopher John
 wrote:
>
> Dear Igraph mailing list
>
>
> I am having problems trying to create a well spaced circular graph similar to 
> the one found here:
>
>
> http://www.maayanlab.net/KEA2/
>
>
> I am using R, currently the closest I can get to the nice clear spacing found 
> on this website is using this code:
>
>
> L <- layout.fruchterman.reingold(net, niter=1)
>
>
> However, there are big white spaces still
>
>
> Any ideas how to solve this?
>
>
> Thanks,
>
>
> Chris
>
> ___
> 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] Calculating total number of paths between two specific nodes

[Szabolcs Horvát]

Your graph is a DAG, so you can use the kth power of the adjacency matrix
to count paths of length k between nodes. Furthermore, since the graph is a
DAG, the adjacency matrix is nilpotent, i.e. some big enough power is zero.

You basically need to compute A + A^2 + A^3 + ..., until the power becomes
zero. This matrix gives you the number of paths between any two points.

On Wed, 16 May 2018 at 23:03, Xu, Yanjie  wrote:

> Dear developers of igraph,
>
>
>
> I am currently using igraph in r to analyse directed acyclic graphs. One
> of my task is calculating number of all possible paths between the “start”
> and “end” nodes. With igraph, I can get a list of all possible paths (e.g.,
> from node 1 to node 81) with the code below:
>
>
>
> >>all_simple_paths(net, 1, 81)
>
>
>
> Then I summarize how many paths (n) we have:
>
>
>
> >>n<-length(all_simple_paths(net, 1, 81))
>
>
>
> This works we my network has around 15 nodes, but we the number of nodes
> increase, it takes days to calculate “n” for a single network. I have
> hundreds of networks waiting for calculation. Do you have an idea whether
> there is a quicker way to get the number of possible paths between two
> specific nodes? Many many thanks!
>
>
>
> Best regards,
>
> Yanjie
>
>
> ___
> 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 Spanning Tree with igraph

[Szabolcs Horvát]

Simply replace each edge weight with its negative, then find a minimum
spanning tree.

On Tue, 15 May 2018 at 15:18, Leonardo Mazzoni 
wrote:

> Dear all,
>
> I am currently doing a part of my PhD project applying the concept of
> Hidalgo et al. (2007) to find product space at a regional level. I have
> a nxn symmetric matrix and I would like to obtain the graphical
> representation (the network), using the technique of Maximum Spanning
> Tree.
> In igraph there is the function Minimum Spanning Tree. Could you please
> suggest me a code in R to use the package igraph to find the Maximum
> Spanning Tree?
>
> thank you in advance for your help!
> all the best
>
> Leonardo
>
>
> ___
> 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] betweenness centrality on weighted networks

[Szabolcs Horvát]

Hello Joice,

I do not think the terminology you are using (cost, strength) is
standard, and it is not clear what you mean.

The concept of betweenness centrality is based on the idea of
(shortest) path length.  In the unweighted case, the length of a path
is simply the number of edges it consists of.  In the weighted case,
it is the sum of the weights of these edges.  This is precisely how
igraph uses edge weights for betweenness calculations.

Betweenness is, roughly speaking, the number of shortest paths passing
through a vertex (or edge).  High edge weights make paths longer, thus
high weight edges are less likely to appear in the paths that are the
shortest.

This has hopefully answered your question.

On 6 April 2018 at 18:06, joice de faria poloni  wrote:
> Dear igraph users,
>
> I'm working with gene correlation networks, where each vertex represents a
> gene and each edge represents an expression correlation among genes.
> In this sense, I was planning to use the igraph package to calculate network
> centralities, specifically betweenness and edge betweenness.
> However,  I  have a question: When I use the command "edge_betweenness" or
> "betweenness", the weight of the edges will be considered as costs or
> strengths? If they are considered as costs, can I use a command to calculate
> betweenness as a strength?
>
> Thank you for your assistance regarding in this matter.
>
>
> ___
> 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] graphs with varying centralization

[Szabolcs Horvát]

It is usually easy enough to create one or a few instances of a graph with
a certain property. E.g., you can make an educated guess about which model
already in igraph will produce a certain property, then vary its
parameters.  Or smoothly interpolate between the adjacency matrices of two
graphs having different values of a property.  E.g. a star graph will have
betweenness centralization of nearly 1, a cycle graph nearly 0.

Will the graphs you obtain this way be representative of most graphs with
the same 'centralization' (or other property) value?  Probably not.  That
will also be the case if you choose more "random looking" graphs as
starting points, such as one from a preferential attachment model and a
random regular graph.  Therein lies the problem with using any arbitrary
graph with a property instead of sampling them uniformly.

On 3 April 2018 at 02:28, John Erwin Banez <jsba...@up.edu.ph> wrote:

> I am trying to test robustness of a method I am trying to develop. Having
> igraphs with varied centrality helps.
>
>
>
> On Mon, Apr 2, 2018 at 5:48 PM, Szabolcs Horvát <szhor...@gmail.com>
> wrote:
>
>> If you want uniform sampling, then this is a research-level problem (not
>> a technical one).  If you don't, I wonder what conclusion you could draw
>> from the results.
>>
>> On 2 April 2018 at 08:10, John Erwin Banez <jsba...@up.edu.ph> wrote:
>>
>>> How do I generate several igraphs with varying graph level
>>> centralization? I am familiar with sample_(...), that variations of
>>> 'sample_' allow me to generate graphs GIVEN a MODELbut not given graph
>>> level centralization.
>>>
>>> I would like to have for example:
>>>
>>> graph_1 <- centralization=.50
>>> graph_2 <- centralization=.30
>>>
>>> .
>>>
>>> .
>>>
>>> .
>>>
>>> graph_n <- centralization=.00
>>>
>>>
>>> --
>>> John Erwin Bañez
>>> Assistant Professor
>>> College of Social Work and Community Development
>>> University of the Philippines, Diliman
>>>
>>> ___
>>> 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
>>
>>
>
>
> --
> John Erwin Bañez
> Assistant Professor
> College of Social Work and Community Development
> University of the Philippines, Diliman
>
> ___
> 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] Sorting vertices by degree with igraph C library

[Szabolcs Horvát]

I do not know.  I believe that the documented ones in igraph are not stable.

Personally, I would just use std::stable_sort() from the C++ standard
library. Is there any reason why you don't want to use that, and want
something from igraph instead?

On 24 March 2018 at 15:48, Vincent Beugnet  wrote:

> Thank you very much !
>
> Last question: is there a stable sort already implemented in igraph ?
>
> ___
> 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] Sorting vertices by degree with igraph C library

[Szabolcs Horvát]

To give a concrete example, you could sort an igraph vector 'vec' using

std::stable_sort(vec.stor_begin, vec.stor_end);

To stick to the documented API (might be a good idea), you can use

std::stable_sort(VECTOR(vec), VECTOR(vec) + igraph_vector_size());

http://en.cppreference.com/w/cpp/algorithm/stable_sort

You don't need to use any other C++ features in your program if you don't
like C++. You can keep it as C.  Compiling as C++ will only impose minor
restrictions.

On 24 March 2018 at 17:20, Szabolcs Horvát <szhor...@gmail.com> wrote:

> I do not know.  I believe that the documented ones in igraph are not
> stable.
>
> Personally, I would just use std::stable_sort() from the C++ standard
> library. Is there any reason why you don't want to use that, and want
> something from igraph instead?
>
> On 24 March 2018 at 15:48, Vincent Beugnet <beugnet.vinc...@free.fr>
> wrote:
>
>> Thank you very much !
>>
>> Last question: is there a stable sort already implemented in igraph ?
>>
>> ___
>> 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] Sorting vertices by degree with igraph C library

[Szabolcs Horvát]

Hello Vincent,

Normally you would have to program this yourself. E.g. you can generate a
vector of increasing integers (vertex indices), write a custom comparison
function that compares v1 and v2 through degrees[v1] and degrees[v2], then
use this to sort the indices (e.g. through the qsort() C standard library
function, or much more easily with std::sort() in C++)

Luckily, this is already done in igraph, though not documented. The
function is  igraph_vector_qsort_ind()  You'll find its description in the
vector.pmt file.

On 22 March 2018 at 20:56, Vincent Beugnet  wrote:

> Hello,
> I'd like to sort all vertices from a graph (undirected) by decreasing
> degree and print their ids with this order. But as the vector in
> igraph_degree is not related with the graph,
>

The degree vector is related with the graph in that the degree of the nth
vertex is the nth entry in the vector.


> I don't know how to get the ordered ids. Can someone help me ?
>
> Thanks
>
> P.S: I'm using the C library
>
> ___
> 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] glpk_not_available

[Szabolcs Horvát]

There is a note for igraph 1.2.1:

https://cran.r-project.org/web/packages/igraph/news.html

"The GLPK library is optional, if it is not available, then the
cluster_optimal() function does not work. Unfortunately we cannot bundle
the GLPK library into igraph on CRAN any more, because CRAN maintainers
forbid the pragmas in its source code."

Gregory: I do not think this refers to Rglpk. The underlying igraph
function is implemented in C (not R!), and relies on an (older) bundled
version of the GLPK C library. The release notes seem to say that this can
no longer be included in build hosted on CRAN.

On 19 March 2018 at 08:41, Harun Pirim  wrote:

> Dear All,
>
> I ran cluster_optimal() function and got the message:
>
> Warning in install.packages :
>   package ‘GLPK’ is not available (for R version 3.4.4)
>
> Any quick fix suggested?
>
> thank you,
>
> harun
> ___
> 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] status of the Viger-Latapy sampling method for graphs with a given degree sequence

[Szabolcs Horvát]

Hello everyone,

I am looking at the various methods available in igraph to *uniformly*
sample random graphs with a given degree sequence.  The obvious candidate
function is  igraph_degree_sequence_game().

http://igraph.org/c/doc/igraph-Generators.html#igraph_degree_sequence_game

This function provides three generation methods:

"SIMPLE" is explained, and it's clear that the sampling is not uniform.
Also, this method allows multigraphs and self-loops.

"SIMPLE_NO_MULTIPLE" is explicitly mentioned as not uniform.

What remains is the Viger-Latapy method. The link here is broken, but it's
easy to google up the original paper, https://arxiv.org/pdf/cs/0502085.pdf,
the abstract of which says:

"We address here the problem of generating random graphs uniformly from the
set of simple connected graphs having a prescribed degree sequence."

While I didn't read the entire paper, the abstract suggests that this
method should sample uniformly from the set of *connected* simple graphs.
However, this does not appear to be the case in a simple test.

Consider the degree sequence (1, 2, 1, 2).  The only two simple graphs with
this degree sequence are:


But the Viger-Latapy method, as implemented in igraph, will generate only
the second one.

Let's look at a more complicated example, the sequence (1, 2, 2, 2, 1).
Here's the list of such graphs (one of which is not connected):


The Viger-Latapy method generates only these:



Within this set, the sampling is indeed uniform, but there are three
connected graphs which are never generated.

*Question:*

Is the Viger-Latapy method known to be flawed, or is there something I'm
missing here?  There doesn't seem to be a peer-reviewed publication about
this.

Szabolcs

*P.S. *A method that does work in practice is generating a single
realization of the degree sequence, then using igraph_rewire() on it. What
is unclear in such situations is how many rewiring steps are necessary to
approximate uniform sampling.
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] R igraph is comiled?

[Szabolcs Horvát]

These clustering methods are implemented in C.  If you are in doubt about a
function, you can check the igraph/C documentation, and see if it is
present there.

http://igraph.org/c/doc/igraph-Community.html#idm470927718656
http://igraph.org/c/doc/igraph-Community.html#idm470920331024

igraph is a C library with interfaces in several higher level languages
(official ones in R and Python, and some other unofficial ones, such as the
one for Mathematica). Most of the functionality you can access through the
official interfaces is implemented in C.

On 2 February 2018 at 09:58, M. Okuda  wrote:

> Dear Sirs/Madams,
>
> I use R igraph, especially the "cluster_spinglass" and "cluster_infomap"
> functions.
> Are these functions compiled or just R scripts?
> To compare the processing speed of these methods with the compiled other
> clustering methods,
> I would like to know what condition R igraph works on.
>
> Truly yours,
>
> M. Okuda
>
>
> ___
> 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] knn computation

[Szabolcs Horvát]

Hello Filippo,

By "parallel edges" I meant more than one edge connecting the same two
graph vertices. The function works only if this never happens.

Szabolcs

On 25 January 2018 at 09:33, Filippo Santi <filippo.sa...@unitn.it> wrote:
> Dear Szabolcs,
>
> Than you for the reply. I will check for these issues you mentioned, even if
> I should have created the network without allowing for self loops. Instead,
> I don't have clear what you mean for "parallel edges connecting the same two
> vertices": is it related with the possibility of having more edge attributes
> in the graph or is it related to the multiplexity of the graph?
>
> Filippo
>
> 2018-01-23 21:10 GMT+01:00 Szabolcs Horvát <szhor...@gmail.com>:
>>
>> Hi Filippo,
>>
>> The message means that your graph has either self-loops (an edge
>> connecting a vertex to itself), or parallel edges connecting the same
>> two vertices. The function does not work on such graphs.  You need to
>> supply a simple graph—take a look at simplify().
>>
>> Also, be aware that knn() does not compute the mean neighbour strength
>> for weighted graphs.  https://github.com/igraph/igraph/issues/987
>>
>> Szabolcs
>>
>> On 23 January 2018 at 19:29, Filippo Santi <filippo.sa...@unitn.it> wrote:
>> > Dear all,
>> >
>> > I am new to R and even more to igraph. I am working on foreign direct
>> > investment network, and I am currently  trying to compute average
>> > nearest
>> > neighbour degree and average nearest neighbour strength, using the knn
>> > function. My code is as following:
>> >
>> > fdi.graph.2003 <- graph_from_data_frame(fdi.edge.2003, directed = T,
>> > vertices = fdi.attr.2003)
>> > ANND <- knn(fdi.graph.2003)
>> >
>> > However, R returns the following error message
>> >
>> > Error in knn(fdi.graph.2003) :
>> > At structural_properties.c:5889 : Average nearest neighbor degree Works
>> > only
>> > with simple graphs, Invalid value
>> >
>> > Do you have any explanation to try to solve this issue? I tried to
>> > compute
>> > it building the graph from a simple binary edgelist too (the above
>> > message
>> > comes from computations based on a weighted network with plenty of edge
>> > attributes, built from a data.frame) but it is not working either.
>> >
>> >
>> > Thanks for any help,
>> >
>> >
>> > Filippo
>> >
>> >
>> >
>> > ___
>> > 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
>
>
>
>
> --
> Filippo Santi
> PhD Candidate in Development Economics
>
>
> ___
> 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] knn computation

[Szabolcs Horvát]

Hi Filippo,

The message means that your graph has either self-loops (an edge
connecting a vertex to itself), or parallel edges connecting the same
two vertices. The function does not work on such graphs.  You need to
supply a simple graph—take a look at simplify().

Also, be aware that knn() does not compute the mean neighbour strength
for weighted graphs.  https://github.com/igraph/igraph/issues/987

Szabolcs

On 23 January 2018 at 19:29, Filippo Santi  wrote:
> Dear all,
>
> I am new to R and even more to igraph. I am working on foreign direct
> investment network, and I am currently  trying to compute average nearest
> neighbour degree and average nearest neighbour strength, using the knn
> function. My code is as following:
>
> fdi.graph.2003 <- graph_from_data_frame(fdi.edge.2003, directed = T,
> vertices = fdi.attr.2003)
> ANND <- knn(fdi.graph.2003)
>
> However, R returns the following error message
>
> Error in knn(fdi.graph.2003) :
> At structural_properties.c:5889 : Average nearest neighbor degree Works only
> with simple graphs, Invalid value
>
> Do you have any explanation to try to solve this issue? I tried to compute
> it building the graph from a simple binary edgelist too (the above message
> comes from computations based on a weighted network with plenty of edge
> attributes, built from a data.frame) but it is not working either.
>
>
> Thanks for any help,
>
>
> Filippo
>
>
>
> ___
> 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] IGraph/M version 0.3.94 is now available (igraph for Mathematica)

[Szabolcs Horvát]

Dear igraph users,

Prerelease 0.3.94 of IGraph/M, igraph's Mathematica interface, is now available.

http://szhorvat.net/mathematica/IGraphM

While this is still a prerelease, I now recommend using it instead of
the stable 0.3.0.

A running list of changes since the 0.3.0 release is available in the
GitHub README:

https://github.com/szhorvat/IGraphM/

There is now a Gitter chatroom for IGraph/M support.

https://gitter.im/IGraphM/Lobby

If you have any feedback, please join the chatroom, or email me directly.

Szabolcs

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

Re: [igraph] Does igraph random_walk function work with weighted networks?

[Szabolcs Horvát]

On 10 November 2017 at 00:47, Olli Pietilainen 
wrote:

> Hello,
> I'm interested in using  random walk function in igraph R package to study
> protein-protein interaction network.
> I was wondering does the random_walk function handle weighted networks to
> modify the transition probability from one vertex to another or are all
> transitions always equally likely to happen?
>

Currently, this function does not support weights (although I noticed that
there was a TODO note in the C source code to add this).

I am mainly commenting to suggest a design improvement, in case weights get
added in the future:

This function should return a set of traversed edges, not a set of
vertices.  It is a fairly common application to do a random walk on
multigraphs (i.e. graphs having parallel edges), and then make some
decision based on how frequently edges were traversed.  Different edges
between the very same vertices may be assigned different effects.



> Thank you so much for your help!
> Best,
> Olli Pietilainen
>
> ___
> 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] How are weights interpreted for igraph_community_edge_betweenness() ?

[Szabolcs Horvát]

Hello igraph users and developers,

How are edge weights interpreted by the
igraph_community_edge_betweenness() function?

http://igraph.org/c/doc/igraph-Community.html#idm470942730032

For betweenness calculations, high weight = long distance (i.e. weak
connection).  Is this the case for this function as well?  It seems to
be based on the centralities it returns.

But for modularity calculations (which are invoked from within this
function), high weight = strong connection.

Is there a mismatch (and therefore a bug) in this function?

Szabolcs Horvát

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

[igraph] igraph for Mathematica: IGraph/M 0.3.92 released

[Szabolcs Horvát]

Dear igraph users,

IGraph/M version 0.3.92, the igraph interface for Mathematica / Wolfram
Language, is now released.

https://github.com/szhorvat/IGraphM/releases
http://szhorvat.net/mathematica/IGraphM

If you use Mathematica 11.2, please do upgrade to this release for full
compatibility.

While it is marked as a prerelease, at this point I recommend you use this
version over 0.3.0. It is marked as such not for reasons of stability, but
because not all features planned for 0.4 are ready yet.

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

Re: [igraph] leading.eigenvector.community function

[Szabolcs Horvát]

On 25 May 2017 at 19:43, Edmund Hunt  wrote:
> Hi Gabor,
>
> Thanks for your reply.
>
> Here are 4 different commands and their result, I guess I am just a bit
> confused how they relate to each other.
>
> The first two are using the cluster_leading_eigen alone, the second two use
> that command to find the communities and then the modularity function to get
> the modularity value out of it
>
> Would I be right in understanding that cluster_leading_eigen only uses the
> weights argument after the communities have been found - but then why does
> it return the same value below for the first two commands - and why is it
> different to the third command
>
> Thanks
>
>> cluster_leading_eigen(net, weights = E(net)$weight)
> IGRAPH clustering leading eigenvector, groups: 2, mod: 0.055
> + groups:
>   $`1`
>   [1] "YV" "B"  "P"
>
>
>
>   $`2`
>   [1] "DG" "V"
>
>
>> cluster_leading_eigen(net, weights = NULL)
> IGRAPH clustering leading eigenvector, groups: 2, mod: 0.055
> + groups:
>   $`1`
>   [1] "YV" "B"  "P"
>
>
>
>   $`2`
>   [1] "DG" "V"


According to the documentation, you need to supply weights=NA, and not
weights=NULL, to ignore any existing weight values in the graph.

>
>> modularity(net,membership(cluster_leading_eigen(net, weights =
>> E(net)$weight)),weights=NULL)
> [1] 0.03061224
>
>> modularity(net,membership(cluster_leading_eigen(net, weights =
>> E(net)$weight)),weights=E(net)$weight)
> [1] 0.0546875
>
>
>
> On 25 May 2017, at 06:51, Gábor Csárdi  wrote:
>
> IIRC the original algorithm can be extended easily to take weights
> into account.
>
> If you think the igraph is not doing that (and the docs say that it
> would), can you please provide a small example that gives you the same
> results with or without (large enough) weights? Thanks.
>
> Gabor
>
> On Wed, May 24, 2017 at 10:11 AM, Edmund Hunt  wrote:
>
> Hello,
>
> I have a question/comment about the leading.eigenvector.community function
> in igraph
>
> It has an argument for weights, but this seems to make no difference to the
> calculated clusters/resulting modularity
>
> Indeed I don’t think Newman’s algorithm takes edge weights into account?
>
> Is it the case that the weights are only used after the community detection
> has taken place, to calculate a modularity value? Is it appropriate to use
> the weights to calculate modularity, can anyone advise me what is the
> ‘right’ thing to do with a weighted, undirected network - is it definitely
> to use the weights in the modularity calculation, or is there a free choice
>
> Perhaps these issues could be made clearer in the function help
>
> Thanks
>
> ___
> 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] igraph for Mathematica: IGraph/M prerelease available

[Szabolcs Horvát]

Dear igraph users,

Prerelease binaries are now available for IGraph/M, the Mathematica
interface for igraph.

http://szhorvat.net/mathematica/IGraphM

In addition to the usual improvements, this release contains many
utility functions for handling weighted graphs and graph properties,
and easier graph styling.

If you find any problems or have any suggestions, please let me know,
so I can deal with them before the final release.

Platforms supported by this release: Windows 64-bit, OS X 10.9 or
later, Linux 64-bit, Raspberry Pi.

Summary of changes since version 0.3.0:


- New deterministic graph generators: IGKautzGraph, IGKaryTree,
IGCompleteGraph, IGCompleteAcyclicGraph, IGDeBruijnGraph,
IGChordalRing, IGEmptyGraph.
- New random graph generators: IGWattsStrogatzGame,
IGCallawayTraitsGame, IGEstablishmentGame.
- Other new functions: IGVertexTransitiveQ, IGEdgeTransitiveQ,
IGSymmetricQ, IGMinimalSeparators, IGSpanningTree.
- Renamed IGMinSeparators to IGMinimumSeparators.
- New utility functions:
   * Weighted graphs: IGUnweighted, IGWeightedAdjacencyGraph,
IGVertexWeightedQ, IGEdgeWeightedQ, IGVertexStrength,
IGVertexInStrength, IGVertexOutStrength.
   * Easier property handling and graph styling:  IGVertexProp,
IGEdgeProp, IGVertexMap, IGEdgeMap, IGVertexPropertyList,
IGEdgePropertyList.
   * Other: IGNullGraphQ, IGSimpleGraph.
- Bug fixes, polish, and documentation improvements.

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

[igraph] confused about vector pointer memory management

[Szabolcs Horvát]

Hello,

I am a bit confused about the correct usage of these functions:

igraph_vector_ptr_destroy_all
igraph_vector_ptr_free_all
igraph_vector_ptr_clear
IGRAPH_VECTOR_PTR_SET_ITEM_DESTRUCTOR

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.

It seems to me that igraph_vector_ptr_clear() should either not call
element destructors at all, or it should both free and destroy
elements, like igraph_vector_ptr_destroy_all() does.

Here's why.

Consider the following situation:

igraph_vector_ptr_t res;
igraph_vector_ptr_init(, 0);

IGRAPH_VECTOR_PTR_SET_ITEM_DESTRUCTOR(, igraph_vector_destroy);

This data structure is essentially a vector of vectors.  There is an
element destructor set.

Now suppose that we add some elements to this vector_ptr, e.g. by
igraph_vector_ptr_push_back().  To add an element, which will be a
vector, first we need to allocate memory for it (malloc), then we need
to initialize it using igraph_vector_init().

To clear up this vector of vectors, we need to do the reverse:

Destroy each element using igraph_vector_destroy(), then free all of
them using free(), then finally deallocate the memory used by the
vector_ptr.

Calling igraph_vector_ptr_destroy_all() does exactly this: it calls
element destructors, frees elements, and destroys the vector_ptr.

Calling igraph_vector_ptr_free_all()  calls element destructors and
frees all elements, but does not resize or free the vector_ptr.

Calling igraph_vector_ptr_clear() calls element destructors and
resizes the vector_ptr to length 0. BUT IT DOES NOT FREE ANY ELEMENTS.
This is stated in the documentation.

Given that the vector_ptr is already resized to 0, *conceptually* it
is empty.  How can I then free the elements manually? I do not have
access to them anymore.

Should I free the elements BEFORE using igraph_vector_ptr_clear()?  I
can do that.  But then I need to destroy the elements first with
igraph_vector_destroy(), and only use free() afterwards.  Now when I
call igraph_vector_ptr_clear(), then it will try to free the elements
a second time because there is an item destructor set.

So there seems to be no good way to use igraph_vector_ptr_clear().

 -  If I do free() manually in advance, then I am forced to also
destroy elements manually.  In this case igraph_vector_ptr_clear()
would cause a double destruction.

 - If I do not  do free(), then I lose access to the elements to be
free()d after igraph_vector_ptr_clear() has run.

What is the correct usage of this function then?

Szabolcs

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

Re: [igraph] what does the knn() function do with weighted graphs?

[Szabolcs Horvát]

OK, after looking at the source code I see what is being calculated:

Instead of dividing the sum of neighbour strengths by the number of
neighbours, it is divided by the strength of the current node.

Thus we get (3+5)/4 = 2, (4+5)/3 = 3 and (4+3)/5 = 1.4.

That's fine, but I think that this is not at all clear from either the
documentation (C or R) or the name of the function.  This quantity
isn't really an average.  Perhaps the documentation should be
improved.

On 25 April 2017 at 20:32, Szabolcs Horvát <szhor...@gmail.com> wrote:
> Hello,
>
> I am having some trouble understanding what the
> igraph_avg_nearest_neighbor_degree() function does with weights.  This
> function is called knn() in R.
>
> I thought that it simply computed the average strengths of a vertex's
> neighbours. But this does not seem to be the case.
>
> Let's make a 3-ring with edge weights 1,2,3:
>
> g<-make_ring(3)
> E(g)$weight <- c(1,2,3)
>
> The strengths are 4, 3, 5, as I expected:
>
>> strength(g)
> [1] 4 3 5
>
> knn() gives the following result:
>
>> knn(g)
> $knn
> [1] 2.0 3.0 1.4
>
> I would have expected this to be (3+5)/2 = 4, (4+5)/2 = 4.5, and
> (4+3)/2 = 3.5 for the three vertices, as each of them have two
> neighbours.
>
> What am I misunderstanding?
>
> The documentation says,
>
> "Calculate the average nearest neighbor degree of the given vertices"
>
> and
>
> "If the graph has a weight edge attribute, then this is used by
> default. If this argument is given, then vertex strength (see
> strength) is used instead of vertex degree."
>
> Szabolcs

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

[igraph] what does the knn() function do with weighted graphs?

[Szabolcs Horvát]

Hello,

I am having some trouble understanding what the
igraph_avg_nearest_neighbor_degree() function does with weights.  This
function is called knn() in R.

I thought that it simply computed the average strengths of a vertex's
neighbours. But this does not seem to be the case.

Let's make a 3-ring with edge weights 1,2,3:

g<-make_ring(3)
E(g)$weight <- c(1,2,3)

The strengths are 4, 3, 5, as I expected:

> strength(g)
[1] 4 3 5

knn() gives the following result:

> knn(g)
$knn
[1] 2.0 3.0 1.4

I would have expected this to be (3+5)/2 = 4, (4+5)/2 = 4.5, and
(4+3)/2 = 3.5 for the three vertices, as each of them have two
neighbours.

What am I misunderstanding?

The documentation says,

"Calculate the average nearest neighbor degree of the given vertices"

and

"If the graph has a weight edge attribute, then this is used by
default. If this argument is given, then vertex strength (see
strength) is used instead of vertex degree."

Szabolcs

___
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

[Szabolcs Horvát]

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

Re: [igraph] Best function to return the size of the maximum clique expediently

[Szabolcs Horvát]

The good news is that the development version of igraph C core already
incorporates the Cliquer library you mentioned, and therefore it became
much faster at clique finding.

The currently released R and Python interfaces do not include this change
yet, but I assume it will be in their next release.

The present release of the Mathematica interface does include it as the
IGCliqueNumber function (http://szhorvat.net/mathematica/IGraphM)

You can also you the development version of the C interface from GitHub,
but that would give little advantage over just using Cliquer directly.

On 12 April 2017 at 16:43, Therese Donovan  wrote:

> Hello. First of all, thank you for producing igraph.   I am new to igraph
> and have been working with a colleague who uses the program, cliquer, to
> find the maximum clique size of a given graph.  Given a set of edges in a
> graph, I have been trying to use the clique_num() function in igraph to
> return the size of the maximum clique.  This is the only output needed –
> the number of points -- we do not need to store all possible cliques.
> Cliquer can do this very quickly using a branch and bound algorithm
> developed by Patric Östergård.  Is there a more appropriate function than
> clique_num() that can return the number of points in a clique that is
> maximal?
>
>
>
> Thank you for your consideration.
>
>
>
>
>
> ___
> 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] looking for cool examples of using igraph

[Szabolcs Horvát]

Hi everyone,

I am looking for "cool" examples to show off the capabilities of
igraph, especially to people who are not deeply familiar with graph
theory.  I am in particular looking for examples that utilize the more
unique features of igraph rather than standard stuff that all graph
handling packages have: coloured graph isomorphism, subgraph finding
(motifs, LAD), community finding (igraph excels here), feedback arc
set, etc.

The best examples would be problems that don't look like graph theory
on the surface yet can be mapped to the kinds of graph-related
problems for which igraph already has a solution.

One example that I am going to use is mapping polyomino tiling into
clique finding.

But generally anything that has the potential to look stunning with
relatively little explanation is useful.  Visualizations of polynomios
look stunning and the tiling problem can be explained in a minute to
anyone without much of a math background.

Szabolcs

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

Re: [igraph] vertex_comb=NULL in contract_vertices() – is this okay?

[Szabolcs Horvát]

I should have looked at the code more carefully.

I appears that:

 1. The original graph is destroyed and replaced with the new one.
 2. vertex_comb is checked for being NULL. In that case the attribute
handling code is skipped.

On 19 September 2016 at 15:23, Szabolcs Horvát <szhor...@gmail.com> wrote:
> Actually I don't fully understand this function.
>
> The signature is:
>
> int igraph_contract_vertices(igraph_t *graph,
> const igraph_vector_t *mapping,
> const igraph_attribute_combination_t *vertex_comb);
>
> 'graph' is the input graph.  Where is the new graph returned?
>
> On 19 September 2016 at 15:17, Szabolcs Horvát <szhor...@gmail.com> wrote:
>> Hello everyone,
>>
>> Quick question about contract_vertices():
>>
>> http://igraph.org/c/doc/igraph-Structural.html#igraph_contract_vertices
>>
>> I don't have attributes.  Can I just pass vertex_comb=NULL?
>>
>> Szabolcs

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

[igraph] vertex_comb=NULL in contract_vertices() – is this okay?

[Szabolcs Horvát]

Hello everyone,

Quick question about contract_vertices():

http://igraph.org/c/doc/igraph-Structural.html#igraph_contract_vertices

I don't have attributes.  Can I just pass vertex_comb=NULL?

Szabolcs

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

Re: [igraph] making sense of is_separator()

[Szabolcs Horvát]

It would seem that a single node graph is not considered connected by this
function.  However, igraph_is_connected does consider a single-node graph
connected (imo correctly), so this would be an inconsistency.

On 31 August 2016 at 16:12, Szabolcs Horvát <szhor...@gmail.com> wrote:

> Hello,
>
> What is the reasoning for the following behaviours of the is_separator()
> function?
>
> http://igraph.org/c/doc/igraph-Separators.html#igraph_is_separator
>
> This makes sense to me:
>
> graph: 1 - 2 - 3
> vertex set: {2}
> result: true
>
> Removing 2 does disconnect the graph.
>
> graph: 1 - 2 - 3
> vertex set: {3}
> result: false
>
> Removing 3 doesn't.
>
> graph: 1 - 2 - 3 - 4
> vertex set: {1, 4}
> result: false
>
> Removing 1 and 4 doesn't.
>
> graph: 1 - 2
> vertex set: {}
> result: false
>
> Removing nothing does not disconnect it.
>
> graph: 1, 2  (disconnected)
> vertex set: {}
> result: true
>
> Makes sense because the graph was already disconnected
>
>
> But I am puzzled by these:
>
> graph: 1 - 2 - 3
> vertex set: {1,3}
> result: true
>
> graph: 1 - 2
> vertex set: {1}
> result: true
>
> Removing these does not disconnect the graph, it merely leaves a 1-node
> graph behind.
>
> Why is the result then true?
>
>
> Szabolcs
>
>
>
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

[igraph] making sense of is_separator()

[Szabolcs Horvát]

Hello,

What is the reasoning for the following behaviours of the is_separator()
function?

http://igraph.org/c/doc/igraph-Separators.html#igraph_is_separator

This makes sense to me:

graph: 1 - 2 - 3
vertex set: {2}
result: true

Removing 2 does disconnect the graph.

graph: 1 - 2 - 3
vertex set: {3}
result: false

Removing 3 doesn't.

graph: 1 - 2 - 3 - 4
vertex set: {1, 4}
result: false

Removing 1 and 4 doesn't.

graph: 1 - 2
vertex set: {}
result: false

Removing nothing does not disconnect it.

graph: 1, 2  (disconnected)
vertex set: {}
result: true

Makes sense because the graph was already disconnected


But I am puzzled by these:

graph: 1 - 2 - 3
vertex set: {1,3}
result: true

graph: 1 - 2
vertex set: {1}
result: true

Removing these does not disconnect the graph, it merely leaves a 1-node
graph behind.

Why is the result then true?


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

Re: [igraph] Random graphs with controllable community structure?

[Szabolcs Horvát]

I think it's this one:

http://igraph.org/python/doc/igraph.GraphBase-class.html#SBM

I'm not so familiar with the R/Python interfaces ...  I mostly use the C
interface to develop the Mathematica one <
https://github.com/szhorvat/IGraphM>

On 10 August 2016 at 22:37, Nick Eubank <nickeub...@gmail.com> wrote:

> Thanks! I see it in R-igraph -- do you know if it's also in python-igraph?
> Can't seem to find...
>
> On Wed, Aug 10, 2016 at 1:34 PM Szabolcs Horvát <szhor...@gmail.com>
> wrote:
>
>> The stochastic block model is implemented in graph.
>>
>> On 10 August 2016 at 22:31, Nick Eubank <nickeub...@gmail.com> wrote:
>>
>>> Hi All,
>>>
>>> Are there any random graph models that have parameterized community
>>> structure (something that'd show up in a community detection algorithm like
>>> CPM?). Seems most models don't generate any consistent community structure
>>> at relatively global scales.
>>>
>>> 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
>>
>
> ___
> 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] igraph for Mathematica: IGraph/M 0.2.2 released

[Szabolcs Horvát]

Dear igraph users,

I am writing to announce the release of IGraph/M version 0.2.2, the
igraph interface for Mathematica.  As usual, it can be downloaded from

https://github.com/szhorvat/IGraphM/releases

The goal of IGraph/M is seamlessly integrate igraph into Mathematica
and make it easy to use their functions together.

This is a bugfix release.  It includes some of the fixes accumulated
during the work towards version 0.3.

Users should be aware of the following important fixes/changes since
version 0.2.0:

 - IGFeedbackArcSet could return wrong results for some graphs. This
is now fixed.
 - The "RemovedEdges" property returned by
IGCommunitiesEdgeBetweenness could be incorrect for some graphs. This
is now fixed. Other properties were not affected.
 - VF2 isomorphism functions now work when both vertex and edge
colours are specified at the same time.
 - IGBlissCanonicalGraph is now suitable for filtering isomorphic
duplicates with functions such as DeleteDuplicatesBy.  Note that the
output of this function has changed since 0.2.0.

There are several other minor fixes that do not affect results.

This release is based on the same build of the C core library as
0.2.0.  None of the problems mentioned above are due to the C core, so
they don't affect other igraph interfaces.

Binaries are available for Windows 64-bit, OS X 10.9 or later, Linux
64-bit and Raspberry Pi.

If you are currently using IGraph/M 0.2.x, please upgrade to 0.2.2.
Any feedback about the package is most welcome.

Szabolcs

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

[igraph] feedback arc set with R interface

[Szabolcs Horvát]

Hello,

The C and Python interfaces have a function for computing a "feedback arc
set".

Does such a function exist in the R interface?   If yes, what is it called?

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

Re: [igraph] computing betweenness for weighted network

[Szabolcs Horvát]

On 4 May 2016 at 15:59, Tamas Nepusz  wrote:
>> I didn't know about Nexus.  Is it still being maintained?
> Well -- the server is operational, the API has not changed, so it
> works, and we would probably fix it if someone reports that it is not
> functioning properly. However, we haven't received any data donations
> and probably lack the resources (bandwidth and storage space) to host
> large-scale datasets on our servers.

Are there any standards for the edge and vertex attributes?  For
example, can I assume that for a simple weighted graph the edge weight
will always be called "weight"?  Or are there no guarantees?

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

Re: [igraph] Solution for installing python-igraph for Anaconda using Homebrew igraph [OS X]

[Szabolcs Horvát]

Could this be a homebrew-induced problem?

I do not have homebrew, but I do have Anaconda and pip install
python-igraph seems to work fine (it compiles everything and igraph can be
used with no problems).

On 28 April 2016 at 18:53, Tamas Nepusz  wrote:

> Great, thanks for the writeup! I'm thinking about incorporating this
> somehow into the setup.py script, which already contains an Anaconda
> Python specific hack - it all depends on whether there is a way for
> setup.py to pass the --global-option flag "internally" to the
> compiler.
> T.
>
>
> On Thu, Apr 28, 2016 at 5:53 PM, Christopher Cameron 
> wrote:
> > I wanted to share this solution with the list in case others run into
> this issue:
> >
> > I ran into errors about libiconv.la and/or libxml2.2.dylib while trying
> to install python-igraph on a clean install of OS X 10.11, with homebrew
> installed igraph C library and Anaconda Python 2.7. I came across a few
> posts about possible solutions but wanted to offer an solution that does
> not involve renaming/moving system library files. The method below uses
> shell variables and extra pip flags to build python-igraph against the
> homebrew C library.
> > Longer description and beautified commands here:
> http://chrisjcameron.github.io/2016/04/27/homebrew_and_anaconda/
> >
> > Temporarily change your PATH to avoid anaconda directories (e.g.)
> > % PATH=/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin
> >
> > Install homebrew iGraph normally:
> > % brew install igraph
> >
> > Use extra flags so python-igraph is not built against the libraries
> bundled with Anaconda:
> > % ~/anaconda/bin/pip install python-igraph --global-option=build_ext
> --global-option="-L/usr/lib:/usr/local/lib"
> >
> > I was able to import igraph and run the igraph test suite successfully.
> >
> >
> >
> > ___
> > 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] communities_spinglass original method with negative weights

[Szabolcs Horvát]

Hello,

According to the documentation, communities_spinglass doesn't support
negative weights with the original method.

http://igraph.org/c/doc/igraph-Community.html#igraph_community_spinglass

"The vector giving the edge weights, it may be NULL, in which case all
edges are weighted equally. Edge weights should be positive, altough
this is not tested."


What does this mean exactly? What happens if I pass negative weights?
In a simple test, the function return a result (both in C and R)
without complaints ("altough this is not tested").  Is the result
simply useless?

What is the rationale behind not checking the weight vector at least
in the high level interfaces?

Szabolcs

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

Re: [igraph] maximal_cliques_template.h: a way to stop the search?

[Szabolcs Horvát]

Hi Tamas,

All this sounds good, but I am a bit uncomfortable with one thing:
using IGRAPH_INTERRUPTED to signal the stop.  This error code is used
to signal a user-interrupt checked through
igraph_allow_interruption().  When such an interruption is detected,
there is no expectation for the function to return anything
meaningful, only to free resources (i.e. ensure no memory leak).  The
interruption is handled as a sort of error condition which is passed
up to the calling igraph function.

In this case there would be no error, only a signal to stop the
search.  The top-level clique search function should not indicate an
error to its caller, it should return with IGRAPH_SUCCESS.  The
behaviour should be the same as with igraph_isomorphic_function_vf2()

It must be possible to distinguish between an interactive user
interruption (which is an error condition) and the callback function
requesting a stop (which is not an error).

Of course what you expect would work regardless because the _bk
function does not check for interruptions internally (yet). But what
if in the future someone adds a check there?


On 22 April 2016 at 18:31, Tamas Nepusz  wrote:
> Hi,
>
>> Maximal clique related functions are implemented (mostly) through
>> maximal_cliques_template.h.  There is a RECORD macro where we can
>> define how to record a clique that was found.  Is there a way to
>> signal within this RECORD section that the clique search does not need
>> to continue and the clique search function should now return (after
>> doing all the necessary cleanup)?
> Well, not with the current implementation, but I think it is not too
> hard to modify the existing implementation.
>
> Basically, what you need to do is:
>
> - Formally state that a nonzero return value from
> igraph*_maximal_cliques_bk (the backtracking step) is a request to
> stop the search. (Right now the function always returns zero, but it
> has an int return type, so you can safely return any igraph error code
> there).
>
> - Whenever igraph_*_maximal_cliques_bk is called, you have to check
> whether there was a nonzero value returned and if so, stop the search
> and propagate the error value back to the caller.
>
> - At the topmost level where igraph_*_maximal_cliques_bk is called the
> first time, you need to check the return value and interrupt the
> search accordingly.
>
> By the way, the RECORD macros currently don't do any error checking on
> calls to igraph_vector_ptr_push_back() and alike, so errors from these
> functions may go unnoticed, which is a Bad Thing (TM). I think the
> best would be to:
>
> 1) update all RECORD macros with IGRAPH_CHECK() calls whenever we
> perform an operation that may potentially return an error code
> 2) use the special (and currently undocumented) IGRAPH_INTERRUPTED
> error code from the RECORD macros to signal that the user wants to
> stop the search
> 3) make sure that nonzero return values from
> igraph_*_maximal_cliques_bk are propagated upwards. (Surrounding every
> such call except the topmost one with IGRAPH_CHECK() should suffice).
> 4) at the topmost call to igraph_*_maximal_cliques_bk, check whether
> the error code is IGRAPH_INTERRUPTED; if not, return the error code to
> the caller. Something like:
>
> int ret = igraph_..._maximal_cliques_bk(...);
> if (ret == IGRAPH_INTERRUPTED) {
> /* handle the interruption */
> } else {
> /* let igraph handle the error */
> IGRAPH_CHECK(ret);
> }
>
> T.
>
> ___
> 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] maximal_cliques_template.h: a way to stop the search?

[Szabolcs Horvát]

Hello,

Maximal clique related functions are implemented (mostly) through
maximal_cliques_template.h.  There is a RECORD macro where we can
define how to record a clique that was found.  Is there a way to
signal within this RECORD section that the clique search does not need
to continue and the clique search function should now return (after
doing all the necessary cleanup)?

I want to have an analog of igraph_cliques_callback for maximal cliques:

https://github.com/igraph/igraph/blob/master/include/igraph_cliques.h#L106

I am trying to decide if I can re-use the callback function type
igraph_clique_handler_t

https://github.com/igraph/igraph/blob/master/include/igraph_cliques.h#L102

This callback function can signal when the search does not need to continue.

The function igraph_i_maximal_cliques() actually already does this,
but it is not public.  It takes a callback function as an argument.
That function can signal when the search should no longer continue.
But igraph_i_maximal_cliques is considerably slower than the
maximal_cliques_template.h implementation, so I wanted to avoid using
it.

Szabolcs

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

Re: [igraph] A question about the installation of the C library igraph

[Szabolcs Horvát]

It is a C library, which means that you have to write your own C programs
to make use of it.  Here's the tutorial to get started:

http://igraph.org/c/doc/igraph-tutorial.html

On 2 April 2016 at 04:01, 王钧  wrote:

> I've used the brew to install the igraph according to your instruction,
> but i do not know how to start to use it because it isn't an app, is it?
> Could you please help me how to use it ?
>
>
>
>
> ___
> 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 calculating minimum spanning tree with weights C interface

[Szabolcs Horvát]

On 29 March 2016 at 15:59,  wrote:

> I have been trying to calculate a minimum spanning tree using prim method,
> but I have got a little bit confused about the weights are used in this
> context. The suggest example program in the source documents does not seem
> to be correct, I don't understand why the edge betweenness needs to be
> calculated.
>

The edge betweenness does not need to be calculated.  This simple example
program simply uses the edge betweenness as edge weights.  You can use
whatever weights you want.


> Please see the following program, its designed to make a simple undirected
> graph.
>
>
> #include 
> int main()
> {
> igraph_vector_t eb, edges;
> igraph_vector_t weights;
> long int i;
> igraph_t theGraph, tree;
> struct arg {
> int index;
> int source;
> int target;
> float weight;
> };
> struct arg data[] = {
> {0, 0, 1, 2.0},
> {1, 1, 2, 3.0},
> {2, 2, 3, 44.0},
> {3, 3, 4, 3.0},
> {4, 4, 1, 2.0},
> {5, 4, 5, 9.0},
> {6, 4, 6, 3.0},
> {6, 6, 5, 7.0}
> };
>
> int nargs = sizeof(data) / sizeof(struct arg);
> igraph_empty(, nargs, IGRAPH_UNDIRECTED);
>
>
It looks like nargs is the number of edges in your graph.  You need to pass
the number of nodes to igraph_empty().


>
>
> igraph_vector_init(, nargs);
> // create graph
> for (i = 0; i < nargs; i++) {
> igraph_add_edge(, data[i].source, data[i].target);
> // Add an weight per entry
> igraph_vector_set(, i, data[i].weight);
> }
>
> igraph_vector_init(, igraph_ecount());
> igraph_edge_betweenness(, , IGRAPH_UNDIRECTED, );
> for (i = 0; i < igraph_vector_size(); i++) {
> VECTOR(eb)[i] = -VECTOR(eb)[i];
> }
>
> igraph_minimum_spanning_tree_prim(, , );
> igraph_write_graph_edgelist(, stdout);
>
> igraph_vector_init(, 0);
> igraph_minimum_spanning_tree(, , );
> igraph_vector_print();
> igraph_vector_destroy();
>
> igraph_destroy();
> igraph_destroy();
> igraph_vector_destroy();
> return 0;
> }
>
> Can anybody see anything that is wrong with this program its designed to
> build a simple graph with what I hope is the correct way to use a weight
> argument.
>

You can use whatever values you want for edge weights.  Here you copied the
example program, calculated the edge betweenness and used that as weights.
Do you want to use the edge betweenness (eb) or your original weights
(weights)?  It all depends on what you want to do.


> One value per edge between a source and a target.
>
> regards
>
> Dave.
>
> ___
> 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] Recover original vertex ID from graph decomposition

[Szabolcs Horvát]

You could use igraph_clusters() instead. It computes the mapping
without creating new graphs.

If you need to create a new graph from a component,
igraph_induced_subgraph should work.

On 13 February 2016 at 20:07, Hadidi, Lars
 wrote:
> The igraph_decompose function decomposes a given graph into its connected
> components.
>
> The vertex ids in the new graphs will be different than in the original
> graph.
>
>
>
> Is it possible to get the original IDs of the vertices for each component ?
>
>
>
> The elements of the components' result vector point to each component. There
> may be a mapping between the components IDs and the input graph, e.g.
> original id is the component id plus the sum of the amount of vertices of
> all previous components from the result vector.
>
>
>
>
> ___
> 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] What exactly does igraph_transitivity_undirected() compute for directed graphs?

[Szabolcs Horvát]

Thanks again for the clarification!  I think what actually happens is
that the neighbours of a vertex are counted as the degree of that
vertex (which is not the same thing for multigraphs).

Do you think a patch that converts directed graphs to undirected
simple graphs before computing the local clustering coefficient would
be appropriate here?

On 7 December 2015 at 13:16, Gábor Csárdi <csardi.ga...@gmail.com> wrote:
> I am not sure if it is defined. I guess this is just a case when the
> behavior is not defined for multi-graphs.
>
> Gabor
>
> On Mon, Dec 7, 2015 at 12:14 PM, Szabolcs Horvát <szhor...@gmail.com> wrote:
>> Thank you for the explanation.
>>
>> Could you elaborate a bit on how igraph defines the local clustering
>> coefficient when multiple (parallel) edges are present?
>>
>> On 7 December 2015 at 12:56, Gábor Csárdi <csardi.ga...@gmail.com> wrote:
>>> It's because of the multiple edges in the first graph. I.e.:
>>>
>>>> transitivity(as.undirected(g, mode = "each"),"local")
>>> [1] 0.333 0.333 1.000
>>>
>>> Gabor
>>>
>>> On Mon, Dec 7, 2015 at 10:05 AM, Szabolcs Horvát <szhor...@gmail.com> wrote:
>>>> Hello,
>>>>
>>>> What precisely does igraph_transitivity_undirected() compute for
>>>> directed graphs?
>>>>
>>>> The C documentation states that
>>>>
>>>> "Directed graphs are considered as undirected ones."
>>>>
>>>> but this is not exactly the case.
>>>>
>>>> With an example using the R interface (for simplicity),
>>>>
>>>>> g<-make_graph(c(1,2, 2,1, 2,3, 3,1))
>>>>> transitivity(g,"local")
>>>> [1] 0.333 0.333 1.000
>>>>
>>>>> transitivity(as.undirected(g),"local")
>>>> [1] 1 1 1
>>>>
>>>> Can someone clarify what precisely is computed in the directed case?
>>>>
>>>> Szabolcs
>>>>
>>>> ___
>>>> 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] What exactly does igraph_transitivity_undirected() compute for directed graphs?

[Szabolcs Horvát]

Hello,

What precisely does igraph_transitivity_undirected() compute for
directed graphs?

The C documentation states that

"Directed graphs are considered as undirected ones."

but this is not exactly the case.

With an example using the R interface (for simplicity),

> g<-make_graph(c(1,2, 2,1, 2,3, 3,1))
> transitivity(g,"local")
[1] 0.333 0.333 1.000

> transitivity(as.undirected(g),"local")
[1] 1 1 1

Can someone clarify what precisely is computed in the directed case?

Szabolcs

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

Re: [igraph] What exactly does igraph_transitivity_undirected() compute for directed graphs?

[Szabolcs Horvát]

Thank you for the explanation.

Could you elaborate a bit on how igraph defines the local clustering
coefficient when multiple (parallel) edges are present?

On 7 December 2015 at 12:56, Gábor Csárdi <csardi.ga...@gmail.com> wrote:
> It's because of the multiple edges in the first graph. I.e.:
>
>> transitivity(as.undirected(g, mode = "each"),"local")
> [1] 0.333 0.333 1.000
>
> Gabor
>
> On Mon, Dec 7, 2015 at 10:05 AM, Szabolcs Horvát <szhor...@gmail.com> wrote:
>> Hello,
>>
>> What precisely does igraph_transitivity_undirected() compute for
>> directed graphs?
>>
>> The C documentation states that
>>
>> "Directed graphs are considered as undirected ones."
>>
>> but this is not exactly the case.
>>
>> With an example using the R interface (for simplicity),
>>
>>> g<-make_graph(c(1,2, 2,1, 2,3, 3,1))
>>> transitivity(g,"local")
>> [1] 0.333 0.333 1.000
>>
>>> transitivity(as.undirected(g),"local")
>> [1] 1 1 1
>>
>> Can someone clarify what precisely is computed in the directed case?
>>
>> Szabolcs
>>
>> ___
>> 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] igraph_ prefix in source file names

[Szabolcs Horvát]

Dear all,

Within the igraph C sources, is there any reasoning for which file has an
igraph_ prefix and which doesn't?  I can't immediately see what pattern
they follow.

Consider cliques.c vs igraph_cliques.c
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] why use floating point for graph nodes?

[Szabolcs Horvát]

On 5 November 2015 at 10:17, Gábor Csárdi  wrote:
>
> so that you don't need to copy between C and R.
>

Oh, so does the R interface avoid copying data structures that are
also exposed to R?  (I don't know anything about R internals or how to
extend R with C.)

In which situations does it manage to avoid copies?  I am interested
in this because a major bottleneck of the Mathematica interface is all
the copying it needs to do and currently I'm trying to speed things
up.

When igraph functions return an igraph_vector_t, does it need to be
copied to get exposed as an R numerical vector?  If not, did you need
to make changes to igraph's memory allocation to make it usable in
conjunction with R?

I know that copies can be avoided when sending data *to* igraph, e.g.
often we can use igraph_vector_view()

Does igraph offer anything similar to a "vector view" for an igraph_t?
 I.e. if I already have an igraph_vector_t for the "from" vertices and
"to" vertices, can I safely re-use them inside of a graph?  I never
really looked at the internal structure and I don't know what oi, ii,
os, is do ...  If igraph wasn't designed for this, it's probably not a
good idea for me to push it though.

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

Re: [igraph] why use floating point for graph nodes?

[Szabolcs Horvát]

Hi Gabor,

Just out of curiosity, have you measured what sort of performance
impact that change had, if any?

Szabolcs

On 5 November 2015 at 10:08, Gábor Csárdi  wrote:
> FYI: https://github.com/igraph/igraph/tree/feature-int-igraph_t
>
> Gabor
>
> On Wed, Nov 4, 2015 at 11:12 PM, Tamas Nepusz  wrote:
>> Ah, sorry, just realized that igraph_t contains igraph_vector_t
>> objects, and those indeed contains doubles. Yes, you are right, this
>> is weird, and this is a heritage from the old days when
>> igraph_integer_t was also typedef'd to a double. Just for fun I have
>> changed the types in igraph_t to igraph_vector_long_t and made a few
>> quick modifications to src/type_indexededgelist.c to make things
>> compile without warnings, and it seems to do the trick - all tests
>> compile just fine. However, there are probably lots of unnecessary
>> casts left in the code, and of course we cannot change the public API
>> (which still uses igraph_vector_t in lots of cases to store vertex
>> lists) without breaking everyone else's code, so this quirk is
>> probably here to stay for while (unless Gabor makes an executive
>> decision and decides to break the API intentionally).
>>
>> If anyone is interested in it, I have pushed the changes into a
>> separate branch named feature/graph_t-with-long-vector.
>>
>> T.
>>
>> T.
>>
>>
>> On Wed, Nov 4, 2015 at 11:18 PM, Tamas Nepusz  wrote:
 Why does igraph use floating point data (C doubles) to represent graph
 vertices?  It seems like an unusual choice and I would expect it to
 negatively affect performance.  Is it an R heritage?
>>> Em... it used to be that way a (not so) long time ago; see this
>>> thread on the mailing list:
>>>
>>> https://lists.nongnu.org/archive/html/igraph-help/2009-01/msg00119.html
>>>
>>> However, I have just checked the source code and igraph_integer_t is
>>> now typedef'd to an int so this is probably not the case any more.
>>>
>>> T.
>>
>> ___
>> 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] why use floating point for graph nodes?

[Szabolcs Horvát]

Why does igraph use floating point data (C doubles) to represent graph
vertices?  It seems like an unusual choice and I would expect it to
negatively affect performance.  Is it an R heritage?

Szabolcs

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

Re: [igraph] Error importing igraph in OSX 10.10.5

[Szabolcs Horvát]

On recent versions of OS X, by default gcc is an alias for clang, and
will work correctly.  If the gcc command crashes on your computer,
then there must be a gcc executable somewhere else in the path.  What
does

echo $PATH

return on your computer?

On 15 October 2015 at 03:17, Pablo Moriano  wrote:
> Hi Tamas,
>
> I remember that just before I tried to install igraph, I typed `export 
> CC=/usr/bin/gcc’ and `export CXX=/usr/bin/g++’ to declare the Apple compilers 
> as my default option. Is that related with this issue? Is there any way to 
> check if I have installed the C compilers (from gnu) and where? Thank you.
>
>> On Oct 14, 2015, at 6:30 PM, Tamas Nepusz  wrote:
>>
>> Hi Pablo,
>>
>> gcc does not seem to work on your machine. This might or might not be
>> a problem - it probably doesn't affect igraph but you should try and
>> reinstall the C compilers at some point to be on the safe side.
>>
>> I have clang-600.0.51 on my machine and the compilation of igraph
>> works perfectly fine with this version. I'll try to find another
>> machine with a newer clang and test the compilation there.
>>
>> T.
>>
>> T.
>>
>>
>> On Tue, Oct 13, 2015 at 2:46 PM, Pablo Moriano  wrote:
>>> Hi Tamas,
>>>
>>> Thank you for your response. These are the results:
>>>
>>> gcc -v
>>>
>>> Segmentation fault: 11
>>>
>>> clang -v
>>>
>>> Apple LLVM version 7.0.0 (clang-700.0.72)
>>> Target: x86_64-apple-darwin14.5.0
>>> Thread model: posix
>>>
>>> What can be wrong?
>>>
>>> On Oct 13, 2015, at 5:04 AM, Tamas Nepusz  wrote:
>>>
>>> Hi Pablo,
>>>
>>> This issue seems to be either specific to OS X 10.10.5 or to your
>>> machine because it works just fine on my Mac with OS X 10.9. My best
>>> guess is that this is an issue with your C compiler. Can you post the
>>> output of "gcc -v" and "clang -v" here?
>>>
>>> T.
>>>
>>> T.
>>>
>>>
>>> On Mon, Oct 12, 2015 at 11:03 PM, Pablo Moriano 
>>> wrote:
>>>
>>> Hi,
>>>
>>> I installed igraph on a mac OS X10.10.5 under Anaconda Python using pip
>>> install igraph-python. It seems to be installed correctly. It does not
>>> complain. However, when I tried to import the library, I am getting
>>>
>>> import igraph
>>>
>>> Traceback (most recent call last):
>>> File "", line 1, in 
>>> File
>>> "/Users/user/anaconda/lib/python2.7/site-packages/igraph/__init__.py", line
>>> 34, in 
>>>   from igraph._igraph import *
>>> ImportError:
>>> dlopen(/Users/user/anaconda/lib/python2.7/site-packages/igraph/_igraph.so,
>>> 2): Symbol not found: ___emutls_get_address
>>> Referenced from:
>>> /Users/user/anaconda/lib/python2.7/site-packages/igraph/_igraph.so
>>> Expected in: dynamic lookup
>>>
>>> Does anyone knows how to fix it? 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
>>>
>>>
>>>
>>> ___
>>> 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 Propagation

[Szabolcs Horvát]

Most igraph functions are implemented in C, not in R.  You'll find all
the igraph source code on GitHub: https://github.com/igraph/  There's
a link at the top right of the igraph.org homepage.

The label propagation algorithm is here:

https://github.com/igraph/igraph/blob/master/src/community.c#L2127

On 29 September 2015 at 19:02, Benika H  wrote:
> Hi. I would like to use the R source code for the label propagation
> algorithm. Is there a version on GitHub or available elsewhere? I'm trying
> to set a group of nodes as seed nodes and determine neighbors. Therefore, I
> would like to modify the code for this use.
>
>
> Thank you,
>
> BH
>
> ___
> 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] Why are chordal completions computed by igraph so suboptimal?

[Szabolcs Horvát]

Dear All,

igraph can compute a fill-in necessary to make a graph chordal.  I noticed
that the fill-in it returns is usually far from optimal.  While igraph
makes no claims of generating a minimal fill-in, I do wonder if this
behaviour is correct or if something is going wrong.

A simple example is a 2D grid graph, where a trivial minimal fill-in is
adding the "diagonals" of each "square".

Example in R:

g <- make_lattice(c(2,3))

is_chordal(g, fillin=T)

The fill-in it returns is (6 3) (4 1) (6 1) (5 1). If you plot the graph,
you'll see that (6 3) (4 1) is sufficient.  For larger graphs the fill-in
tends to be even more suboptimal.

So is this the expected behaviour?

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

Re: [igraph] edge.betweenness returns negative or NaN values

[Szabolcs Horvát]

On 14 September 2015 at 00:30, Szabolcs Horvát <szhor...@gmail.com> wrote:
> Just to have a simple test case:
>
> Based on a comparison with Mathematica, for an n*n grid graph things
> start to go wrong at n=35. For n=34 the edge betweenness is still
> accurate.
>

While the n=34 value is about right for the limits of betweenness
calculation without bigints, it happens to be the case that for n > 34
Mathematica also gives bad results (different ones).

> On 13 September 2015 at 22:37, Tamas Nepusz <nta...@rmki.kfki.hu> wrote:
>> Ah, my bad, I did not notice that you meant the edge betweenness and
>> not the node betweenness. It looks like the edge betweenness related
>> code does not include a similar bigint workaround. This should be
>> fixed in the next version then - can you add a bug report to
>> https://github.com/igraph/igraph/issues ?
>>
>> Thanks,
>> T.
>>
>> T.
>>
>>
>> On Sun, Sep 13, 2015 at 9:24 AM, Vincent Labatut
>> <vincent.laba...@free.fr> wrote:
>>> Hello Tamas,
>>>
>>> and thanks for your answer.
>>> I was thinking of something like that, since the networks are lattices and
>>> this case is mentionned in the documentation.
>>> I also had noticed the "nobigint" parameter for the "betweenness" functions,
>>> however it does not exist for the "edge.betweenness" functions.
>>> Best,
>>> Vincent
>>>
>>>> Hello,
>>>>
>>>> The negative values are most likely due to integer overflows (i.e. the
>>>> betweenness score would be too large and the underlying variable in
>>>> which igraph computes the betweenness score overflows). You can get
>>>> around this by passing nobigint=FALSE to the edge betweenness call -
>>>> it will make igraph use "big integers", which can hold arbitrarily
>>>> large numbers at the expense of being somewhat slower.
>>>>
>>>> As for the NaNs, it could be a bug, but let's see first whether the
>>>> issue persists with nobigint=FALSE. If so, let us know and try to post
>>>> a small example on which we could reproduce the issue with NaNs.
>>>>
>>>> T.
>>>>
>>>>
>>>>
>>>> On Sat, Sep 12, 2015 at 3:08 PM, Vincent Labatut
>>>> <address@hidden> wrote:
>>>>> Hello,
>>>>>
>>>>> I am processing the edge-betweenness of various networks using R igraph
>>>>> version 7.1. Those are spatial networks (each node has a (x,y) position)
>>>>> and
>>>>> I am using the "weight" option of the "edge.betweenness" function to take
>>>>> the spatial distances into account. This spatial distance is stored in an
>>>>> edge attribute called "dist".
>>>>>
>>>>> Here is the command I use:
>>>>> edge.betweenness(graph=g, weights=E(g)$dist)
>>>>>
>>>>> However, for some of my networks, I get negative values, or even NaN.
>>>>> Here
>>>>> are two examples, under the graphml format:
>>>>> http://dx.doi.org/10.6084/m9.figshare.1540708
>>>>> - scale=32.graphml
>>>>> - scale=41.graphml
>>>>>
>>>>> For the first one, the first values returned by "edge.betweenness" are:
>>>>>[1] 1904887544.08 1904887544.08 1896303182.39 1951787568.72
>>>>> 1203043060.76
>>>>>[6] 1270869072.68  622780616.09  667964773.27  279064394.68
>>>>> 309184936.21
>>>>>   [11]  135403467.81  155266075.94   51600202.02   60120695.31
>>>>> 21113003.39
>>>>>   [16]   24783603.896275147.306937885.521347425.01
>>>>> 1002544.99
>>>>>   [21] 150574.42-327097.77-711849.38   -1430744.36
>>>>> -246214.20
>>>>>   [26]-602827.15-230344.97-484630.12-297768.08
>>>>> -492364.06
>>>>>
>>>>> For the second one, all the returned values are NaN.
>>>>>
>>>>> Note that all these weights are positive by definition. They even are
>>>>> non-zero since no two nodes hold the same position, by construction. I
>>>>> also
>>>>> checked this programmatically. Moreover, there are no multiple links,
>>>>> also
>>>>> by construction (and I checked with "has.multiple").
>&g

Re: [igraph] Easier way to compile igraph on Windows?

[Szabolcs Horvát]

Just changing those two files wasn't sufficient. I was getting linking
errors.  Since defining MSDOS appeared to work, I just used that
instead of tracking down the linking errors.  I'm going to look at
what else is changed by MSDOS and what's the minimal change required
to make it work.

Then there's the problem with the test failures.

Are the failed tests somehow using f2c?  I get crashes on sparse array
stuff, and no output for some weighted shortest path functions.
Hopefully it's related because then I know where to look to fix the
failures ...

On 14 September 2015 at 11:38, Tamas Nepusz <nta...@rmki.kfki.hu> wrote:
> I'm a bit afraid of simply defining "MSDOS" as it seems to change
> several other things in f2c - for instance, it also defines
> NON_UNIX_STDIO, which in turn changes several IO related things in
> f2c, and I'm not sure about the consequences of those changes. So, I
> think it's okay if you change this for your own purposes, but we
> cannot treat this as an official workaround for compiling igraph on
> MSYS yet.
>
> T.
>
>
> On Sun, Sep 13, 2015 at 2:57 PM, Szabolcs Horvát <szhor...@gmail.com> wrote:
>> export CFLAGS=-DMSDOS
>> ./bootstrap.sh
>> ./configure --disable-gmp --prefix=...
>
> ___
> 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] Easier way to compile igraph on Windows?

[Szabolcs Horvát]

On 7 September 2015 at 19:46, Gábor Csárdi  wrote:
> Also, I am not sure if MSVC objects and msys objects are binary
> compatible. In general, can you compile Mathematica extensions with
> both?
>

Thanks for the response Gábor ! I don't really understand the source
of these incompatibilities. I know that both MSVC and mingw32 used to
work more or less out of the box with Mathematica, and I used the
latter a lot. MinGW-w64 requires more work, but there is actually a
usage example in the Mathematica documentation ... of course that
doesn't mean that there won't ever be any problems ...  It would
likely be the safest if I could use MSVC as that's the standard
toolchain on Windows, but at the moment I'll be happy if I can get
things working at all, with any compiler.

When you compiled with MinGW, did you have any problem with tests
passing (or rather not passing)?

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

Re: [igraph] Easier way to compile igraph on Windows?

[Szabolcs Horvát]

On 7 September 2015 at 21:34, Tamas Nepusz  wrote:
>> I tried installing msys2  to be able to run the
>> configure script, and the mingw-w64 package to be able to compile for 64 bit
>> systems.  Unfortunately the build process stops when the compiler cannot
>> find .
> sys/times.h is not available in MinGW, only in Cygwin (as far as I
> know). The only place where igraph uses it is in f2c, which is a
> third-party library. In particular, the two occurrences are in
> src/f2c/dtime_.c and src/f2c/etime_.c. These files seem to use clock()
> and CLOCKS_PER_SECOND only. clock() is actually also available from
> , so you could try including time.h instead of sys/time.h.
> Also, CLOCKS_PER_SECOND should probably be replaced with
> CLOCKS_PER_SEC because time.h defines CLOCKS_PER_SEC.
>
> Let me know if this worked for you.
>

Thanks for the hints Tamás! They helped me get a working igraph finally.

Looking at those files, it turns out that I need to #define MSDOS in
order to avoid using sys/times.h. Just getting rid of sys/times.h in
these files was not sufficient, but defining MSDOS resulted in a
successful compilation.  For future reference, here's what I did:

First I installed msys2 and the mingw-w64 toolchain based on the
instructions here: https://wiki.qt.io/MSYS2

After mingw-w64 is installed, you'll find a mingw64_shell.bat file in
the msys2 installation directory. Run this to get a shell where the
compiler is already in the PATH.  I used gcc 5.2.0.

Clone the git repo, then as usual,

export CFLAGS=-DMSDOS
./bootstrap.sh
./configure --disable-gmp --prefix=...

(In place of ... write the desired installation location.  I haven't
tried using GMP yet..)

make

This will produce libigraph-0.dll as well as static libraries.

Trying make check will fail unless the above mentioned dll is in the
path.  After fixing that, the following tests still fail:

 32 33 83 84 86 159

I'm still investigating this, but some are due to segfaults, some due
to wrong results and some due to missing headers.

The produced DLL appears to be compatible with MSVC, but depends on
the following due to using this version of MinGW:

libgcc_s_seh-1.dll
libstdc++-6.dll
libwinpthread-1.dll

I do have a (sort of) working igraph for Mathematica, but as you can
see this is not yet the final solution, so still investigating.

Szabolcs

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

Re: [igraph] edge.betweenness returns negative or NaN values

[Szabolcs Horvát]

Just to have a simple test case:

Based on a comparison with Mathematica, for an n*n grid graph things
start to go wrong at n=35. For n=34 the edge betweenness is still
accurate.

On 13 September 2015 at 22:37, Tamas Nepusz  wrote:
> Ah, my bad, I did not notice that you meant the edge betweenness and
> not the node betweenness. It looks like the edge betweenness related
> code does not include a similar bigint workaround. This should be
> fixed in the next version then - can you add a bug report to
> https://github.com/igraph/igraph/issues ?
>
> Thanks,
> T.
>
> T.
>
>
> On Sun, Sep 13, 2015 at 9:24 AM, Vincent Labatut
>  wrote:
>> Hello Tamas,
>>
>> and thanks for your answer.
>> I was thinking of something like that, since the networks are lattices and
>> this case is mentionned in the documentation.
>> I also had noticed the "nobigint" parameter for the "betweenness" functions,
>> however it does not exist for the "edge.betweenness" functions.
>> Best,
>> Vincent
>>
>>> Hello,
>>>
>>> The negative values are most likely due to integer overflows (i.e. the
>>> betweenness score would be too large and the underlying variable in
>>> which igraph computes the betweenness score overflows). You can get
>>> around this by passing nobigint=FALSE to the edge betweenness call -
>>> it will make igraph use "big integers", which can hold arbitrarily
>>> large numbers at the expense of being somewhat slower.
>>>
>>> As for the NaNs, it could be a bug, but let's see first whether the
>>> issue persists with nobigint=FALSE. If so, let us know and try to post
>>> a small example on which we could reproduce the issue with NaNs.
>>>
>>> T.
>>>
>>>
>>>
>>> On Sat, Sep 12, 2015 at 3:08 PM, Vincent Labatut
>>>  wrote:
 Hello,

 I am processing the edge-betweenness of various networks using R igraph
 version 7.1. Those are spatial networks (each node has a (x,y) position)
 and
 I am using the "weight" option of the "edge.betweenness" function to take
 the spatial distances into account. This spatial distance is stored in an
 edge attribute called "dist".

 Here is the command I use:
 edge.betweenness(graph=g, weights=E(g)$dist)

 However, for some of my networks, I get negative values, or even NaN.
 Here
 are two examples, under the graphml format:
 http://dx.doi.org/10.6084/m9.figshare.1540708
 - scale=32.graphml
 - scale=41.graphml

 For the first one, the first values returned by "edge.betweenness" are:
[1] 1904887544.08 1904887544.08 1896303182.39 1951787568.72
 1203043060.76
[6] 1270869072.68  622780616.09  667964773.27  279064394.68
 309184936.21
   [11]  135403467.81  155266075.94   51600202.02   60120695.31
 21113003.39
   [16]   24783603.896275147.306937885.521347425.01
 1002544.99
   [21] 150574.42-327097.77-711849.38   -1430744.36
 -246214.20
   [26]-602827.15-230344.97-484630.12-297768.08
 -492364.06

 For the second one, all the returned values are NaN.

 Note that all these weights are positive by definition. They even are
 non-zero since no two nodes hold the same position, by construction. I
 also
 checked this programmatically. Moreover, there are no multiple links,
 also
 by construction (and I checked with "has.multiple").

 I was wondering if the negative or NaN values I get are due to me
 misusing
 the function, or if this is a bug in igraph.

 Thanks,
 Vincent Labatut

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

>>
>>
>> On Sat, Sep 12, 2015 at 3:08 PM, Vincent Labatut 
>> wrote:
>>>
>>> Hello,
>>>
>>> I am processing the edge-betweenness of various networks using R igraph
>>> version 7.1. Those are spatial networks (each node has a (x,y) position) and
>>> I am using the "weight" option of the "edge.betweenness" function to take
>>> the spatial distances into account. This spatial distance is stored in an
>>> edge attribute called "dist".
>>>
>>> Here is the command I use:
>>> edge.betweenness(graph=g, weights=E(g)$dist)
>>>
>>> However, for some of my networks, I get negative values, or even NaN. Here
>>> are two examples, under the graphml format:
>>> http://dx.doi.org/10.6084/m9.figshare.1540708
>>> - scale=32.graphml
>>> - scale=41.graphml
>>>
>>> For the first one, the first values returned by "edge.betweenness" are:
>>>[1] 1904887544.08 1904887544.08 1896303182.39 1951787568.72
>>> 1203043060.76
>>>[6] 1270869072.68  622780616.09  667964773.27  279064394.68
>>> 309184936.21
>>>   [11]  135403467.81  155266075.94   51600202.02   60120695.31
>>> 21113003.39
>>>   [16]   24783603.896275147.306937885.521347425.01
>>> 1002544.99
>>>   

Re: [igraph] rewire

[Szabolcs Horvát]

On 10 September 2015 at 15:21, Qunawei Zhang  wrote:

> Hello:
>
> I have some questions about rewire, would you please explain to me? Thanks
> (1) Each iteration, two edges are randomly selected right? And the new
> edges (which generated by the rewiring) can also be selected and to be
> rewire again?
>

The following is based on my understanding, and may not be fully accurate.
The igraph authors will correct me if necessary.

In each step you select two disjoint edges and swap the endpoints if
possible.  E.g., A-B, C-D can be swapped to A-C, B-D or to A-D, B-C, if
those edges do not already exist.


> (2) If I set  niter = 100, does it mean 100 edge pairs will be rewired?
>

No, it means that 100 attempts will be made.  Some may be unsuccessful.


> Is there a probability that controls whether to rewire each selected edge
> pairs?
>

Sorry, I don't understand this question.


> Some times a randomly selected edge pair can not be rewired, will this
> counted a trial or only successfully rewired ones will be counted as a
> trail?
>

"Trial" means "attempt".  Not all attempts will be successful.

Ensuring that precisely 100 swaps will be performed is rather problematic
to implement in a useful (and fast) way because it would involve checking
whether any edges can be swapped at all.

(3) Sometimes, the rewired network will be divided into several components,
> even when the original network is one connected component. Is there is a
> way to control the rewire process make the network connected? I tried to
> just selected the connected random network, but I can only get a few from
> 1000 random network, and I need much more.
>

Rewiring many times creates a random graph with the same degree sequence as
your starting point.  You can check out the degree sequence game function
with the Viger-Latapy method, which creates connected graphs.


>
>  rewire(graph, mode = c("simple", "loops"), niter = 100)
> niter
>
> Number of rewiring trials to perform.
>
>
> Thanks.
>
> Best
> Quanwei
>
> ___
> 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] Proper way to deal with igraph_vector_ptr_t returned by functions

[Szabolcs Horvát]

Hi all,

Many igraph functions return "lists of lists" as an
igraph_vector_ptr_t of igraph_vector_t * elements. This question is
only about cases when the pointer vector contains pointers to
igraph_vector_t.

I'm looking for some confirmation that I am dealing with these in the
right way and that I am freeing memory properly.

First question:

Do all these igraph functions (e.g. igraph_cliques) handle pointer
vectors in the same way?  In particular, do they have destructors set
already?  Perhaps some functions set destructors and some don't? Do
all require already initialized pointer vectors?

Roughly, this is what I'm doing:

igraph_vector_ptr_t list;

igraph_vector_ptr_init(, 0);

// make sure the right destructor is set
IGRAPH_VECTOR_PTR_SET_ITEM_DESTRUCTOR(, igraph_vector_destroy);

igraph_some_function(..., , ...);

// use list in some way ...

// this should free
igraph_vector_ptr_destroy_all();

Is this way general enough to handle *any* igraph function that
returns multiple vectors this way?

Instead of setting a destructor, I could loop through it and free
elements by hand. Some examples do that.

Finally, I notice that some examples use free() and not igraph_free()
to free memory. Do I need to worry about this and the potential
differences between the two if igraph itself and my program use
different compilers?  Shouldn't igraph provide an igraph_malloc in
addition to igraph_free to make sure that memory I might allocate will
be correctly freed by igraph_vector_ptr_free_all()? This last one is
so far a theoretical question as I don't yet need this.

Szabolcs

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

Re: [igraph] Memory issues with igraph-python get_subisomorphisms_vf2

[Szabolcs Horvát]

Depending on your graphs, there can be potentially a very large number of
(sub)isomorphisms.  If you want to store all of them at the same time, the
memory requirement is far worse than that.  For an extreme example,
consider a complete graph on 2N nodes.  How many complete subgraphs does it
contain on N nodes?  For 2N = 40 that would be (2N)! / (2 N!) = 137 846 528
820 ~ 1.38e11.

Have you tried the count_subisomorphisms_vf2 function?  It won't store all
isomorphisms, it will only count them.  If there's combinatorial explosion
it might still not ever finish in practice though.

In the C interface there's a vf2 function that executes a custom callback
function for each isomorphism found.  The callback function can signal that
it wants to stop.  With this one can implement finding at most a certain
number of isomorphisms and stopping afterwards.  This is what I did with
the Mathematica interface (patterned after Mathematica's own isomorphism
finder function), though I am not yet sure of what use it will be to find
more than one yet less than all of them.



On 9 September 2015 at 16:14, Iva Pritisanac 
wrote:

> Dear All,
>
> I have memory problem when using igraph-python method
> get_subisomorphisms_vf2 on Windows 64bit system.
>
> I am using igraph-python in the context of a graph-subgraph isomorphism
> applications for graph-subgraph with ~40 vertices.
> When attempting to obtain a nested list of all subisomorphisms, physical
> memory of my system gets exhausted very quickly (~within 10min).
>
> Given that the memory requirement of the vf2 algorithm is *O*(N), I
> should not have this problem. Is there something I am missing?
>
> Thank you very much in advance!
>
> Sincerely,
>
> Iva
>
>
> ___
> 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] igraph_isohandler_t: whose responsibility is to free map12 and map21?

[Szabolcs Horvát]

Dear All,

The  igraph_isomorphic_function_vf2()  function takes a callback of the type

typedef igraph_bool_t igraph_isohandler_t(const igraph_vector_t
*map12, const igraph_vector_t *map21, void *arg);

Whose responsibility is it to igraph_vector_destroy() map12 and map21?
  Does it need to be done in the handler or does
igraph_isomorphic_function_vf2() do it?

I am hoping and assuming that it is left to the handler, but I would
like to make sure.

Szabolcs

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

Re: [igraph] Easier way to compile igraph on Windows?

[Szabolcs Horvát]

Hi Gabor,

Thank you for the comments.

Can you give me some hints on how you built igraph using the mingw
toolchain?

Did you compile a 32 or a 64 bit executable?  How did you run the configure
script?

I tried installing msys2 <https://msys2.github.io/> to be able to run the
configure script, and the mingw-w64 package to be able to compile for 64
bit systems.  Unfortunately the build process stops when the compiler
cannot find .  The configure script does correctly find out
that this header file is not available, but it still sets up a build
process that requires it.

I don't specifically need MSVC, I just need to somehow compile it for
64-bit Windows without needing to rely on a special DLL like the cygwin
one.  I got stuck with trying to fix up the MSVC project file and I finally
gave up on it.

Szabolcs

On 5 September 2015 at 21:13, Gábor Csárdi <csardi.ga...@gmail.com> wrote:

> The "correct" way is to run `make msvc`, but not from cygwin. In fact
> we do not use cygwin for anything.
>
> However, we only test this for releases, so between releases some
> source or include files might be missing from the project files.
>
> The R interface has a completely separate compilation process which
> uses mingw, so that does not help you at all.
>
> The solution here is to add the missing source/include files to the
> project file. Pull requests are welcome, especially because I do not
> have access to windows right now, so I cannot test this.
>
> Gabor
>
> On Sat, Sep 5, 2015 at 6:44 PM, Szabolcs Horvát <szhor...@gmail.com>
> wrote:
> > It seems the way to build the MSVC source package is to use "make msvc"
> > after ./configure.
> >
> > For some reason this builds an incorrect package when I run it in
> cygwin. I
> > get "file names" such as "include\make[1]" in the generated .vcproj
> file, so
> > something seems to go very wrong with the project generation.
> >
> > If I run "make msvc" on OS X instead of cygwin, it does generate a
> _valid_
> > project file, but trying to build it throws errors about several missing
> > include files, such as "amd_internal.h" and "cholmod_internal.h" (I guess
> > the include directories are missing from the project file?), as well as
> > several other problems such as M_PI not being defined.
> >
> > Since R/igraph 1.0 seems to be based on the development verison of
> C/igraph,
> > I assume there must be a better way to compile igraph for Windows than
> > trying to fix all these manually.  Has anyone compiled the 0.8 series for
> > Windows already?  What is the right way to do it?
> >
> > Using the cygwin compiler is not an option because it introduces
> > dependencies on cygwin DLLs.  Using the MinGW compiler doesn't seem to be
> > possible because it doesn't have sys/times.h, which igraph wants to use.
> >
> > Is there any alternative solution?
> >
> > On 5 September 2015 at 13:17, Szabolcs Horvát <szhor...@gmail.com>
> wrote:
> >>
> >> My mistake was that I was looking at the sources on GitHub.  If I
> download
> >> the 0.7.1 package from http://igraph.org/c/#downloads, it (sort of)
> works
> >> with MSVC.  The 0.8.0 nightly packages for MSVC do not work.
> >>
> >> I had to do this:
> >>
> http://stackoverflow.com/questions/26579997/igraph-c-compiling-link-errors-in-visual-studio
> >> and also make sure the macro snprintf was not defined (for Visual Studio
> >> 2015).
> >>
> >> Now my question is:  How is the MSVC source package created?  How can I
> >> create such a package from the sources on GitHub, so I can used the
> weighted
> >> layout algorithms that were added since 0.7.1?
> >>
> >> On 4 September 2015 at 15:40, Szabolcs Horvát <szhor...@gmail.com>
> wrote:
> >>>
> >>> Dear All,
> >>>
> >>> Are there any precompiled packages available for Windows, usable for C
> >>> development with igraph?
> >>>
> >>> Or is there at least something that avoids having to install all of
> >>> cygwin, automake, autoconf2.5, libtool, flex, bison, etc. as described
> in
> >>> the INSTALL.WINDOWS file and allows compiling with the free Microsoft
> >>> compiler?  I'm assuming some of these tools generate source code (I
> might be
> >>> wrong) and that perhaps some of this code can be pre-generated.
> >>>
> >>> I don't have a Windows machine, and I would like to minimize the amount
> >>> of stuff that need to be installed to compile something with igraph on
> >>> another machine.
> >>>
> >>> Szabolcs
> >>
> >>
> >
> >
> > ___
> > 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] Announcement: IGraph/M, an igraph interface for Mathematica

[Szabolcs Horvát]

Dear igraph users,

I would like to announce IGraph/M, a Mathematica interface for igraph.

https://github.com/szhorvat/IGraphM

Currently (i.e. as of version 0.1), IGraph/M only provides a partial
coverage of the igraph functionality.  This package was born out of
personal need and I focused on functions I will use myself.  However, the
groundwork has been laid, and adding new functions is relatively quick and
easy.  Thus if anyone would like to contribute to the project, please
contact me.

Binary packages for OS X (10.9 or later) and Linux can be downloaded from
GitHub:
https://github.com/szhorvat/IGraphM/releases

Unfortunately I was unable to compile igraph on Windows, thus I cannot
provide a Windows version.  Contributions in this regard will be most
welcome.

Functionality in IGraph/M version 0.1 that is not yet built into
Mathematica:

 * Vertex betweenness centrality for weighted graphs
 * Estimates of vertex betweenness, edge betweenness and closeness
centrality; for large graphs
 * Minimum feedback arc set for weighted and unweighted graphs
 * Find all cliques (not just maximal ones)
 * Count 3- and 4-motifs
 * Rewire edges, keeping either the density or the degree sequence
 * Alternative algorithms for isomorphism testing: Bliss, VF2
 * Subgraph isomorphism
 * Test if a degree sequence is graphical
 * Alternative algorithms for generating random graphs with given degree
sequence
 * Layout algorithms that take weights into account

Note that IGraph/M is *not a replacement* for Mathematica's graphs and
networks functionality.  It is meant to complement what is already
available in Mathematica, thus it primarily focuses on adding functionality
that is not already present.

I should mention that there is already a small package, IGraphR <
https://github.com/szhorvat/IGraphR>, that makes igraph's R interface
accessible from Mathematica.  I started IGraph/M because I needed better
performance and reliability than what Mathematica's R interface (RLink)
could provide.

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

Re: [igraph] Easier way to compile igraph on Windows?

[Szabolcs Horvát]

My mistake was that I was looking at the sources on GitHub.  If I download
the 0.7.1 package from http://igraph.org/c/#downloads, it (sort of) works
with MSVC.  The 0.8.0 nightly packages for MSVC do not work.

I had to do this:
http://stackoverflow.com/questions/26579997/igraph-c-compiling-link-errors-in-visual-studio
 and also make sure the macro snprintf was not defined (for Visual Studio
2015).

Now my question is:  How is the MSVC source package created?  How can I
create such a package from the sources on GitHub, so I can used the
weighted layout algorithms that were added since 0.7.1?

On 4 September 2015 at 15:40, Szabolcs Horvát <szhor...@gmail.com> wrote:

> Dear All,
>
> Are there any precompiled packages available for Windows, usable for C
> development with igraph?
>
> Or is there at least something that avoids having to install all of
> cygwin, automake, autoconf2.5, libtool, flex, bison, etc. as described in
> the INSTALL.WINDOWS file and allows compiling with the free Microsoft
> compiler?  I'm assuming some of these tools generate source code (I might
> be wrong) and that perhaps some of this code can be pre-generated.
>
> I don't have a Windows machine, and I would like to minimize the amount of
> stuff that need to be installed to compile something with igraph on another
> machine.
>
> Szabolcs
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

Re: [igraph] Easier way to compile igraph on Windows?

[Szabolcs Horvát]

It seems the way to build the MSVC source package is to use "make msvc"
after ./configure.

For some reason this builds an incorrect package when I run it in cygwin. I
get "file names" such as "include\make[1]" in the generated .vcproj file,
so something seems to go very wrong with the project generation.

If I run "make msvc" on OS X instead of cygwin, it does generate a _valid_
project file, but trying to build it throws errors about several missing
include files, such as "amd_internal.h" and "cholmod_internal.h" (I guess
the include directories are missing from the project file?), as well as
several other problems such as M_PI not being defined.

Since R/igraph 1.0 seems to be based on the development verison of
C/igraph, I assume there must be a better way to compile igraph for Windows
than trying to fix all these manually.  Has anyone compiled the 0.8 series
for Windows already?  What is the right way to do it?

Using the cygwin compiler is not an option because it introduces
dependencies on cygwin DLLs.  Using the MinGW compiler doesn't seem to be
possible because it doesn't have sys/times.h, which igraph wants to use.

Is there any alternative solution?

On 5 September 2015 at 13:17, Szabolcs Horvát <szhor...@gmail.com> wrote:

> My mistake was that I was looking at the sources on GitHub.  If I download
> the 0.7.1 package from http://igraph.org/c/#downloads, it (sort of) works
> with MSVC.  The 0.8.0 nightly packages for MSVC do not work.
>
> I had to do this:
> http://stackoverflow.com/questions/26579997/igraph-c-compiling-link-errors-in-visual-studio
>  and also make sure the macro snprintf was not defined (for Visual Studio
> 2015).
>
> Now my question is:  How is the MSVC source package created?  How can I
> create such a package from the sources on GitHub, so I can used the
> weighted layout algorithms that were added since 0.7.1?
>
> On 4 September 2015 at 15:40, Szabolcs Horvát <szhor...@gmail.com> wrote:
>
>> Dear All,
>>
>> Are there any precompiled packages available for Windows, usable for C
>> development with igraph?
>>
>> Or is there at least something that avoids having to install all of
>> cygwin, automake, autoconf2.5, libtool, flex, bison, etc. as described in
>> the INSTALL.WINDOWS file and allows compiling with the free Microsoft
>> compiler?  I'm assuming some of these tools generate source code (I might
>> be wrong) and that perhaps some of this code can be pre-generated.
>>
>> I don't have a Windows machine, and I would like to minimize the amount
>> of stuff that need to be installed to compile something with igraph on
>> another machine.
>>
>> Szabolcs
>>
>
>
___
igraph-help mailing list
igraph-help@nongnu.org
https://lists.nongnu.org/mailman/listinfo/igraph-help

[igraph] Easier way to compile igraph on Windows?

[Szabolcs Horvát]

Dear All,

Are there any precompiled packages available for Windows, usable for C
development with igraph?

Or is there at least something that avoids having to install all of cygwin,
automake, autoconf2.5, libtool, flex, bison, etc. as described in the
INSTALL.WINDOWS file and allows compiling with the free Microsoft
compiler?  I'm assuming some of these tools generate source code (I might
be wrong) and that perhaps some of this code can be pre-generated.

I don't have a Windows machine, and I would like to minimize the amount of
stuff that need to be installed to compile something with igraph on another
machine.

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

Re: [igraph] ./configure won't detect GMP

[Szabolcs Horvát]

Hi Tamas,

Actually gmp.h is present in $HOME/local/include.  I'm really confused
about what is going wrong now.  Maybe there's something obvious I'm
missing?

Witness:

$ ls $HOME/local/include
gmp.h  igraph

This is part of the output from ./configure:

checking for libxml/parser.h... yes
checking for __gmpz_add in -lgmp... yes
checking gmp.h usability... no
checking gmp.h presence... no
checking for gmp.h... no
checking that generated files are newer than configure... done

So you are right that it doesn't find gmp.h

But if I crudely remove the checking part from configure.ac and force
it to try to use GMP anyway by setting gmp_support=yes, then igraph
compiles without errors and works fine.

On 2 September 2015 at 22:31, Tamas Nepusz <nta...@rmki.kfki.hu> wrote:
> Hi Szabolcs,
>
> The configure script looks for a header named gmp.h and a library that
> contains the symbol named __gmpz_add. I think that your LDFLAGS is
> okay since it contains a .dylib or .so file that contains __gmpz_add,
> but your CFLAGS variable should be like this:
>
> export CFLAGS=-I$HOME/local/include/gmp
>
> This is because gmp installs its headers in $prefix/include/gmp and
> not in $prefix/include, and igraph tries to include them with #include
> .
>
> T.
>
> T.
>
>
> On Wed, Sep 2, 2015 at 5:54 PM, Szabolcs Horvát <szhor...@gmail.com> wrote:
>> Dear All,
>>
>> I'm compiling igraph on OS X 10.10.5 using the system compiler.
>>
>> I'm trying to use GMP 6.0.0 from https://gmplib.org/, which I
>> installed into $HOME/local.  I configure igraph like this:
>>
>> export CFLAGS=-I$HOME/local/include
>> export LDFLAGS=-L$HOME/local/lib
>> ./configure --prefix=$HOME/local
>>
>> The configure script fails to detect GMP.  How can I get it to succeed?
>>
>> Notes: It does detect MacPorts's GMP if I try to use it.  It's also
>> version 6.0.0.  If I remove the part of the configure script that
>> detects GMP to trick it into thinking that it's present, igraph does
>> compile correctly, and it does work correctly (including functions
>> that use GMP).
>>
>> I don't know anything about autoconf and don't understand how it tries
>> to detect GMP ...
>>
>> Am I doing something wrong or is the GMP detection buggy?
>>
>> Szabolcs
>>
>> ___
>> 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] ./configure won't detect GMP

[Szabolcs Horvát]

Dear All,

I'm compiling igraph on OS X 10.10.5 using the system compiler.

I'm trying to use GMP 6.0.0 from https://gmplib.org/, which I
installed into $HOME/local.  I configure igraph like this:

export CFLAGS=-I$HOME/local/include
export LDFLAGS=-L$HOME/local/lib
./configure --prefix=$HOME/local

The configure script fails to detect GMP.  How can I get it to succeed?

Notes: It does detect MacPorts's GMP if I try to use it.  It's also
version 6.0.0.  If I remove the part of the configure script that
detects GMP to trick it into thinking that it's present, igraph does
compile correctly, and it does work correctly (including functions
that use GMP).

I don't know anything about autoconf and don't understand how it tries
to detect GMP ...

Am I doing something wrong or is the GMP detection buggy?

Szabolcs

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

Re: [igraph] About bliss isomorphism testing and potential bug in igraph_isomorphic_bliss

[Szabolcs Horvát]

It looks like bliss 0.73 was released since I posted this.  It also
looks like I was wrong when I said that 0.50 has things that 0.7x
doesn't.  It's just that doxygen didn't extract those classes in the
default configuration, so I thought they were not there.

On 31 August 2015 at 08:06, Szabolcs Horvát <szhor...@gmail.com> wrote:
> Dear All,
>
> I have a few questions about C/igraph and isomorphism testing using bliss.
>
> According to the documentation, igraph uses bliss 0.35
>
> http://igraph.org/c/doc/igraph-Isomorphism.html#idm470920858320
>
> * Is this accurate?
>
> If yes, is there a specific reason why igraph doesn't upgrade to more
> recent bliss?  Currently 0.50 and 0.72 are available.  0.50 seems to
> have functionality that 0.72 doesn't.  Maybe the same is the case with
> 0.35?
>
> The R/igraph documentation says that bliss doesn't support directed
> graphs: http://igraph.org/r/doc/isomorphic.html  The C/igraph
> documentation makes no such mention and the canonical_permutation
> function does return a result for directed graphs.
>
> * Does bliss support directed graphs in igraph?
>
> All igraph_bliss functions return an igraph_bliss_info_t which has the
> group_size member.
>
> * Do I need to _always_ free(group_size), even if I ran some other
> function than igraph_automorphisms()?
>
> Finally, the bliss documentation says:
>
> http://www.tcs.hut.fi/Software/bliss/doxy/classbliss_1_1Graph.html#08da370e34106cd7db479eca7c7375cc
>
> "The selected splitting heuristics affects the computed canonical
> labelings; therefore, if you want to compare whether two graphs are
> isomorphic by computing and comparing (for equality) their canonical
> versions, be sure to use the same splitting heuristics for both
> graphs."
>
> But igraph_isomorphic_bliss takes a _separate_ splitting heuristic
> argument for each of the two input graphs.  It would seem that setting
> different splitting heuristics may cause the function to return a
> wrong result.
>
>  * Is it a bug that different splitting heuristics are allowed?  Or is
> it done intentionally?
>
> Szabolcs

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

[igraph] How to tell if igraph was compiled with GMP?

[Szabolcs Horvát]

Dear All,

How can I tell if a (precompiled) version of igraph was compiled with GMP?

The results returned by some functions depend on whether they can use
GMP, so it is important to be able to tell if GMP is available.

Szabolcs

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

Re: [igraph] About bliss isomorphism testing and potential bug in igraph_isomorphic_bliss

[Szabolcs Horvát]

On 1 September 2015 at 15:25, Tamas Nepusz  wrote:
>
>> The R/igraph documentation says that bliss doesn't support directed
>> graphs: http://igraph.org/r/doc/isomorphic.html
> This seems to be the case, judging from bliss_graph.cc. Also, some
> BLISS-related functions in igraph (e.g., igraph_automorphisms) do
> mention that directed graphs are treated as undirected. However, I
> agree with you that there is a discrepancy between the C core and the
> higher level interfaces re the handling of directed graphs and this
> should be more consistent. Please file an issue for it on Github.

Indeed it doesn't support directed graphs, i.e. it treats them as
undirected.  Perhaps a warning would be in order.  Here's a transcript
of a hopefully self-explanatory Mathematica session, which directly
corresponds to how the C code works, but it was easier to try.  I
didn't have this implemented yet when I asked the question yesterday.

In[2]:= << IGraphM`

In[3]:= g1 = Graph[{1, 2, 3}, {1 <-> 2, 2 <-> 3}]; (* undirected *)

In[4]:= g2 = Graph[{1, 2, 3}, {1 -> 2, 2 -> 3}]; (* directed *)

In[5]:= g3 = Graph[{1, 2, 3}, {1 -> 2, 3 -> 2}]; (* directed, but
different from g2 *)

It won't allow comparing directed with undirected:

In[6]:= IGBlissIsomorphic[g1, g2]

During evaluation of In[6]:= IGraphM`LTemplate`LTemplate::error:
Cannot compare directed and undirected graphs
During evaluation of In[6]:= IGraphM`LTemplate`LTemplate::error: Invalid value

Out[6]= LibraryFunctionError["LIBRARY_FUNCTION_ERROR", 6]

In[7]:= IGBlissIsomorphic[g2, g2]
Out[7]= True

It says that g2 and g3 are isomorphic when they really aren't.

In[8]:= IGBlissIsomorphic[g2, g3]
Out[8]= True

igraph_isomorphic() supports directed graphs:

In[9]:= IGIsomorphic[g2, g3]
Out[9]= False

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

[igraph] About bliss isomorphism testing and potential bug in igraph_isomorphic_bliss

[Szabolcs Horvát]

Dear All,

I have a few questions about C/igraph and isomorphism testing using bliss.

According to the documentation, igraph uses bliss 0.35

http://igraph.org/c/doc/igraph-Isomorphism.html#idm470920858320

* Is this accurate?

If yes, is there a specific reason why igraph doesn't upgrade to more
recent bliss?  Currently 0.50 and 0.72 are available.  0.50 seems to
have functionality that 0.72 doesn't.  Maybe the same is the case with
0.35?

The R/igraph documentation says that bliss doesn't support directed
graphs: http://igraph.org/r/doc/isomorphic.html  The C/igraph
documentation makes no such mention and the canonical_permutation
function does return a result for directed graphs.

* Does bliss support directed graphs in igraph?

All igraph_bliss functions return an igraph_bliss_info_t which has the
group_size member.

* Do I need to _always_ free(group_size), even if I ran some other
function than igraph_automorphisms()?

Finally, the bliss documentation says:

http://www.tcs.hut.fi/Software/bliss/doxy/classbliss_1_1Graph.html#08da370e34106cd7db479eca7c7375cc

"The selected splitting heuristics affects the computed canonical
labelings; therefore, if you want to compare whether two graphs are
isomorphic by computing and comparing (for equality) their canonical
versions, be sure to use the same splitting heuristics for both
graphs."

But igraph_isomorphic_bliss takes a _separate_ splitting heuristic
argument for each of the two input graphs.  It would seem that setting
different splitting heuristics may cause the function to return a
wrong result.

 * Is it a bug that different splitting heuristics are allowed?  Or is
it done intentionally?

Szabolcs

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

[igraph] C/igraph: How to handle weighted graphs?

[Szabolcs Horvát]

Dear All,

What is the proper way to handle weighted graphs with C/igraph?

It appears that most (all?) functions that use weights take the
weights as a separate argument (and ignore them if passed NULL).  But
weights can also be stored inside the graph, as a graph attribute. Is
there any reason, other than perhaps convenience, why I should store
the weights as a graph attribute instead of a separate vector?  Do any
functions automatically use the weights stored in the graph itself?

I am working on an igraph interface for Mathematica.  I am asking this
question to make sure the choice I make will work well with all
functions, including the ones I haven't looked at yet.

Szabolcs

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

Re: [igraph] How bad an idea is to access the igraph_vector_t and igraph_matrix_t structs directly?

[Szabolcs Horvát]

I'm sorry, I realize I made a mistake and igraph does store matrices
in column major order.

On 30 August 2015 at 21:12, Szabolcs Horvát szhor...@gmail.com wrote:
 Dear All,

 The igraph_vector_t and igraph_matrix_t structs don't seem to be
 documented.  Does this mean that they are not meant to be used by end
 users and I should stick to the documented API instead of accessing
 the structs directly?

 For my use case, working with the structs is just more convenient,
 especially for matrices.  I use C++ style being and end iterators
 which seems to be stored int he struct and stor_begin and end.  I need
 to copy matrices as fast as possible in row-major order, which seems
 to be the internal storage format, while  matrix_copy_to() uses
 column-major format.

 So, to sum up: how stable is this interface and is it very risky is I
 use it directly?

 Szabolcs

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

[igraph] How bad an idea is to access the igraph_vector_t and igraph_matrix_t structs directly?

[Szabolcs Horvát]

Dear All,

The igraph_vector_t and igraph_matrix_t structs don't seem to be
documented.  Does this mean that they are not meant to be used by end
users and I should stick to the documented API instead of accessing
the structs directly?

For my use case, working with the structs is just more convenient,
especially for matrices.  I use C++ style being and end iterators
which seems to be stored int he struct and stor_begin and end.  I need
to copy matrices as fast as possible in row-major order, which seems
to be the internal storage format, while  matrix_copy_to() uses
column-major format.

So, to sum up: how stable is this interface and is it very risky is I
use it directly?

Szabolcs

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

Re: [igraph] igraph/C: is there a facility for interrupting computations?

[Szabolcs Horvát]

Hi Tamás,

Thanks for the quick response!
I just tried this and with igraph_set_interruption_handler() it works
great (already integrated with Mathematica).

Szabolcs

On 29 August 2015 at 23:03, Tamas Nepusz nta...@rmki.kfki.hu wrote:
 Hi Szabolcs,

 Not all igraph routines support interruptions, but those that do call
 a macro named IGRAPH_ALLOW_INTERRUPTION() at regular intervals. This
 macro will in turn call a so-called interruption handler, which you
 can set with the igraph_set_interruption_handler() function (see
 https://github.com/igraph/igraph/blob/master/src/interrupt.c). Within
 the interruption handler, you must check whether the host environment
 (Mathematica in your case) has signalled that the user wishes to
 interrupt the computation. (For instance, in Python, I call the
 PyErr_CheckSignals() function here). If the user wishes to interrupt
 the computation, you must call IGRAPH_FINALLY_FREE() and then return
 IGRAPH_INTERRUPTED; otherwise return IGRAPH_SUCCESS. See the Python
 interface for an example:

 https://github.com/igraph/python-igraph/blob/master/src/igraphmodule.c#L147

 I'm not sure how this translates to Mathematica - ideally, Mathematica
 should have some kind of an internal flag that is set when the user
 wishes to interrupt the computation. Your task would be to check this
 flag whenever the interrupt handler is called.

 T.

 T.


 On Sat, Aug 29, 2015 at 10:28 PM, Szabolcs Horvát szhor...@gmail.com wrote:
 Dear All,

 Does the C interface to igraph have any facility for
 aborting/interrupting computations that take very long?

 I assume it does because interrupting is possible with igraph/R.  E.g.
 the following takes a long time:

 rewire(erdos.renyi.game(1000, 0.5, 'gnp'), keeping_degseq(niter=1000))

 But pressing the stop button in R cancels it without killing the R session.

 How is this implemented?

 So far I tried setting a status handler as follows:

 int igStatusHandler(const char *, void *) { return IGRAPH_INTERRUPTED; }

 igraph_set_status_handler(igStatusHandler);

 But igraph_rewire() still runs to the finish without interruption.

 Use case: I am working on a (partial) Mathematica interface and the
 ability to interrupt would be a big usability improvement.  I was
 using igraph through the R interface from Mathematica before
 (https://github.com/szhorvat/IGraphR) but that has its limitations.

 Szabolcs

 ___
 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