-
-
Notifications
You must be signed in to change notification settings - Fork 8.7k
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
Added SKL-like random forest Python API. #4148
Conversation
- added XGBRFClassifier and XGBRFRegressor classes to SKL-like xgboost API - also added n_gpus and gpu_id parameters to SKL classes - added documentation describing how to use xgboost for random forests, as well as existing caveats
- introduced new parameters to XGBRanker - also passing **kwargs further in XGBRanker.__init__
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.
Because many of our internal parameters can be subject to change I do not like to bake them all into the Python API. Parameters such as 'gpu_id' can be passed as kwargs. I don't think this PR should require any changes to the actual function arguments.
As mentioned before, I do not like the use of self.mode to change behaviour, I think this should be handled via polymorphism.
- removed the n_gpus and gpu_id parameters - removed the mode parameter, using subclass methods instead - small fixes
I've removed I've also removed |
@trivialfis can I get your review. @canonizer xgboost's default tree_method is currently 'exact'. This PR would change the sklearn interface to use 'hist' as the default. This would be a huge change for our user base. Arguably we should in fact make this change, but that is a big decision and that we need some internal discussion on. |
@RAMitchell Will review shortly. |
@RAMitchell @hcho3 WDYT? |
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.
I think we can't remove the 'silent' parameter yet. Given that this is a public API we should continue to support the parameter alongside 'verbosity' and issue a deprecation warning for at least a few subsequent releases.
Have you manually checked the python documentation @canonizer? It would be good to check if this formats correctly on your local machine.
I am also wondering if we can somehow mark the RF extension to the API as experimental to give ourselves some room to modify it in the near future. @hcho3 WDYT?
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.
LGTM. Yes, let’s mark them experimental so that we can fix API design as necessary.
I will make a separated PR for marking this experimental later. Let's merge it now. @canonizer @RAMitchell @hcho3 . |
#4255 brings back the silent parameter and marks it deprecated. |
as well as existing caveats