Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Union, intersection, etc. (?) based on an attribute #20

Closed
12 tasks done
gaborcsardi opened this issue May 4, 2013 · 3 comments
Closed
12 tasks done

Union, intersection, etc. (?) based on an attribute #20

gaborcsardi opened this issue May 4, 2013 · 3 comments
Assignees
Labels
high High-priority issue; typically for cases when igraph returns incorrect result for non-corner cases
Milestone

Comments

@gaborcsardi
Copy link
Contributor

At least, there should be methods for union and intersection, based on a vertex attribute.


Imported from Launchpad using lp2gh.

Code:

  • graph.disjoint.union
  • graph.union
  • graph.intersection
  • graph.difference
  • graph.compose
  • what should "+" do for named graphs? union or disjoint union?
  • warning for non-unique vertex names after a disjoint union

Docs:

  • graph.disjoint.union
  • graph.union
  • graph.intersection
  • graph.difference
  • graph.compose
@gaborcsardi
Copy link
Contributor Author

(by gabor.csardi)
We have some R code now in the 0.6-main tree, contributed by Magnus Torfason

@gaborcsardi
Copy link
Contributor Author

(by gabor.csardi)
After some failed attempts, as I see these are the possible solutions to this issue:

Extend/redesign the attribute handler to make it more flexible, because right now we cannot express that we are merging and combining attributes from multiple graphs, possibly with renaming them.

This is not very clean, a bigger piece of work, and unclear where else we could actually use the new, fairly difficult attribute API functions.


Implement the whole thing in R/Python, independently of the C level. This is not really the igraph way, but attributes are probably not really used from C, anyway. Also, it might be slower. The good thing is that for R the code by Magnus is a very good starting point.


Probably the winner. Add an optional argument to the C functions, that allows the tracking of the edges. Everything everything else in R/Python.

E.g. for intersection a possible implementation might do the following:
1) in R, delete vertices that are not present in all graphs (based on named, obviously)
2) permute the vertices in these subgraphs, so that the same symbolic vertices have the same internal ids
3) call the plain C intersection function, this would return the mapping for tracking the edges
4) copy and rename all the graph attributes to the result graph
5) copy and rename all vertex attributes to the result graph, this is easy, because the vertex ids map to names the same way in all permuted subgraphs .
6) copy and rename all edge attributes to the result graph, based on the tracking information returned by the C function.

@ghost ghost assigned gaborcsardi May 7, 2013
@gaborcsardi
Copy link
Contributor Author

A lot of work was done in the 0.7-ropbyname branch.

gaborcsardi added a commit that referenced this issue Oct 1, 2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
high High-priority issue; typically for cases when igraph returns incorrect result for non-corner cases
Projects
None yet
Development

No branches or pull requests

1 participant