[MRG+1] Option to suppress validation for finiteness #7548

Merged
merged 20 commits into from Jun 8, 2017

Conversation

Projects
None yet
7 participants
@jnothman
Member

jnothman commented Oct 2, 2016

Fixes #1363. I'm not sure if this is the best way to make a global configuration parameter available, or the best place to document it.

@jnothman

This comment has been minimized.

Show comment
Hide comment
@jnothman

jnothman Oct 2, 2016

Member

And perhaps in the future we will add more validation suppression as a result of this flag (e.g. some of the stuff in utils.multiclass) and so we might need better ways to warn users that the behaviour of this flag may become more expansive without backwards compatibility concerns.

Is it worth using this option, for instance, to assume labels are already encoded in 0 to n_classes - 1? (or because this is a fit-time concern, is that premature optimisation?)

Member

jnothman commented Oct 2, 2016

And perhaps in the future we will add more validation suppression as a result of this flag (e.g. some of the stuff in utils.multiclass) and so we might need better ways to warn users that the behaviour of this flag may become more expansive without backwards compatibility concerns.

Is it worth using this option, for instance, to assume labels are already encoded in 0 to n_classes - 1? (or because this is a fit-time concern, is that premature optimisation?)

@amueller

This comment has been minimized.

Show comment
Hide comment
@amueller

amueller Oct 3, 2016

Member

Currently the variable name is a bit to generic for my taste. It sounds like it suppresses all validation. Maybe FAST_VALIDATION?

Member

amueller commented Oct 3, 2016

Currently the variable name is a bit to generic for my taste. It sounds like it suppresses all validation. Maybe FAST_VALIDATION?

@jnothman

This comment has been minimized.

Show comment
Hide comment
@jnothman

jnothman Oct 4, 2016

Member

SUPPRESS_COSTLY_VALIDATION?? :) Problem with FAST_VALIDATION is the "only do it with care" factor. How about LESS_VALIDATION? PRESUME_VALID?

Member

jnothman commented Oct 4, 2016

SUPPRESS_COSTLY_VALIDATION?? :) Problem with FAST_VALIDATION is the "only do it with care" factor. How about LESS_VALIDATION? PRESUME_VALID?

@jnothman

This comment has been minimized.

Show comment
Hide comment
@jnothman

jnothman Oct 5, 2016

Member

I've renamed to PRESUME_FINITE

Member

jnothman commented Oct 5, 2016

I've renamed to PRESUME_FINITE

@amueller

This comment has been minimized.

Show comment
Hide comment
@amueller

amueller Oct 5, 2016

Member

Sounds good. To me ASSUME_FINITE sounds more natural but you're the native speaker ;)

Member

amueller commented Oct 5, 2016

Sounds good. To me ASSUME_FINITE sounds more natural but you're the native speaker ;)

@amueller

This comment has been minimized.

Show comment
Hide comment
@amueller

amueller Oct 5, 2016

Member

LGTM. I'd like to have @GaelVaroquaux sign off on this if he has time.

Member

amueller commented Oct 5, 2016

LGTM. I'd like to have @GaelVaroquaux sign off on this if he has time.

@amueller amueller changed the title from [MRG] Option to suppress validation for finiteness to [MRG + 1] Option to suppress validation for finiteness Oct 5, 2016

@amueller

This comment has been minimized.

Show comment
Hide comment
@amueller

amueller Oct 5, 2016

Member

The documentation is quite hard to find right now, but I'm not sure what a better place would be.

Member

amueller commented Oct 5, 2016

The documentation is quite hard to find right now, but I'm not sure what a better place would be.

@jnothman

This comment has been minimized.

Show comment
Hide comment
@jnothman

jnothman Oct 5, 2016

Member

I'm happy to change to ASSUME. The difference is that often you assume something but still check; when you presume something, you go with that presumption blindly.

No hurry here.

Member

jnothman commented Oct 5, 2016

I'm happy to change to ASSUME. The difference is that often you assume something but still check; when you presume something, you go with that presumption blindly.

No hurry here.

@NelleV

This comment has been minimized.

Show comment
Hide comment
@NelleV

NelleV Oct 6, 2016

Member

I like PRESUME_FINITE.
It looks good to me as well.

Member

NelleV commented Oct 6, 2016

I like PRESUME_FINITE.
It looks good to me as well.

@NelleV

NelleV approved these changes Oct 7, 2016

@NelleV NelleV changed the title from [MRG + 1] Option to suppress validation for finiteness to [MRG + 2] Option to suppress validation for finiteness Oct 7, 2016

@jnothman

This comment has been minimized.

Show comment
Hide comment
@jnothman

jnothman Oct 7, 2016

Member

But we do have assume_* elsewhere in the code (assume_centered and assume_unique) with the same meaning so perhaps we should follow that convention.

Member

jnothman commented Oct 7, 2016

But we do have assume_* elsewhere in the code (assume_centered and assume_unique) with the same meaning so perhaps we should follow that convention.

@TomDLT

This comment has been minimized.

Show comment
Hide comment
@TomDLT

TomDLT Oct 13, 2016

Member

Small concern about putting the check inside assert_all_finite(X), as it is a public function advertised in the doc.
Shouldn't we just add it inside _ensure_sparse_format, check_array and check_X_y?

Member

TomDLT commented Oct 13, 2016

Small concern about putting the check inside assert_all_finite(X), as it is a public function advertised in the doc.
Shouldn't we just add it inside _ensure_sparse_format, check_array and check_X_y?

@amueller

This comment has been minimized.

Show comment
Hide comment
@amueller

amueller Oct 14, 2016

Member

@TomDLT I'm not sure I understand your concern. We should document that the behavior is overwritten by the flag, but it doesn't change any current behavior.

Member

amueller commented Oct 14, 2016

@TomDLT I'm not sure I understand your concern. We should document that the behavior is overwritten by the flag, but it doesn't change any current behavior.

@jnothman

This comment has been minimized.

Show comment
Hide comment
@jnothman

jnothman Oct 15, 2016

Member

I think the idea that we're assuming rather than asserting finiteness when
the flag is on is pretty clear.

On 15 October 2016 at 04:04, Andreas Mueller notifications@github.com
wrote:

@TomDLT https://github.com/TomDLT I'm not sure I understand your
concern. We should document that the behavior is overwritten by the flag,
but it doesn't change any current behavior.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#7548 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEz6xVXXhOe7etRA3SvLIboMAiKrSQAks5qz7YCgaJpZM4KL6yC
.

Member

jnothman commented Oct 15, 2016

I think the idea that we're assuming rather than asserting finiteness when
the flag is on is pretty clear.

On 15 October 2016 at 04:04, Andreas Mueller notifications@github.com
wrote:

@TomDLT https://github.com/TomDLT I'm not sure I understand your
concern. We should document that the behavior is overwritten by the flag,
but it doesn't change any current behavior.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#7548 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAEz6xVXXhOe7etRA3SvLIboMAiKrSQAks5qz7YCgaJpZM4KL6yC
.

@jnothman

This comment has been minimized.

Show comment
Hide comment
@jnothman

jnothman Oct 15, 2016

Member

have added a note to docs.

Member

jnothman commented Oct 15, 2016

have added a note to docs.

@NelleV

This comment has been minimized.

Show comment
Hide comment
@NelleV

NelleV Oct 31, 2016

Member

Are we still waiting for @GaelVaroquaux to comment on that one?

Member

NelleV commented Oct 31, 2016

Are we still waiting for @GaelVaroquaux to comment on that one?

@GaelVaroquaux

This comment has been minimized.

Show comment
Hide comment
@GaelVaroquaux

GaelVaroquaux Oct 31, 2016

Member

LGTM.

One think that would be good would be to add a contextmanager to do that. I fear Ill-written code that suppresses validation in more places that it would like.

Member

GaelVaroquaux commented Oct 31, 2016

LGTM.

One think that would be good would be to add a contextmanager to do that. I fear Ill-written code that suppresses validation in more places that it would like.

@jnothman

This comment has been minimized.

Show comment
Hide comment
@jnothman

jnothman Nov 1, 2016

Member

Do you foresee with sklearn.set_validation analogous to np.seterr? If we can agree on where it lives and how broadly it is named, I'm happy to implement here before merge. Otherwise, I think we could merge this PR as is (modulo what's new).

Member

jnothman commented Nov 1, 2016

Do you foresee with sklearn.set_validation analogous to np.seterr? If we can agree on where it lives and how broadly it is named, I'm happy to implement here before merge. Otherwise, I think we could merge this PR as is (modulo what's new).

@GaelVaroquaux

This comment has been minimized.

Show comment
Hide comment
@GaelVaroquaux

GaelVaroquaux Nov 1, 2016

Member
Member

GaelVaroquaux commented Nov 1, 2016

@amueller

This comment has been minimized.

Show comment
Hide comment
@amueller

amueller Nov 17, 2016

Member

I'm fine with either way, slightly leaning to set_validation

Member

amueller commented Nov 17, 2016

I'm fine with either way, slightly leaning to set_validation

@jnothman

This comment has been minimized.

Show comment
Hide comment
@jnothman

jnothman Nov 18, 2016

Member

Yes, I'll get back to it some time soon! I know, it'll be a nice feature to have.

Member

jnothman commented Nov 18, 2016

Yes, I'll get back to it some time soon! I know, it'll be a nice feature to have.

@jnothman

This comment has been minimized.

Show comment
Hide comment
@jnothman

jnothman Nov 23, 2016

Member

I've added a context manager, sklearn.set_config. Happy to make it live somewhere else if there's a suggestion for how to structure this in the package.

I'm dropping the +2 for new reviews.

Member

jnothman commented Nov 23, 2016

I've added a context manager, sklearn.set_config. Happy to make it live somewhere else if there's a suggestion for how to structure this in the package.

I'm dropping the +2 for new reviews.

@jnothman jnothman changed the title from [MRG + 2] Option to suppress validation for finiteness to [MRG] Option to suppress validation for finiteness Nov 23, 2016

@jnothman

This comment has been minimized.

Show comment
Hide comment
@jnothman

jnothman Nov 24, 2016

Member

Btw, I chose set_config over set_validation as I think given the paucity of global config parameters in scikit-learn (the data directory is one other that could be included here), we might as well make this more generic.

Member

jnothman commented Nov 24, 2016

Btw, I chose set_config over set_validation as I think given the paucity of global config parameters in scikit-learn (the data directory is one other that could be included here), we might as well make this more generic.

+ ... pass # do learning/prediction here with reduced validation
+
+ Note that this will affect all uses of
+ :func:`sklearn.utils.assert_all_finite` within the context.

This comment has been minimized.

@GaelVaroquaux

GaelVaroquaux Nov 24, 2016

Member

Maybe I would say here that it may lead to crashes, include segmentation faults, if there are non finite numbers.

@GaelVaroquaux

GaelVaroquaux Nov 24, 2016

Member

Maybe I would say here that it may lead to crashes, include segmentation faults, if there are non finite numbers.

sklearn/__init__.py
+ _ASSUME_FINITE = assume_finite
+
+ yield
+ _ASSUME_FINITE = prev_assume_finite

This comment has been minimized.

@GaelVaroquaux

GaelVaroquaux Nov 24, 2016

Member

Should we / can we have a test for the context manager?

@GaelVaroquaux

GaelVaroquaux Nov 24, 2016

Member

Should we / can we have a test for the context manager?

@GaelVaroquaux GaelVaroquaux changed the title from [MRG] Option to suppress validation for finiteness to [MRG+1] Option to suppress validation for finiteness Nov 24, 2016

@GaelVaroquaux

This comment has been minimized.

Show comment
Hide comment
@GaelVaroquaux

GaelVaroquaux Nov 24, 2016

Member

Aside the two small comments above (the main being the one on the test), I am +1 for merge. Thanks!

Member

GaelVaroquaux commented Nov 24, 2016

Aside the two small comments above (the main being the one on the test), I am +1 for merge. Thanks!

sklearn/__init__.py
+ config = get_config().copy()
+ set_config(**kwargs)
+
+ yield

This comment has been minimized.

@tacaswell

tacaswell Dec 15, 2016

Contributor

This should be

try:
    yield
finally:
    set_config(...)

or any exceptions raised with in the context manager will cause it to not be reset .

@tacaswell

tacaswell Dec 15, 2016

Contributor

This should be

try:
    yield
finally:
    set_config(...)

or any exceptions raised with in the context manager will cause it to not be reset .

This comment has been minimized.

@jnothman

jnothman Dec 15, 2016

Member

Thank you.

@jnothman

jnothman Dec 15, 2016

Member

Thank you.

@tacaswell

This comment has been minimized.

Show comment
Hide comment
@tacaswell

tacaswell Dec 15, 2016

Contributor

The most useful part of the rcparam system is the validation which serves as both runtime validation and an good documentation. However, if I were going to do the rc system from scratch today I would use something like nested attrs objects rather than a dictionary sub-class.

👍 on the names

Contributor

tacaswell commented Dec 15, 2016

The most useful part of the rcparam system is the validation which serves as both runtime validation and an good documentation. However, if I were going to do the rc system from scratch today I would use something like nested attrs objects rather than a dictionary sub-class.

👍 on the names

@jnothman

This comment has been minimized.

Show comment
Hide comment
@jnothman

jnothman Dec 15, 2016

Member
Member

jnothman commented Dec 15, 2016

@amueller

This comment has been minimized.

Show comment
Hide comment
@amueller

amueller Dec 16, 2016

Member

@tacaswell argued for resetting everything on exit of the context manager in person.
The argument was: imagine you have a library using the context manager, and a user provided function inside the context. Whether any parameters set in this function will be reset depends on whether they are also used in the context manager, information that is not available to the user code.

Therefore: reset everything to what it was before.

Member

amueller commented Dec 16, 2016

@tacaswell argued for resetting everything on exit of the context manager in person.
The argument was: imagine you have a library using the context manager, and a user provided function inside the context. Whether any parameters set in this function will be reset depends on whether they are also used in the context manager, information that is not available to the user code.

Therefore: reset everything to what it was before.

@jnothman

This comment has been minimized.

Show comment
Hide comment
@jnothman

jnothman Dec 19, 2016

Member

I don't get it. A user-code callback uses set_config and therefore wants that to persist outside the calling library func. You're proposing that this simply not work if the library func happens to use a config_context, regardless of whether the config it is setting has nothing to do with what is being set in the user func??

Member

jnothman commented Dec 19, 2016

I don't get it. A user-code callback uses set_config and therefore wants that to persist outside the calling library func. You're proposing that this simply not work if the library func happens to use a config_context, regardless of whether the config it is setting has nothing to do with what is being set in the user func??

@amueller

This comment has been minimized.

Show comment
Hide comment
@amueller

amueller Dec 19, 2016

Member

I'm paraphrasing @tacaswell so I might get his argument wrong.

Basically you have

# in some library:

def func(user_callback):
    with config_context(**some_dict):
        user_callback()

# in user code:
def my_callback():
    set_config(b='c')

func(my_callback)

Whether my_callback has any effect depends on whether b in some_dict, which the user might not know. So instead of having different behavior for b in some_dict and b not in somedict, we consistently make it have no effect.

I'm uncertain, but that is @tacaswell's reasoning. I could bug the numpy people about it, too ;)

Member

amueller commented Dec 19, 2016

I'm paraphrasing @tacaswell so I might get his argument wrong.

Basically you have

# in some library:

def func(user_callback):
    with config_context(**some_dict):
        user_callback()

# in user code:
def my_callback():
    set_config(b='c')

func(my_callback)

Whether my_callback has any effect depends on whether b in some_dict, which the user might not know. So instead of having different behavior for b in some_dict and b not in somedict, we consistently make it have no effect.

I'm uncertain, but that is @tacaswell's reasoning. I could bug the numpy people about it, too ;)

@tacaswell

This comment has been minimized.

Show comment
Hide comment
@tacaswell

tacaswell Dec 19, 2016

Contributor

I would also think about the case

def some_func(*args, confg_dict):
    with config_context(**config_dict):
        some_library_function_with_side_effect(*args)

In this case if the side effects stick depends on what keys the user passes in.

"Restores configuration to what it was before entering context" is simpler than "restores the keys set as part of the conext, but not key that are set by other means with in the context". The second case also leads to a discussion if maybe the keys that are set by other means should be tracked an explicitly not reset. Do you do that my comparing the configuration on exit to the configuration set on entrance and only reset the keys that have not changed? Then you get to the corner case where some of the keys are set to what they happened to be in the entrance of the context manager and others are not so only some of the explicit configuration changing in the context is left alone. So then you start to instrument the the configuration object to track __setitem__ to keep track of what has or has not been changed, but now you have to deal with nested context managers....

Hence, adopt the position 'context manager puts the config back to what it was before you entered' 😜

Contributor

tacaswell commented Dec 19, 2016

I would also think about the case

def some_func(*args, confg_dict):
    with config_context(**config_dict):
        some_library_function_with_side_effect(*args)

In this case if the side effects stick depends on what keys the user passes in.

"Restores configuration to what it was before entering context" is simpler than "restores the keys set as part of the conext, but not key that are set by other means with in the context". The second case also leads to a discussion if maybe the keys that are set by other means should be tracked an explicitly not reset. Do you do that my comparing the configuration on exit to the configuration set on entrance and only reset the keys that have not changed? Then you get to the corner case where some of the keys are set to what they happened to be in the entrance of the context manager and others are not so only some of the explicit configuration changing in the context is left alone. So then you start to instrument the the configuration object to track __setitem__ to keep track of what has or has not been changed, but now you have to deal with nested context managers....

Hence, adopt the position 'context manager puts the config back to what it was before you entered' 😜

@jnothman

This comment has been minimized.

Show comment
Hide comment
@jnothman

jnothman Dec 20, 2016

Member

@amueller, my concern with that first example is that introducing a context manger into func where there was none before wrecks everything from my_callback, despite some_dict not setting any of the same parameters as my_callback. Functions that use context managers then need to be documented for their imperviousness anyway.

I get the documentation simplicity of your approach. It makes sense in numpy where the errstate is homogeneous in the types of settings it's dealing with; and perhaps in matplotlib where the config is everything. Here we only have one setting, and as far as I can tell, configurations are unlikely to have much to do with each other. A context, except at the outermost level of library invocation, is likely to set only few of the params.

But this is almost entirely philosophy and I should probably just adopt what you suggest.

Member

jnothman commented Dec 20, 2016

@amueller, my concern with that first example is that introducing a context manger into func where there was none before wrecks everything from my_callback, despite some_dict not setting any of the same parameters as my_callback. Functions that use context managers then need to be documented for their imperviousness anyway.

I get the documentation simplicity of your approach. It makes sense in numpy where the errstate is homogeneous in the types of settings it's dealing with; and perhaps in matplotlib where the config is everything. Here we only have one setting, and as far as I can tell, configurations are unlikely to have much to do with each other. A context, except at the outermost level of library invocation, is likely to set only few of the params.

But this is almost entirely philosophy and I should probably just adopt what you suggest.

@tacaswell

This comment has been minimized.

Show comment
Hide comment
@tacaswell

tacaswell Dec 20, 2016

Contributor

You currently only have one global configuration 😈. If you expect it to stay that way, then why aren't these called ignore_nan_context and set_ignore_nan_state, etc?

Users are very clever and will do all sorts of 'interesting' things (and will not be persuaded by 'do not do that', and documenting what not to do just gives some users ideas!) so even if sklearn never writes functions like this, some downstream library will.

Contributor

tacaswell commented Dec 20, 2016

