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 <[email protected]> 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, <[email protected]> wrote: > >> >> Message: 2 >> Date: Fri, 4 Dec 2015 14:57:25 +0100 >> From: Tamas Nepusz <[email protected]> >> To: Help for igraph users <[email protected]> >> Subject: Re: [igraph] igraph and python3 >> Message-ID: >> <CABsfaEQEbjscGY=_SVYp_0dDruU2r+i9=_ >> [email protected]> >> 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 <[email protected]> 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 >> > [email protected] >> > https://lists.nongnu.org/mailman/listinfo/igraph-help >> > >> >> >> >> ------------------------------ >> >> Message: 3 >> Date: Fri, 4 Dec 2015 15:13:57 +0000 >> From: "Hadidi, Lars" <[email protected]> >> To: Help for igraph users <[email protected]> >> Subject: Re: [igraph] Performance issue on dymanic networks >> Message-ID: <[email protected]> >> 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: [email protected] >> <[email protected]> im >> Auftrag von Tamas Nepusz <[email protected]> >> 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 >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/igraph-help >> >> >> >> ------------------------------ >> >> _______________________________________________ >> igraph-help mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/igraph-help >> >> >> End of igraph-help Digest, Vol 113, Issue 2 >> ******************************************* >> > >
_______________________________________________ igraph-help mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/igraph-help
