Two new algorithms for cycles and extension of cycle_basis

[kakila]

I have merged my algorithms with networkx. I tried to follow coding standards by looking at other files.
I have added tests.
I would like to know how to create demos to show the use of cycle_basis and cycle_basis_matrix to generate Kirchhof equations for a given circuit (directed multigraph).

Thanks

[dschult]

I think an example demonstrating how to work with a given circuit could go into examples/algorithms.

[dschult]

here are some questions... feel free to answer "yes, I think this is best". I'm not saying it isn't, I'm just asking.

Does chords() require finding a spanning tree or a minimum spanning tree? Which would be better?

There are many e[:2] and e[:2][::-1] used in cycle_basis_matrix. I think I see why -- to handle multigraphs which have 3-tuples for edges. The code returns the node-tuple or its reverse. Would it be cleaner to split "e" into the nodes, or does that require more convolutions?

You had some tests at the end of your original script. Did all those tests get transferred over to test_cycles?

In the docs for chords() you should specify that the output objects are networkx graphs. Is that what you want or would it be better to return sets of edges?

Looks good! Thanks,
Dan

[kakila]

Does chords() require finding a spanning tree or a minimum spanning tree? Which would be better?
I do not remember exactly why I used minimum spanning tree. Let me check ...

There are many e[:2] and e[:2][::-1] used in cycle_basis_matrix. I think I see why -- to handle multigraphs which have 3-tuples for edges. The code returns the node-tuple or its reverse. Would it be cleaner to split "e" into the nodes, or does that require more convolutions?
I am not sure I understand what you mean. Indeed I am checking the order of the edge because I assumed directed graphs are allowed.

You had some tests at the end of your original script. Did all those tests get transferred over to test_cycles?
No, some of my test where equivalent to the ones already in place in the tests for cycle_basis. So I skipped those. I did not have tests for chrods cause I alsways thought of it as an private function...if it is not useful for the user one could rename it to chords

In the docs for chords() you should specify that the output objects are networkx graphs. Is that what you want or would it be better to return sets of edges?
Since the two graphs are then used as networkx graphs I prefer to return that. I will improve the docs (in my repository? I do not understand how this thing works...is my repo synchronized with the repo of networkx?)

[dschult]

I believe the pull request is just a pointer to your repository. If you
push to the branch in your github repository that you made the request from
it adds that commit to the pull request automatically.

It is also true that others cannot change the pull request directly. We
can make pull requests to your branch on your fork. Then you would have to
merge them to have them show up in the pull request. So that's why I think
of it as a pointer to your branch on your fork. But I'm still learning
about github....

My question about the e[:2][::-1] notation is this: Could this be done
with something like:
try:
u,v=e
except ValueError:
e,v,k=e
e_nodes=(u,v)
e_nodes_reversed=(v,u)
and then you wouldn't have to use double subscripts. But looking at what I
just wrote, it seems ugly too. Is there a better way?

Dan

On Sun, Mar 2, 2014 at 4:31 PM, Juan Pablo Carbajal <
notifications@github.com> wrote:

Does chords() require finding a spanning tree or a minimum spanning tree?
Which would be better?
I do not remember exactly why I used minimum spanning tree. Let me check
...

There are many e[:2] and e[:2][::-1] used in cycle_basis_matrix. I think I
see why -- to handle multigraphs which have 3-tuples for edges. The code
returns the node-tuple or its reverse. Would it be cleaner to split "e"
into the nodes, or does that require more convolutions?
I am not sure I understand what you mean. Indeed I am checking the order
of the edge because I assumed directed graphs are allowed.

You had some tests at the end of your original script. Did all those tests
get transferred over to test_cycles?
No, some of my test where equivalent to the ones already in place in the
tests for cycle_basis. So I skipped those. I did not have tests for chrods
cause I alsways thought of it as an private function...if it is not useful
for the user one could rename it to chords

