8000 [MRG] Fix warnings during tests by vighneshbirodkar · Pull Request #5297 · scikit-learn/scikit-learn · GitHub
[go: up one dir, main page]

Skip to content

[MRG] Fix warnings during tests #5297

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
wants to merge 11 commits into from

Conversation

vighneshbirodkar
Copy link
Contributor

Addresses #5089

@@ -211,6 +211,12 @@ def _boston_subset(n_samples=200):
BOSTON = X, y
return BOSTON

def get_kwargs(estimator_class):
Copy link
Contributor Author

Choose a reason for hiding this comment

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

ping @amueller @ogrisel @MechCoder
Some tests warned because the SVM object wasn't initialized with the correct arguments. Is there a better way to fix this ?

Copy link
Member

Choose a reason for hiding this comment

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

I think if anything, this should be in set_fast_parameters and that function be renamed.
For the common tests it might be ok to catch the deprecation warnings when the decision function is used.

Copy link
Member

Choose a reason for hiding this comment

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

Either solution is fine, I just don't want to add another helper function here.

@@ -213,8 +213,8 @@ def _boston_subset(n_samples=200):
return BOSTON


def set_fast_parameters(estimator):
# speed up some estimators
def set_optimal_parameters(estimator):
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@amueller I have changed the name of this function to set_optimal_parameters

@vighneshbirodkar
Copy link
Contributor Author

@amueller @ogrisel A few deprecation warnings still remain. Let me know if any more are to be fixed.

@@ -647,8 +648,20 @@ def is_abstract(c):
return sorted(set(estimators))


NON_RANDOM_CLASSES = (DBSCAN,)


def set_random_state(estimator, random_state=0):
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I am wondering if it is OK to do it here. The other alternative is to set random_state to None is get_optimal_parameters and ensure it is always called after set_random_state

Copy link
Member

Choose a reason for hiding this comment

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

If there is just one class that it is deprecated for, it might be better to just do

if isinstance(estimator, DBSCAN):
    return

Copy link
Member

Choose a reason for hiding this comment

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

(And maybe move the classes for whom sentence to a comment)

@TomDLT
Copy link
Member
TomDLT commented Sep 29, 2015

This is redundant with some fixes in #5277. Have you checked it?

@vighneshbirodkar
Copy link
Contributor Author

@TomDLT I did now. I can rebase if that is merged before this PR.

@MechCoder MechCoder changed the title [WIP] Fix warnings during tests [MRG] Fix warnings during tests Oct 1, 2015
@@ -449,7 +449,7 @@ def test_parallel_classification():
decisions2 = ensemble.decision_function(X_test)
assert_array_almost_equal(decisions1, decisions2)

ensemble = BaggingClassifier(SVC(),
Copy link
Member

Choose a reason for hiding this comment

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

Just a note for future: There seems to be a runtime warning due to division by zero.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

You mean due to the changes I have made ?

Copy link
Member

Choose a reason for hiding this comment

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

Nope, not due to your changes. Some independent warning.

@MechCoder
Copy link
Member

LGTM (Apart from the inline comments).

I am thinking if it would be good to have a custom @ignore_deprecation_warnings that would accept a tag parameter and would ignore the warnings only of a certain release. This will enable us to quickly filter and modify tests after the release (while making sure other warnings are not ignored).

@ogrisel
Copy link
Member
ogrisel commented Oct 5, 2015

I am thinking if it would be good to have a custom @ignore_deprecation_warnings that would accept a tag parameter and would ignore the warnings only of a certain release. This will enable us to quickly filter and modify tests after the release (while making sure other warnings are not ignored).

+1 but for another PR :)

@MechCoder
Copy link
Member

I copied my comment to another issue.

@TomDLT
Copy link
Member
TomDLT commented Oct 7, 2015

LGTM

Would it be too wise to add a comment whenever using @ignore_warning (as a decorator), to describe what warning we want to ignore?

@MechCoder
Copy link
Member

Will merge after tests pass.

@giorgiop
Copy link
Contributor
giorgiop commented Oct 8, 2015

I will say something obvious, but I feel it is good to point this out anyway. Fixing for test warnings should be one of the last things to do before release. We are fixing many bugs in these weeks and many imply raising new DeprecationWarnings; some of them in tests might not be caught by the same PR (by mistake).

I think this PR can be merged if it achieved what was planned at the beginning. Instead, I will not close #5089 until the very end --maybe only on beta.

@MechCoder
Copy link
Member

Instead, I will not close #5089 until the very end --maybe only on beta.

Sure, I think in PR's like this it is all right to have incremental improvements rather than fix all warnings at once. Moreover, merging this would make it easier to quickly filter out the new warnings, while not bothering about the old ones as you have pointed out while bug fixing for the release.

Are you still -1 to merging this right now, and dealing with the new warnings as and when we get to them?

@giorgiop
Copy link
Contributor
giorgiop commented Oct 8, 2015

@MechCoder , you got my point. Incremental is better. Feel free to merge this please. I would keep #5089 open for a while, as a reminder.

@MechCoder
Copy link
Member

Merged. Thanks.

@MechCoder MechCoder closed this Oct 8, 2015
@amueller
Copy link
Member
amueller commented Oct 9, 2015

@giorgiop we wanted to release two 20 days ago, as you can see on the tag. Which is why I asked @vighneshbirodkar to work on this. My health and travel have delayed everything unfortunately.

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.

6 participants
0