-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
[python-package] limit when num_boost_round warnings are emitted (fixes #6324) #6579
Conversation
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 like the general idea of this PR!
Left some minor comments below:
Co-authored-by: Nikita Titov <nekit94-08@mail.ru>
…into python/alias-warning
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 a lot for addressing my comments!
I have two more suggestions based on the most recent commit.
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 very much for working on this change!
Thanks for the thoughtful reviews @StrikerRUS ! |
@jameslamb Could you please remove python/alias-warning branch on RTD? I think we don't need to leave debug builds there. |
🙈 sorry about that, thanks for your attention to detail! Just removed it. |
Fixes #6324
Replaces #6548
num_iterations
is only raised if the user-provided configuration has conflicting valuesNotes for Reviewers
Just opening this to show I'm working on it. It still needs tests, and isn't ready for review yet.
How I tested this
Enabled this branch on readthedocs. See https://readthedocs.org/projects/lightgbm/builds/.
Isn't this kind of a lot of complexity for one parameter?
I think it's worth it. "number of boosting rounds" is one of the most important parameters for gradient boosting. I think it's worth handling it very carefully and raising an informative warning in the cases where conflicting configuration is provided. For example, I think this warning could save people from unnecessarily performing hyperparameter tuning over different combinations of
num_iterations
andnum_trees
, not understanding that those mean the same thing in LightGBM's parameters.Why not use
pytest.parametrize()
for all these tests?I started out that way, but then decided that it'd require enough if-else blocks and other logic that I was worried about accidentally, silently, mishandling some test cases.
I think the level of repetition in these test cases is ok, because it makes them easy to read and understand.