Skip to content

[MRG] Fix warnings during tests#5297

Closed
vighneshbirodkar wants to merge 11 commits intoscikit-learn:masterfrom
vighneshbirodkar:warn_fix
Closed

[MRG] Fix warnings during tests#5297
vighneshbirodkar wants to merge 11 commits intoscikit-learn:masterfrom
vighneshbirodkar:warn_fix

Conversation

@vighneshbirodkar
Copy link
Copy Markdown
Contributor

Addresses #5089

Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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.

Copy link
Copy Markdown
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
Copy Markdown
Contributor Author

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

Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
Member

TomDLT commented Sep 29, 2015

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

@vighneshbirodkar
Copy link
Copy Markdown
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
Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
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
Copy Markdown
Member

I copied my comment to another issue.

@TomDLT
Copy link
Copy Markdown
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
Copy Markdown
Member

Will merge after tests pass.

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