In the docs for chords() you should specify that the output objects are
networkx graphs. Is that what you want or would it be better to return sets
of edges?
Since the two graphs are then used as networkx graphs I prefer to return
that. I will improve the docs (in my repository? I do not understand how
this thing works...is my repo synchronized with the repo of networkx?)

Reply to this email directly or view it on GitHubhttps://github.com//pull/1067#issuecomment-36467749
.

[kakila]

I have improved chords, added tests and used names of the edge and reversed edged as suggested by Dan.

Regarding spanning trees. I think I used minimum_spanning_tree because I could not find the algorithm to calculate any one spanning tree. Is there an efficiency overhead due to minimum_spanning_tree? Is there a better algorithm to get just one of the spanning trees?

[kakila]

I have added an example to the example/algorithms folder. I hope now the merge can be executed.

Let me know if there is anything missing.

[kakila]

Pinging this request. Is there anything I can do to facilitate the merge?

Thanks

[harrymvr]

To get a single spanning tree, you can just run a BFS. To sample a spanning tree according to its weight, there is a really nice algorithm [1]. You can read the paper here. I might implement it in the near future myself.

[1] Wilson, David Bruce. "Generating random spanning trees more quickly than the cover time." Proceedings of the twenty-eighth annual ACM symposium on Theory of computing. ACM, 1996.

[kakila]

Thank you for your answer.
I will not be able to implement this algorithm in the near future.
Is there any reason not to merge the current changes?

[hagberg]

The tests are still failing. Fixing those is necessary to do the merge.

I think the rest needs a careful review and likely some adjustments.

I'd also like to see scipy sparse matrices used. That is what we are now using (or intend to change) in the rest of the NetworkX package.

[kakila]

The failing tests seem to be related to older versions of python. Who can one check the offending commands?

[kakila]

Regarding, sparse matrices. I will implement this in the future, it is marked as a todo in the code. Is this a reason not to merge the code?

[hagberg]

The scipy import needs protection from when the module isn't found (scipy is not required).
See e.g. pagerank_alg.py for how to do that.

[hagberg]

Well, the future is now! So might as well get it implemented with scipy.sparse matrices so we don't have to go and fix it later.

[kakila]

Well, the future is now!

Assuming you have the time, yes. I will see what I can do. Though I would ask you to merge this and then improve. Maybe there are useful reports if people use this code.

[kakila]

Apparently the problem with Travis is that the tests are importing scipy to compare the results.
If the algo is returning a numpy array, how can I assert their equality without importing numpy or scipy?

[kakila]

Ok, Travis is happy now.

[ysitu]

What is the status of this PR?

[chebee7i]

It looks like it could use a bit more editing. But I suspect that duties took the author elsewhere, so we might have to tackle them.

[kakila]

At the moment I am in holidays.
If you have specific guidelines about what should be edited, I will be
happy to do it, if I can, when I return.

On Wed, Aug 6, 2014 at 12:34 AM, chebee7i notifications@github.com wrote:

It looks like it could use a bit more editing. But I suspect that duties
took the author elsewhere, so we might have to tackle them.

—
Reply to this email directly or view it on GitHub
#1067 (comment).

[jfinkels]

I can take a look at this.

[jfinkels]

Some comments.

1. The chords() function might be simpler with an edge-induced subgraph function (see edge_subgraph() (migrated from Trac #333) #330). For example:

   chords = G.edge_subgraph(e for e in G.edges() if e not in T.edges())
   

2. There should be a fundamental_cycles function that takes a graph and a spanning tree, and returns the fundamental cycles of the graph with respect to that particular tree. Following the above example,

   fundamental_cycles = [[(u, v)] + nx.shortest_path(T, v, u) for u, v in chords]
   

3. These functions should allow the user to specify a spanning tree that has already been computed. For example, I may want to construct a low-stretch spanning tree, as suggested by @harrymvr, then get the set of fundamental cycles with respect to that spanning tree.

I'm about to open a new pull request that makes some style and documentation fixes, and partially implements item 3. Some tests are still missing.

[hagberg]

See #1538