-
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
[R-package] added support for first_metric_only (fixes #2368) #2912
Conversation
I think we should only use one label in https://github.com/microsoft/LightGBM/blob/master/.github/release-drafter.yml |
ah ok yep, I agree! Still getting used to the release drafter. Thanks! |
70a1c64
to
68e7840
Compare
I am going to get this PR updated this week. I want to get it and a few others into 3.0.0 (#3071 ) and I know we want to do a release as soon as possible. I'll fix the merge conflicts tonight and update it to |
ok I think this is ready for a review! This is ready to be reviewed, but since it is a new feature, this PR should not be merged until after 3.0.0 is released (#3293 ) |
@jameslamb It seems R's tests often failed, is that normal? |
yeah unfortunately it's because there isn't a proper package manager for some of the artifacts we download, like Rtools and MiKTeX. So you see a lot of issues like this: I know @StrikerRUS has mentioned it in the past...is there a place we could self-host these that might be more reliable? At least for things that are never changing (like |
Maybe our GitHub Releases page? Line 31 in ca066d4
|
is it ok if I host things directly on that specific release (2.0.12)? I don't think it will be too confusing for users, since that is such an old release. And that seems like the easiest free option. Otherwise, maybe Microsoft could cover the costs of a small Azure Blob Store container for this project's CI. |
@jameslamb |
Yeah, I believe old releases are perfect places to store some files required for our CI. |
ok added #3359 with these artifacts, let's move the conversation there |
This pull request has been automatically locked since there has not been any recent activity since it was closed. To start a new related discussion, open a new issue at https://github.com/microsoft/LightGBM/issues including a reference to this. |
This PR attempts to add support for
first_metric_only
in the R package.This got complicated because of some inconsistencies in the way we describe what you can specify for
eval
. From the existing docs and from the Python side (#2049, #2209), I think we want to support the following combinations:eval
NULL
or empty list to say "no additional evaluation metrics"metric
"None"
to say "no metric"...where "string" or "character" stuff in that list refers to these metrics which are known to LightGBM and computed on the C++ side (https://lightgbm.readthedocs.io/en/latest/Parameters.html#metric)
I believe I've accomplished that in this PR. At this point I'm far enough along that I could use a review.
I know there are some items that still need to be addressed, but want to wait for review comments before going too much farther and growing the diff.
lightgbm.cv()
+ tests onlightgbm.cv()
eval
are consistent acrosslgb.train()
,lightgbm()
, andlgb.cv()
NOTE: I fixed a bug inlgb.params2string()
along the way here. I think I'll move that to a different PR, so it doesn't get stuck in this review and so this diff gets a bit smaller.