You currently only have one global configuration 😈. If you expect it to stay that way, then why aren't these called ignore_nan_context and set_ignore_nan_state, etc?

Users are very clever and will do all sorts of 'interesting' things (and will not be persuaded by 'do not do that', and documenting what not to do just gives some users ideas!) so even if sklearn never writes functions like this, some downstream library will.

@jnothman

This comment has been minimized.

Show comment
Hide comment
@jnothman

jnothman Dec 20, 2016

Member
Member

jnothman commented Dec 20, 2016

@tacaswell

This comment has been minimized.

Show comment
Hide comment
@tacaswell

tacaswell Dec 21, 2016

Contributor

Sorry if I was arguing too forcefully or was out of line. I do not know the audience here (but do know I am the peanut gallery!).

Contributor

tacaswell commented Dec 21, 2016

Sorry if I was arguing too forcefully or was out of line. I do not know the audience here (but do know I am the peanut gallery!).

@jnothman

This comment has been minimized.

Show comment
Hide comment
@jnothman

jnothman Dec 21, 2016

Member
Member

jnothman commented Dec 21, 2016

@jnothman

This comment has been minimized.

Show comment
Hide comment
@jnothman

jnothman Dec 21, 2016

Member

Pushed conformant changes

Member

jnothman commented Dec 21, 2016

Pushed conformant changes

@jnothman

This comment has been minimized.

Show comment
Hide comment
@jnothman

jnothman Feb 3, 2017

Member

@amueller, I assume this still has your +1? Another review?

Member

jnothman commented Feb 3, 2017

@amueller, I assume this still has your +1? Another review?

@amueller

This comment has been minimized.

Show comment
Hide comment
@amueller

amueller Jun 7, 2017

Member

I'll review again and ping @GaelVaroquaux to check it out

Member

amueller commented Jun 7, 2017

I'll review again and ping @GaelVaroquaux to check it out

+import os
+from contextlib import contextmanager as _contextmanager
+
+_ASSUME_FINITE = bool(os.environ.get('SKLEARN_ASSUME_FINITE', False))

This comment has been minimized.

@amueller

amueller Jun 7, 2017

Member

If we want to add more config in the future, don't we want them to be bundled in a dictionary?

@amueller

amueller Jun 7, 2017

Member

If we want to add more config in the future, don't we want them to be bundled in a dictionary?

@amueller

This comment has been minimized.

Show comment
Hide comment
@amueller

amueller Jun 7, 2017

Member

still +1 but maybe have a the global variable be a dict if we want to add an option for the repr?

Member

amueller commented Jun 7, 2017

still +1 but maybe have a the global variable be a dict if we want to add an option for the repr?

+
+ Parameters
+ ----------
+ assume_finite : bool, optional

This comment has been minimized.

@agramfort

agramfort Jun 7, 2017

Member

bad param docstring

@agramfort

agramfort Jun 7, 2017

Member

bad param docstring

This comment has been minimized.

@jnothman

jnothman Jun 7, 2017

Member

How so? Because I should say that it needs to be specified by name?

The point here is that the user always has the option to change, but can leave things unchanged Too

@jnothman

jnothman Jun 7, 2017

Member

How so? Because I should say that it needs to be specified by name?

The point here is that the user always has the option to change, but can leave things unchanged Too

This comment has been minimized.

@agramfort

agramfort Jun 8, 2017

Member

forget it

@agramfort

agramfort Jun 8, 2017

Member

forget it

@jnothman

This comment has been minimized.

Show comment
Hide comment
@jnothman

jnothman Jun 7, 2017

Member
Member

jnothman commented Jun 7, 2017

@amueller

This comment has been minimized.

Show comment
Hide comment
@amueller

amueller Jun 8, 2017

Member

Ok I'll do that in my PR ;)

Member

amueller commented Jun 8, 2017

Ok I'll do that in my PR ;)

@jnothman

This comment has been minimized.

Show comment
Hide comment
@jnothman

jnothman Jun 8, 2017

Member
Member

jnothman commented Jun 8, 2017

@agramfort

This comment has been minimized.

