-
Notifications
You must be signed in to change notification settings - Fork 83
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
Find rows near the decision boundary #2908
Conversation
Codecov Report
@@ Coverage Diff @@
## main #2908 +/- ##
=======================================
+ Coverage 99.7% 99.7% +0.1%
=======================================
Files 302 302
Lines 28433 28587 +154
=======================================
+ Hits 28340 28494 +154
Misses 93 93
Continue to review full report at Codecov.
|
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.
@bchen1116 Thanks for this! I left some minor comments for improving the implementation and tests. I am only "blocking" because I would like to discuss whether "epsilon" is a more useful parameter than "num_rows". I think it's confusing we return all rows by default.
) | ||
assert all(vals.values == expected_vals) | ||
|
||
if types == "all": |
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.
Isn't this check redundant?
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.
This is just double-checking that we can exclude passing in y
and still get the same results
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.
Thanks for explaining!
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.
Super thorough testing. Some of the tests took me a minute to realize what exactly was being tested. Perhaps this could be remedied with maybe more specific names for the tests? I feel like test_rows_of_interest_threshold was the one that I spent the most time on. Anyway, nothing blocking. Just food for thought.
|
||
if threshold is not None and (threshold < 0 or threshold > 1): | ||
raise ValueError( | ||
"Provided threshold {} must be between [0, 1]".format(threshold) |
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.
nit: hard brackets is for inclusive, might want to switch to (0, 1).
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.
@chukarsten I was thinking we should allow the user to set the threshold as 0 or 1 if they wanted to get the rows closest to those values. What do you think?
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.
Thank you for making the changes @bchen1116 ! This looks good to me!
Address this issue
Design doc here
Walkthrough use in doc here. The link in this walkthrough should work once we publish the doc to main
API doc here