-
Notifications
You must be signed in to change notification settings - Fork 430
feat: make Csr::from_sorted_edges generic over edge type
#783
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
feat: make Csr::from_sorted_edges generic over edge type
#783
Conversation
Csr::from_sorted_edges generic over edge typeCsr::from_sorted_edges generic over edge type
|
I think this was done some times ago due to the requirements of unambiguity of the edge order. |
|
What I noticed when using CSRs for undirected graphs is that edges have to be present in both directions for |
4b41b80 to
a2b5892
Compare
a2b5892 to
5baf298
Compare
Let's do that. |
5baf298 to
7d21f27
Compare
7d21f27 to
2726f3c
Compare
|
Since this PR seems stale, I was wondering if it would be alright if I would pick it up. That is, fork your branch and finish it such that your work gets merged : ) |
bb207b2 to
26f106a
Compare
|
Sorry for the delay. I added a note to the documentation. |
26f106a to
b6f7190
Compare
No worries at all :) Alright, I see 🤔 I'll look into it then and prob take over the PR 👍 I appreciate the quick response |
|
Okay, I will close this in favor of #861 then : ) |
… increase edge_count in Csr::from_sorted_edges (#861) This PR continues the work done in #783. Thus, this resolves #588. The trait bound on the `Csr` to be `Directed` for `from_sorted_edges` was lifted. Thus, it was noticed that at no point in `from_sorted_edges`, the `edge_count` is increased. This is only relevant for `Undirected` graphs, as `Directed` graphs use their `self.column.len()` as the `edge_count()` under the hood. --------- Co-authored-by: Jan Baudisch <jan.baudisch@uni-ulm.de>
… increase edge_count in Csr::from_sorted_edges (petgraph#861) This PR continues the work done in petgraph#783. Thus, this resolves petgraph#588. The trait bound on the `Csr` to be `Directed` for `from_sorted_edges` was lifted. Thus, it was noticed that at no point in `from_sorted_edges`, the `edge_count` is increased. This is only relevant for `Undirected` graphs, as `Directed` graphs use their `self.column.len()` as the `edge_count()` under the hood. --------- Co-authored-by: Jan Baudisch <jan.baudisch@uni-ulm.de>
… increase edge_count in Csr::from_sorted_edges (petgraph#861) This PR continues the work done in petgraph#783. Thus, this resolves petgraph#588. The trait bound on the `Csr` to be `Directed` for `from_sorted_edges` was lifted. Thus, it was noticed that at no point in `from_sorted_edges`, the `edge_count` is increased. This is only relevant for `Undirected` graphs, as `Directed` graphs use their `self.column.len()` as the `edge_count()` under the hood. --------- Co-authored-by: Jan Baudisch <jan.baudisch@uni-ulm.de>
I am not sure if there was a reason for the constraint, but it seems to work fine for undirected graphs.
Fixes #588.