igraph-help
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [igraph] igraph and python3


From: Nate Reed
Subject: Re: [igraph] igraph and python3
Date: Sat, 5 Dec 2015 08:12:54 -0600

Fixed by installing the python-igraph package. This recompiled the interface for python3. Thanks for the tip, Tamas.

On Sat, Dec 5, 2015 at 8:05 AM, Nate Reed <address@hidden> wrote:
It is picking up the igraph package in python 3's site-packages:

>>> import igraph
>>> print(igraph.__file__)
/Library/Frameworks/Python.framework/Versions/3.4/lib/python3.4/site-packages/igraph/__init__.py

It was installed using pip3. 

On Fri, Dec 4, 2015 at 11:00 AM, <address@hidden> wrote:


Message: 2
Date: Fri, 4 Dec 2015 14:57:25 +0100
From: Tamas Nepusz <address@hidden>
To: Help for igraph users <address@hidden>
Subject: Re: [igraph] igraph and python3
Message-ID:
        <CABsfaEQEbjscGY=_SVYp_0dDruU2r+i9=_address@hidden>
Content-Type: text/plain; charset=UTF-8

igraph is supported with Python 3, but it has to be compiled and
installed separately for Python 2.x and for Python 3.x. It seems like
in your case it is installed only for Python 2.x and typing "import
igraph" in Python 3.x imports some other file instead.

Try running "import igraph; print igraph.__file__" in Python 3.x to
figure out what file is imported as "igraph" in Python 3.x.

T.
T.



On Fri, Dec 4, 2015 at 2:35 PM, Nate Reed <address@hidden> wrote:
> I wrote a Python 2.7 script that uses igraph, but when I tried running in
> Python 3, it fails as follows:
>
>>>> from igraph import *
>>>> g = Graph(directed=True)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> NameError: name 'Graph' is not defined
>
> Is Python 3 supported? Is there documentation on use of igraph with Python3?
>
> Thanks,
> Nate
>
> _______________________________________________
> igraph-help mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/igraph-help
>



------------------------------

Message: 3
Date: Fri, 4 Dec 2015 15:13:57 +0000
From: "Hadidi, Lars" <address@hidden>
To: Help for igraph users <address@hidden>
Subject: Re: [igraph] Performance issue on dymanic networks
Message-ID: <address@hidden>
Content-Type: text/plain; charset="iso-8859-1"

Thank you for your support.

I will try to adjust the eps-value which has been set to std::numeric_limits<double>::epsilon() in my case.

Sincerely,

Lars

________________________________________
Von: igraph-help-bounces+lhadidi=address@hidden <igraph-help-bounces+lhadidi=address@hidden> im Auftrag von Tamas Nepusz <address@hidden>
Gesendet: Mittwoch, 2. Dezember 2015 15:36
An: Help for igraph users
Betreff: Re: [igraph] Performance issue on dymanic networks

Hello Lars,

> yes I do use weights, and they are indeed not integers but floating point values.
In that case, try to use a non-zero "eps" value; set it to some small
number instead, e.g., 1e-6. The reason is that in the Hungarian
algorithm, there are cases when one has to decide whether a (real or
phantom) edge is "tight", where "tight" means that the sum of the
labels of its two endpoints is equal to the weight of the edge.
However, in floating-point arithmetics, it may happen that the
equality check fails even if it would be true in reality; for
instance, try this in Python:

>>> 0.1 + 0.2 == 0.3
False

(See http://0.30000000000000004.com/ for more details).

That's why igraph uses a tolerance threshold of 'eps' where an edge is
considered tight if the sum of the labels of its two endpoints minus
the weight of the edge is less than 'eps' in absolute value. If you
use eps=0 and the weights are not integers, some edges that are tight
might not be considered tight by the algorithm. If you use a value of
eps that is too large, then some non-tight edges might be considered
tight. Both options could lead to suboptimal solutions, but I think
that eps being equal to a small positive number such as 1e-6 should be
fine.

> Could you provide me an outline of how it is done in igraph's case, maybe just a reference to a paper or a book,  according to the implementation in your library.

The implementation in igraph uses the original graph data structure
plus an additional adjacency list that contains the tight phantom
edges that appeared during the course of the algorithm. That's the
only trick if I remember correctly. The additional (dummy) entries of
the matrix are not stored.

For what it's worth, I think that the implementation in igraph could
actually be improved a bit. Right now the problem is that we have an
O(n^2) loop where we update the set of tight phantom edges - this is
done by examining all possible pairs of vertices from the two parts of
the graph. I think we could do better there by re-checking only those
vertices where the label of the vertex was adjusted in the last
iteration.

All the best,
T.

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



------------------------------

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


End of igraph-help Digest, Vol 113, Issue 2
*******************************************



reply via email to

[Prev in Thread] Current Thread [Next in Thread]