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

Moving remaining stats prims from cuml #507

Merged

Conversation

cjnolet
Copy link
Member

@cjnolet cjnolet commented Feb 10, 2022

No description provided.

@cjnolet cjnolet added improvement Improvement / enhancement to an existing function non-breaking Non-breaking change labels Feb 10, 2022
@cjnolet cjnolet requested review from a team as code owners February 10, 2022 22:05
Copy link
Member

@divyegala divyegala left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just one comment. Looks very good!

/**
* @brief Implementation of 'Seive of Eratosthenes'
*/
class Seive {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this class have a detail::SeiveImpl which has the implementation, and the public API be class Seive :: public detail::SeiveImpl?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still thinking through how to hide the common/utilities stuff, and whether we should. This Seive is used internally in one place so far and it might be that we just end up making it internal. For now, though I don't think it should affect this PR.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

(I'd love to gather your thoughts on the utilities as well)

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think whether it's an internal or external common/utility source, the consistency of having the implementation hidden in detail helps a developer to know where, if ever, they need to look for source code of implementation. The API again just being a contract whether it's internal or external.

Copy link
Member Author

@cjnolet cjnolet Feb 11, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The benefit to hiding internals such as what we've been doing is so that we make a contract with the outside world and know that if we don't break that contract, consumers should be able to build against RAFT. I'm less concerned internally because we will get build errors when things change. I think there is still a level of caution that we can take, but it's not going to require we protect the contract as strongly as w/ the public (external) APIs.

The problem with many of these files w/ utility functions is that there are no "internal" bits- the functions themselves are all external so we don't gain as much by hiding those bits. This is my perspective anyways. I'm still undecided on exactly what we should do. One part of me thinks we should eventually copy the public utils stuff into a raft/utils directory and deprecate the old ones and call it a day. I think we should revisit after moving over the primitives, since those are more of the core focus.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sounds good. It of course doesn't matter much when it's just an internal function, and my only point as a dev was that I would know where to find the implementation if I had to.

Apart from that, I'm fully onboard for the raft/utils package. The utils in the root directly are a bit of a mess and they can be cleaned significantly. But yes, not the highest priority!

Copy link
Member

@divyegala divyegala left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@cjnolet
Copy link
Member Author

cjnolet commented Feb 11, 2022

rerun tests

@cjnolet
Copy link
Member Author

cjnolet commented Feb 11, 2022

@gpucibot merge

@rapids-bot rapids-bot bot merged commit 4c089f6 into rapidsai:branch-22.04 Feb 11, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CMake cpp improvement Improvement / enhancement to an existing function non-breaking Non-breaking change
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants