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

custom evaluation function is not used if name is lexicographically smaller than default #4421

Closed
JaakobKind opened this issue Apr 30, 2019 · 7 comments · Fixed by #4638
Closed

Comments

@JaakobKind
Copy link

Dear xgboost developers,
I have found the following issue.
When I try to use a custom evaluation function, it is only working when I either use parameter disable_default_eval_metric or choose a name for my evaluation metric that is lexicographically larger than the name of the default metric.
If you know these workarounds, they are acceptable, but it took me some time to find out how to overcome the issue. Hence, it would be nice if this bug could be fixed.
I have attached a jupyter notebook that can be used to reproduce the bug. I needed to zip it to be able to upload it -:)

xgboost_bug.zip

@JaakobKind
Copy link
Author

Additional info: I use xgboost 0.82.
I checked whether I get the same issue in R and was not able to reproduce it there. Hence, it seems only to occur in the python version.

@trivialfis
Copy link
Member

@JaakobKind Sorry for late reply, will look into this.

@trivialfis
Copy link
Member

@hcho3 Can I borrow some help here? What's the convention for early stopping when multiple evaluation metrics are used? Monitor one of them or all of them?

@hcho3
Copy link
Collaborator

hcho3 commented May 22, 2019

@trivialfis The convention is to always use the first metric for early stopping

@JaakobKind
Copy link
Author

What is the meaning of "first" here? I hope that it is not lexicographic order of the metric name.

hcho3 added a commit to hcho3/xgboost that referenced this issue Jul 4, 2019
…and always use last metric for early stopping
@hcho3
Copy link
Collaborator

hcho3 commented Jul 4, 2019

@JaakobKind It turns out that there was a bug that caused the metrics to be ordered in lexicographical order. #4638 recovers the originally intended semantics, where the last validation set and last evaluation metric are used for early stopping. (Here "last" means the exact order the user specifies the list of validation sets and metrics.)

Also, #4638 clarifies how early stopping works when multiple validation sets and metrics are given.
Preview: https://hcho3-xgboost.readthedocs.io/en/fix_early_stopping_python/python/python_api.html#xgboost.train

@trivialfis Sorry I was mistaken earlier. It was actually the last metric that should be used for early stopping. I clarified the exact behavior of early stopping in the Python API doc (#4638).

@hcho3
Copy link
Collaborator

hcho3 commented Jul 4, 2019

@JaakobKind And if a customized metric function is added, it will always be added after built-in metrics, so early stopping will always use the customized metric.

hcho3 added a commit that referenced this issue Jul 7, 2019
* Fix #4630, #4421: Preserve correct ordering between metrics, and always use last metric for early stopping

* Clarify semantics of early stopping in presence of multiple valid sets and metrics

* Add a test

* Fix lint
thesuperzapper pushed a commit to thesuperzapper/xgboost that referenced this issue Jul 8, 2019
* Fix dmlc#4630, dmlc#4421: Preserve correct ordering between metrics, and always use last metric for early stopping

* Clarify semantics of early stopping in presence of multiple valid sets and metrics

* Add a test

* Fix lint
sperlingxx pushed a commit to alipay/ant-xgboost that referenced this issue Jul 17, 2019
* Fix dmlc#4630, dmlc#4421: Preserve correct ordering between metrics, and always use last metric for early stopping

* Clarify semantics of early stopping in presence of multiple valid sets and metrics

* Add a test

* Fix lint
@lock lock bot locked as resolved and limited conversation to collaborators Oct 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants