[python-package] limit when num_boost_round warnings are emitted (fixes #6324)#6579
[python-package] limit when num_boost_round warnings are emitted (fixes #6324)#6579
Conversation
StrikerRUS
left a comment
There was a problem hiding this comment.
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
StrikerRUS
left a comment
There was a problem hiding this comment.
Thanks a lot for addressing my comments!
I have two more suggestions based on the most recent commit.
StrikerRUS
left a comment
There was a problem hiding this comment.
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. |
|
This pull request has been automatically locked since there has not been any recent activity since it was closed. |

Fixes #6324
Replaces #6548
num_iterationsis 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_iterationsandnum_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.