Track vertex and edge order and multiedge key to/from networkx#408
Closed
iosonofabio wants to merge 3 commits intoigraph:masterfrom
Closed
Track vertex and edge order and multiedge key to/from networkx#408iosonofabio wants to merge 3 commits intoigraph:masterfrom
iosonofabio wants to merge 3 commits intoigraph:masterfrom
Conversation
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 14 days if no further activity occurs. Thank you for your contributions. |
iosonofabio
added a commit
to iosonofabio/python-igraph
that referenced
this pull request
Sep 16, 2021
5 tasks
ntamas
added a commit
that referenced
this pull request
Sep 28, 2021
…orkx) (#434) * First pass, poor docs * Forgot classmethod decorator * Some polishing and one more input constructor * Graph constructor from pandas adjacency matrix * Move adjacency constructors to module * Move more constructors to dedicated module * Clean up namespace at the end * Small constructor modules * IO module * fix: remove licenses from igraph.io, it is enough to have it in __init__.py * refactor: prefix names of internal functions in igraph.io with an underscore * refactor: moved _first to igraph.utils * style: blackened igraph.io source * Export to dict of sequences * Recover and refine lost PR on use_vids * Match export graph functions for dict/list/tuple types * Include PR #408 in this one * Docstrings and documentation * Bugfix on dict-dict * Implement most of Vincent's suggestions * Running local tests helps... sigh * style: nitpicking, probably ready to merge Co-authored-by: Tamas Nepusz <ntamas@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Improve conversions to/from networkx by using hidden vertex/edge attributes:
_nx_namewas already there: it stores the hashable used to identify the vertex innetworkxafter converting toigraph_nx_multiedge_keykeeps track ofnetworkx's edge key, which is used to distinguish multiedges_igraph_indexis now set when exporting tonetworkxto remember the order of vertices/edges in igraph (networkxdoes not have a strictly enforced order)The first two attributes are checked on the way back from
igraphintonetworkxto set proper vertex names and edge keys, respectively. The last attribute is used on the way back fromnetworkxtoigraphto sort edges according to their original order, or whatever comes closest to that.Of course, manual manipulations of these attributes by the users can mess up the bookkeeping. That's ok I think, they know what they're getting themselves into since the attribute names start with _ which in Python is lingo for "don't touch!".
An interesting case is if e.g. the user exports an
igraphgraph tonetworkx, thins it out by deleting a few edges, and then converts back. Then the order of edges is maintained except the missing edges are skipped, of course.@szhorvat @ntamas would be great if you could take a look and let me know your thoughts. I've had to adapt CI tests a little, which highlighted some bugs that are now fixed.
edit: I found one more bug. ig -> nx -> delete a vertex -> ig will probably error out. Fixed now.
edit2: There must be a bug when ig -> nx -> add vertices/edges -> ig because the newly added objects cannot have an
_igraph_index. They should be defaulted to a (random?) increasing_igraph_indexI guess, but that might or might not be deterministic since they were generated in the context of a nondeterministic library...