-
Notifications
You must be signed in to change notification settings - Fork 197
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
[FEA] [REVIEW] RMAT rectangular graph generator #738
[FEA] [REVIEW] RMAT rectangular graph generator #738
Conversation
…assing it as the offset
…from rmat generator
…rently in cugraph
…rmat-rectangular-generator
…e rectangular cases
…probability distributions are updated for the rectangular case
…rmat-rectangular-generator
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
CMake changes look good
@cjnolet did you mean to assign this to someone else for the review? (I'd require a review from somebody as I'm the author of this PR!) |
@teju85 I noticed awhile back that cugraph developers have been assigning the authors of the PRs to the PRs themselves as a way to quickly see the faces of the authors in the PRs. I've been doing that as well because I also find it makes it easier to browse the PR list. We don't have to do it in this case. I started looking at this PR yesterday and I'll try finishing up a review today. |
Ah I see. Makes sense. Didn't know that. Thanks for letting me know. JFYI, there's an odd failure of the unit-tests in centos. I still need to debug what's going on there. |
@gpucibot merge |
This PR introduces the core RMAT generator primitive into RAFT. It supports the following features:
[a, b; c, d]
distribution parameters at each depth.Cc += @cjnolet, JFYI.
Also Cc += @PiotrBigajNV, JFYI.
Note to the reviewers: I know we already have an RMAT generator in cuGraph then why did we have to "duplicate" it in RAFT!? The reason here is that RAFT needs to generate such sparse graphs/adjacency matrices for benchmarking and unit-testing its sparse primitives. Similarly cugraph-ops will also need to do the same in its benchmarks/tests. We cannot introduce cuGraph as a dependency for these things. Hence, this PR. Also, the primitive here is very basic. It only generates the directed edgelist with possible duplicate edges. So, the caller still needs to do this post-processing if/when required. This means, if we are still worried about code duplication, this core logic of cuGraph can be replaced by a call to the proposed API in this PR. I also know that the missing thing here is the
clip_and_flip
feature of cuGraph. It will be added soon.