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

[jvm-packages]Fix early stopping condition #3928

Merged
merged 15 commits into from
Nov 24, 2018

Conversation

CodingCat
Copy link
Member

No description provided.

@CodingCat
Copy link
Member Author

@yanboliang ?

Copy link
Contributor

@yanboliang yanboliang left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good overall, it's better we can have more docs. Thanks.

@CodingCat CodingCat merged commit 9c4ff50 into dmlc:master Nov 24, 2018
@CodingCat CodingCat deleted the fix_early_stopping branch November 24, 2018 08:18
for (int shift = 0; shift < earlyStoppingRounds - 1; shift++) {
// the initial value of onTrack is false and if the metrics in any of `earlyStoppingRounds`
// iterations goes to the expected direction, we should consider these `earlyStoppingRounds`
// as `onTrack`
onTrack |= maximizeEvaluationMetrics ?
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does this |= mean that, if the metric is moving in the right direction any two consecutive steps within the earlyStoppingRounds from the current iteration, then this method will return true?

This may not be what people normally expect from setting early stopping. For example, I'm getting a real training progress below with earlyStoppingSteps set to 20: the training should stop around iterations 120 since the maximum PR AUC was observed around iteration 100. But the current logic seems to look for any upward pieces within earlyStoppingSteps and keep training.
image

In the python-package(see here), training stops if the current iteration is earlyStoppingSteps away from the best iteration. Should the spark version be consistent with the python implementation?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

good catch, are you interested in filing a PR or an issue?

Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't really write in Scala. So created this issue instead.

@lock lock bot locked as resolved and limited conversation to collaborators Apr 8, 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 this pull request may close these issues.

3 participants