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

Rewrite random forest gtests #4038

Merged
merged 10 commits into from
Jul 20, 2021
Merged

Conversation

RAMitchell
Copy link
Contributor

@RAMitchell RAMitchell commented Jul 8, 2021

Use a property based testing methodology to consolidate most of the tests an extend them to a broader range of inputs. Coverage of input parameters is significantly increased and code size is way down. The majority of tests are now generated in rf_test.cu.

Some dead code is also removed.

Testing has exposed a few bugs that should be resolved in later PRs.

  • The max_leaves parameter is not obeyed in some cases
  • Hard cuda crash for n_bins > 128, presumably due to shared memory requirements
  • Classification algorithms are sometimes not deterministic (not 100% sure if this is expected or not)

@github-actions github-actions bot added CMake CUDA/C++ Cython / Python Cython or Python issue labels Jul 8, 2021
@venkywonka venkywonka self-requested a review July 8, 2021 03:44
@hcho3
Copy link
Contributor

hcho3 commented Jul 8, 2021

property based testing methodology

Can you clarify what this means? From the quick look of it, this PR rewrites the gtests to be more like pytest, with parametrized tests and hypothesis.

@RAMitchell
Copy link
Contributor Author

Here is an article from the author of hypothesis:
https://increment.com/testing/in-praise-of-property-based-testing/

In this case I'm defining the input space of parameters and data, then using a sampling algorithm to generate (potentially many) test cases. Each time we run a test, we test the outputs for consistency.

@RAMitchell RAMitchell marked this pull request as ready for review July 9, 2021 03:56
@RAMitchell RAMitchell requested review from a team as code owners July 9, 2021 03:56
Copy link
Contributor

@venkywonka venkywonka left a comment

Choose a reason for hiding this comment

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

LGTM, awesome PR 🙏🏻
will dig into the bugs, thank you for exposing them rory 👍🏻

Copy link
Contributor

@robertmaynard robertmaynard left a comment

Choose a reason for hiding this comment

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

CMake changes LGTM

@vinaydes
Copy link
Contributor

Classification algorithms are sometimes not deterministic (not 100% sure if this is expected or not)

@RAMitchell sparsetree vectors from two forests can be different. However the actual trees should be same. This can happen because where a node is placed in the sparsetree vector is decided by an atomicAdd operation, which is not 100% reproducible.
I ran an experiment at my end and found that the mismatch was always in the left_child_id field. Which stores the index of left child in the vector. So the trees are not really different.
Are you are observing any other irreproducibility?

@dantegd dantegd added improvement Improvement / enhancement to an existing function non-breaking Non-breaking change labels Jul 12, 2021
@RAMitchell
Copy link
Contributor Author

I have limited the google tests to around 6s to not monopolise CI time.

Copy link
Contributor

@vinaydes vinaydes left a comment

Choose a reason for hiding this comment

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

Apart from the comments I made, everything looks good to go.

bool operator==(const SparseTreeNode<DataT, LabelT, IdxT>& lhs,
const SparseTreeNode<DataT, LabelT, IdxT>& rhs)
{
return (lhs.prediction == rhs.prediction) && (lhs.colid == rhs.colid) &&
Copy link
Contributor

Choose a reason for hiding this comment

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

Do we expect the floating points values such as prediction etc, match exactly?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I've disabled any checks like this for now, but in the future I don't think that's an unreasonable goal for classification.

cpp/src/decisiontree/quantile/quantile.cuh Outdated Show resolved Hide resolved
@@ -289,11 +290,6 @@ class DecisionTree {
(std::numeric_limits<L>::is_integer) ? CRITERION::ENTROPY : CRITERION::MSE;

validity_check(tree_params);
if (tree_params.n_bins > n_sampled_rows) {
Copy link
Contributor

Choose a reason for hiding this comment

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

Why is this check removed? Is it moved to some place else

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's not correct because the quantiles have already been computed at this stage, checked with @venkywonka on this. I don't necessarily see any reason to enforce nbins < nrows.

cpp/test/sg/rf_test.cu Outdated Show resolved Hide resolved
{
TestAccuracyImprovement();
// Bugs
// TestDeterminism();
Copy link
Contributor

Choose a reason for hiding this comment

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

Is classification reproducibility still a problem?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yes. The node queue using atomic needs to be reworked in a later pr I think.

@codecov-commenter
Copy link

Codecov Report

❗ No coverage uploaded for pull request base (branch-21.08@bcc4cad). Click here to learn what that means.
The diff coverage is n/a.

Impacted file tree graph

@@               Coverage Diff               @@
##             branch-21.08    #4038   +/-   ##
===============================================
  Coverage                ?   85.72%           
===============================================
  Files                   ?      230           
  Lines                   ?    18191           
  Branches                ?        0           
===============================================
  Hits                    ?    15595           
  Misses                  ?     2596           
  Partials                ?        0           
Flag Coverage Δ
dask 48.20% <0.00%> (?)
non-dask 78.16% <0.00%> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.


Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update bcc4cad...c990473. Read the comment docs.

@dantegd
Copy link
Member

dantegd commented Jul 20, 2021

@gpucibot merge

@rapids-bot rapids-bot bot merged commit 5b36ced into rapidsai:branch-21.08 Jul 20, 2021
vimarsh6739 pushed a commit to vimarsh6739/cuml that referenced this pull request Oct 9, 2023
Use a property based testing methodology to consolidate most of the tests an extend them to a broader range of inputs. Coverage of input parameters is significantly increased and code size is way down. The majority of tests are now generated in rf_test.cu.

Some dead code is also removed.

Testing has exposed a few bugs that should be resolved in later PRs.

- The max_leaves parameter is not obeyed in some cases
- Hard cuda crash for n_bins > 128, presumably due to shared memory requirements
- Classification algorithms are sometimes not deterministic (not 100% sure if this is expected or not)

Authors:
  - Rory Mitchell (https://github.com/RAMitchell)

Approvers:
  - Venkat (https://github.com/venkywonka)
  - Robert Maynard (https://github.com/robertmaynard)
  - Vinay Deshpande (https://github.com/vinaydes)
  - Dante Gama Dessavre (https://github.com/dantegd)

URL: rapidsai#4038
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
CMake CUDA/C++ Cython / Python Cython or Python issue 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.

7 participants