Show comment
Hide comment
@agramfort

agramfort Jun 8, 2017

Member

looks great.

@amueller green button ?

Member

agramfort commented Jun 8, 2017

looks great.

@amueller green button ?

@amueller amueller merged commit ee88cf4 into scikit-learn:master Jun 8, 2017

5 checks passed

ci/circleci Your tests passed on CircleCI!
Details
codecov/patch 100% of diff hit (target 95.92%)
Details
codecov/project 96.21% (+0.28%) compared to 331ae2f
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@amueller

This comment has been minimized.

Show comment
Hide comment
@amueller

amueller Jun 8, 2017

Member

yes ;)

Member

amueller commented Jun 8, 2017

yes ;)

Sundrique added a commit to Sundrique/scikit-learn that referenced this pull request Jun 14, 2017

[MRG+1] Option to suppress validation for finiteness (#7548)
* ENH add suppress validation option

* TST skip problematic doctest

* Rename SUPPRESS_VALIDATION to PRESUME_FINITE

* Change PRESUME_ to ASSUME_ for convention's sake

* DOC add note regarding assert_all_finite

* ENH add set_config context manager for ASSUME_FINITE

* Make ASSUME_FINITE private and provide get_config

* Fix ImportError due to incomplete change in last commit

* TST/DOC tests and more cautious documentation for set_config

* DOC what's new entry for validation suppression

* context manager is now config_context; set_config affects global config

* Rename missed set_config to config_context

* Fix mis-named test

* Mention set_config in narrative docs

* More explicit about limmited restoration of context

* Handle case where error raised in config_context

* Reset all settings after exiting context manager

dmohns added a commit to dmohns/scikit-learn that referenced this pull request Aug 7, 2017

[MRG+1] Option to suppress validation for finiteness (#7548)
* ENH add suppress validation option

* TST skip problematic doctest

* Rename SUPPRESS_VALIDATION to PRESUME_FINITE

* Change PRESUME_ to ASSUME_ for convention's sake

* DOC add note regarding assert_all_finite

* ENH add set_config context manager for ASSUME_FINITE

* Make ASSUME_FINITE private and provide get_config

* Fix ImportError due to incomplete change in last commit

* TST/DOC tests and more cautious documentation for set_config

* DOC what's new entry for validation suppression

* context manager is now config_context; set_config affects global config

* Rename missed set_config to config_context

* Fix mis-named test

* Mention set_config in narrative docs

* More explicit about limmited restoration of context

* Handle case where error raised in config_context

* Reset all settings after exiting context manager

dmohns added a commit to dmohns/scikit-learn that referenced this pull request Aug 7, 2017

[MRG+1] Option to suppress validation for finiteness (#7548)
* ENH add suppress validation option

* TST skip problematic doctest

* Rename SUPPRESS_VALIDATION to PRESUME_FINITE

* Change PRESUME_ to ASSUME_ for convention's sake

* DOC add note regarding assert_all_finite

* ENH add set_config context manager for ASSUME_FINITE

* Make ASSUME_FINITE private and provide get_config

* Fix ImportError due to incomplete change in last commit

* TST/DOC tests and more cautious documentation for set_config

* DOC what's new entry for validation suppression

* context manager is now config_context; set_config affects global config

* Rename missed set_config to config_context

* Fix mis-named test

* Mention set_config in narrative docs

* More explicit about limmited restoration of context

* Handle case where error raised in config_context

* Reset all settings after exiting context manager

NelleV added a commit to NelleV/scikit-learn that referenced this pull request Aug 11, 2017

[MRG+1] Option to suppress validation for finiteness (#7548)
* ENH add suppress validation option

* TST skip problematic doctest

* Rename SUPPRESS_VALIDATION to PRESUME_FINITE

* Change PRESUME_ to ASSUME_ for convention's sake

* DOC add note regarding assert_all_finite

* ENH add set_config context manager for ASSUME_FINITE

* Make ASSUME_FINITE private and provide get_config

* Fix ImportError due to incomplete change in last commit

* TST/DOC tests and more cautious documentation for set_config

* DOC what's new entry for validation suppression

* context manager is now config_context; set_config affects global config

* Rename missed set_config to config_context

* Fix mis-named test

* Mention set_config in narrative docs

* More explicit about limmited restoration of context

* Handle case where error raised in config_context

* Reset all settings after exiting context manager

paulha added a commit to paulha/scikit-learn that referenced this pull request Aug 19, 2017

[MRG+1] Option to suppress validation for finiteness (#7548)
* ENH add suppress validation option

* TST skip problematic doctest

* Rename SUPPRESS_VALIDATION to PRESUME_FINITE

* Change PRESUME_ to ASSUME_ for convention's sake

* DOC add note regarding assert_all_finite

* ENH add set_config context manager for ASSUME_FINITE

* Make ASSUME_FINITE private and provide get_config

* Fix ImportError due to incomplete change in last commit

* TST/DOC tests and more cautious documentation for set_config

* DOC what's new entry for validation suppression

* context manager is now config_context; set_config affects global config

* Rename missed set_config to config_context

* Fix mis-named test

* Mention set_config in narrative docs

* More explicit about limmited restoration of context

* Handle case where error raised in config_context

* Reset all settings after exiting context manager

AishwaryaRK added a commit to AishwaryaRK/scikit-learn that referenced this pull request Aug 29, 2017

[MRG+1] Option to suppress validation for finiteness (#7548)
* ENH add suppress validation option

* TST skip problematic doctest

* Rename SUPPRESS_VALIDATION to PRESUME_FINITE

* Change PRESUME_ to ASSUME_ for convention's sake

* DOC add note regarding assert_all_finite

* ENH add set_config context manager for ASSUME_FINITE

* Make ASSUME_FINITE private and provide get_config

* Fix ImportError due to incomplete change in last commit

* TST/DOC tests and more cautious documentation for set_config

* DOC what's new entry for validation suppression

* context manager is now config_context; set_config affects global config

* Rename missed set_config to config_context

* Fix mis-named test

* Mention set_config in narrative docs

* More explicit about limmited restoration of context

* Handle case where error raised in config_context

* Reset all settings after exiting context manager

maskani-moh added a commit to maskani-moh/scikit-learn that referenced this pull request Nov 15, 2017

[MRG+1] Option to suppress validation for finiteness (#7548)
* ENH add suppress validation option

* TST skip problematic doctest

* Rename SUPPRESS_VALIDATION to PRESUME_FINITE

* Change PRESUME_ to ASSUME_ for convention's sake

* DOC add note regarding assert_all_finite

* ENH add set_config context manager for ASSUME_FINITE

* Make ASSUME_FINITE private and provide get_config

* Fix ImportError due to incomplete change in last commit

* TST/DOC tests and more cautious documentation for set_config

* DOC what's new entry for validation suppression

* context manager is now config_context; set_config affects global config

* Rename missed set_config to config_context

* Fix mis-named test

* Mention set_config in narrative docs

* More explicit about limmited restoration of context

* Handle case where error raised in config_context

* Reset all settings after exiting context manager

jwjohnson314 pushed a commit to jwjohnson314/scikit-learn that referenced this pull request Dec 18, 2017

[MRG+1] Option to suppress validation for finiteness (#7548)
* ENH add suppress validation option

* TST skip problematic doctest

* Rename SUPPRESS_VALIDATION to PRESUME_FINITE

* Change PRESUME_ to ASSUME_ for convention's sake

* DOC add note regarding assert_all_finite

* ENH add set_config context manager for ASSUME_FINITE

* Make ASSUME_FINITE private and provide get_config

* Fix ImportError due to incomplete change in last commit

* TST/DOC tests and more cautious documentation for set_config

* DOC what's new entry for validation suppression

* context manager is now config_context; set_config affects global config

* Rename missed set_config to config_context

* Fix mis-named test

* Mention set_config in narrative docs

* More explicit about limmited restoration of context

* Handle case where error raised in config_context

* Reset all settings after exiting context manager
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment