Skip to content

Deprecations 0.21 sgd tol #12239

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

Closed

Conversation

amueller
Copy link
Member

@amueller amueller commented Oct 1, 2018

Working on #11992, deprecating the change from n_iter to max_iter/tol in the SGD family

@@ -1556,12 +1499,11 @@ class SGDRegressor(BaseSGDRegressor):

"""
def __init__(self, loss="squared_loss", penalty="l2", alpha=0.0001,
l1_ratio=0.15, fit_intercept=True, max_iter=None, tol=None,
l1_ratio=0.15, fit_intercept=True, max_iter=None, tol=1e-3,
Copy link
Member Author

Choose a reason for hiding this comment

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

missing max_iter here.

@sklearn-lgtm

This comment has been minimized.

@amueller amueller changed the title Deprecations 21 sgd tol Deprecations 0.21 sgd tol Oct 2, 2018
@sklearn-lgtm
Copy link

This pull request introduces 1 alert when merging b4fc3c3 into dfd009d - view on LGTM.com

new alerts:

  • 1 for Unused import

Comment posted by LGTM.com

@amueller
Copy link
Member Author

amueller commented Oct 2, 2018

So it looks like setting tol=0 is not actually preserving previous behavior, setting tol=-inf would. Setting tol to any negative number that's not inf is currently supported but seems very counter-intuitive. Should we disallow that (maybe worth a separate issue)?

@amueller
Copy link
Member Author

amueller commented Oct 2, 2018

also if a user used tol=None for some reason, they wouldn't get a warning in the past but now it breaks.... hm...

@@ -1290,8 +1242,6 @@ def _fit_regressor(self, X, y, alpha, C, loss, learning_rate,
# Windows
seed = random_state.randint(0, np.iinfo(np.int32).max)

tol = self._tol if self._tol is not None else -np.inf
Copy link
Member Author

Choose a reason for hiding this comment

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

maybe this line should stay here, making None an alias for -np.inf?

Copy link
Member

Choose a reason for hiding this comment

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

I agree.
In any case, we have to be consistent, either keeping this line, or removing the one in fit_binary:

tol = est.tol if est.tol is not None else -np.inf

validation_fraction=0.1, verbose=0, warm_start=False)
>>> print(clf.coef_)
[[0.29509834 0.33711843 0.56127352 0.60105546]]
[[-0.6543424 1.54603022 1.35361642 0.22199435]]
Copy link
Member Author

Choose a reason for hiding this comment

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

This is a really bad sign! I think we might have messed this up somehow.
I thought setting max_iter here meant we automatically set tol to 0.001 but apparently not?

@amueller
Copy link
Member Author

amueller commented Oct 2, 2018

Ok so if someone set max_iter but not tol in 0.20, they got tol=None which is equivalent to tol=-np.inf and they didn't get a deprecation warning. In 0.21 they will get a changed behavior, tol=0.001. thoughts?

@jnothman
Copy link
Member

jnothman commented Oct 3, 2018

told=None was only valid during deprecation, so it's not a problem

@TomDLT
Copy link
Member

TomDLT commented Oct 3, 2018

But a user getting a DeprecationWarning for n_iter could silence it by setting max_iter instead. This would not trigger any warning about not setting tol, and was equivalent to tol=-np.inf. Now, changing the default to tol=0.001 would break their code.

The wise decision would probably be to remove warnings about n_iter and max_iter, but to do a new deprecation cycle for tol.

@amueller
Copy link
Member Author

amueller commented Oct 3, 2018

@jnothman can you elaborate. I think I'm with @TomDLT on this one though that would be a real pain :-/

@jnothman
Copy link
Member

jnothman commented Oct 4, 2018

I now see what you mean. I had skimmed. We had told them it was doing something different to what it actually was if they set max_iter and not tol. But we had documented that from 0.21 the default would be 1e-3. We had not clearly specified what would happen if max_iter was specified but tol not.

So I see a choice of:

  • conservatively, follow backwards compatibility: adopt @TomDLT's approach, which would issue a FutureWarning when max_iter is explicitly set and tol is not.
  • progressively, follow the documentation: follow what we had documented, but perhaps issue a ChangedBehaviorWarning if max_iter is set and tol is not.

(Is there a way to systematically avoid this in the future, I wonder?)

@amueller
Copy link
Member Author

amueller commented Oct 4, 2018

A similar issue arises in #12240 btw.

I have no idea how to systematically test for this. The test we want is to assure that people that got no warning will not see changed behavior. But the new behavior is sometimes not even implemented when we raise the warning.

@jnothman
Copy link
Member

jnothman commented Oct 5, 2018 via email

@amueller
Copy link
Member Author

amueller commented Oct 5, 2018

Yeah. I'm not sure how easy that is in general. We can try?

@jnothman
Copy link
Member

jnothman commented Oct 6, 2018 via email

@amueller
Copy link
Member Author

Should we get some sort of warning into 0.20.1? I guess depends on which way we go?

@jnothman
Copy link
Member

Sure, a FutureWarning in 0.20.1 wouldn't hurt...

@amueller amueller added this to the 0.20.1 milestone Oct 11, 2018
@amueller
Copy link
Member Author

We still haven't made a decision here, right? And we also need to make a decision for #12240.
I don't really have a strong opinion. @rth @ogrisel ?

@jnothman
Copy link
Member

I'm happy with the progressive option: follow what we had documented, but perhaps issue a ChangedBehaviorWarning if max_iter is set and tol is not.

I am okay to issue a FutureWarning in 0.20.1

@amueller
Copy link
Member Author

ok. @NicolasHug can you maybe do that?

@amueller
Copy link
Member Author

closing as we need to wait longer now

@amueller amueller closed this Dec 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants