You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
add_edge_list of class Graph (in c_graph.pyx) calls gdf_edge_list_view and add_adj_list calls gdf_adj_list_view.
gdf_edge_list_view does not check there already exists an adjacency list representation and gdf_adj_list_view does not check there already exists an edge list representation. If both are called representing two different graphs, it is unclear what num_vertices of class Graph should return (current it returns the number of vertices in the adjacency list).
Expected behavior
There are two options. If the graph instance already holds a graph, 1) we may allow only conversion between formats. 2) Alternatively, we may delete an existing graph (including graph representations in different formats) before adding a new one.
The text was updated successfully, but these errors were encountered:
The current version has the following advantage: if a user has both adj_list and edge_list already, the user can provide it directly without running any conversion.
However, I agree that this can be misused to store different graphs in the same object. In this case, I think the first solution you proposed is a good fix.
Users may not have both edge_list and adj_list from the beginning, but they may convert one format to another using CPU to get both. We may better advise users to do conversion in GPU, and implementing option 1 may be able to facilitate users to do conversion in GPU. We may also add conversion functions to the python API. Currently, we have exposed only the conversion function from COO to CSC (add_transpose) in the Python API. Other conversions occur implicitly. And it can be quite non-intuitive to users that just querying the number of vertices (calling num_vertices()) can invoke COO to CSR conversion (which takes time and requires additional memory). We may better compute num_vertices from COO if CSR is not available (and cache the computed value) or compute num_vertices when add_edge_list is called. This could be another [FEA]ture issue if this is worth implementing.
PR updates RAFT's CMake and uses CPM for dependency management. Still WIP, meant for early 0.20, but opening the PR to start debugging in CI.
This is heavily based on cuDF's, RMM's and cumlprims' changes. PR does the following:
- [x] Adopt CPM:
- [x] RMM
- [x] FAISS
- [x] GTest
- [ ] NCCL: Missing building from source, will be added if/when required
- [ ] UCX: Missing building from source, will be added if/when required
- [x] CUB for CUDA < 11.0
- [x] Update arch detection
- [x] Use generators to allow clang compilation as well
- [x] Updates to outdated cmake parts and remove old code
- [x] Update code to aid transition to rapidsai#83
Authors:
- Dante Gama Dessavre (https://github.com/dantegd)
- Robert Maynard (https://github.com/robertmaynard)
Approvers:
- Robert Maynard (https://github.com/robertmaynard)
- Rick Ratzel (https://github.com/rlratzel)
- Divye Gala (https://github.com/divyegala)
URL: rapidsai/raft#187
Describe the bug
add_edge_list of class Graph (in c_graph.pyx) calls gdf_edge_list_view and add_adj_list calls gdf_adj_list_view.
gdf_edge_list_view does not check there already exists an adjacency list representation and gdf_adj_list_view does not check there already exists an edge list representation. If both are called representing two different graphs, it is unclear what num_vertices of class Graph should return (current it returns the number of vertices in the adjacency list).
Expected behavior
There are two options. If the graph instance already holds a graph, 1) we may allow only conversion between formats. 2) Alternatively, we may delete an existing graph (including graph representations in different formats) before adding a new one.
The text was updated successfully, but these errors were encountered: