Skip to content

MNT Clean-up deprecations for 1.7: TSNE's n_iter #31140

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

Merged
merged 1 commit into from
Apr 9, 2025

Conversation

jeremiedbb
Copy link
Member

Removed deprecated n_iter parameter of TSNE.

@jeremiedbb jeremiedbb added No Changelog Needed Quick Review For PRs that are quick to review labels Apr 3, 2025
@jeremiedbb jeremiedbb added this to the 1.7 milestone Apr 3, 2025
Copy link

github-actions bot commented Apr 3, 2025

✔️ Linting Passed

All linting checks passed. Your pull request is in excellent shape! ☀️

Generated for commit: b71d789. Link to the linter CI: here

Copy link
Member

@thomasjpfan thomasjpfan left a comment

Choose a reason for hiding this comment

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

LGTM

@@ -794,7 +785,7 @@ class TSNE(ClassNamePrefixFeaturesOutMixin, TransformerMixin, BaseEstimator):
StrOptions({"auto"}),
Interval(Real, 0, None, closed="neither"),
],
"max_iter": [Interval(Integral, 250, None, closed="left"), None],
Copy link
Member

Choose a reason for hiding this comment

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

The message below says:

# Also make sure to change `max_iter` default back to 1000 and deprecate None

This removes None straight away and doesn't deprecate it, right?

Copy link
Member Author

Choose a reason for hiding this comment

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

Yes but this is not how we do it usually. We've decided that when we add None as a valid option for a deprecation, then we can remove it right away at the end of the deprecation. It's not like it's a meaningful option, just a sentinel during deprecation.

The writer of the message must have not been aware of this, but it's alright to do it anyway.

Copy link
Member

Choose a reason for hiding this comment

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

OK my main point was that in scikit-learn 1.6.1 the following code does not give any warning and in 1.7 this is going to break (with this PR merged):

import numpy as np
from sklearn.manifold import TSNE

TSNE(max_iter=None).fit(np.random.randn(1000, 10))

I guess that's OK because it's unlikely that someone has used max_iter=None explicitly?

Copy link
Member Author

Choose a reason for hiding this comment

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

indeed, we never encouraged to set None explicitely. It's there only to serve as a sentinel while we have the 2 max_iter and n_iter params. We already merged several PRs like this one for 1.7 and and before 1.6 as well.

Copy link
Contributor

Choose a reason for hiding this comment

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

This make sense @jeremiedbb. So I guess this review comment can be resolved?

@lesteve
Copy link
Member

lesteve commented Apr 9, 2025

Let's merge this one, thanks!

@lesteve lesteve merged commit d3f9701 into scikit-learn:main Apr 9, 2025
47 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants