Thanks to visit codestin.com
Credit goes to github.com

Skip to content

Track SLEP10: Add n_features_in_ to all modules #19333

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
47 tasks done
lorentzenchr opened this issue Feb 3, 2021 · 6 comments
Closed
47 tasks done

Track SLEP10: Add n_features_in_ to all modules #19333

lorentzenchr opened this issue Feb 3, 2021 · 6 comments
Labels
help wanted Moderate Anything that requires some knowledge of conventions and best practices
Milestone

Comments

@lorentzenchr
Copy link
Member

lorentzenchr commented Feb 3, 2021

This issue tracks the status of follow-ups of #18514, i.e. the implementation of SLEP10.

According to N_FEATURES_IN_AFTER_FIT_MODULES_TO_IGNORE in test_common.py, as of 96a96f1, modules to be n_feature_in_-ified are:

Track documentation status of n_features_in_ , see N_FEATURES_MODULES_TO_IGNOREin test_docstring_parameters.py, start was #19351. Note that existing alternatives like n_features_ attributes have to be properly deprecated:

Note: for meta-estimators it is better to delegate feature consistency validation to the inner base estimators.

@lorentzenchr
Copy link
Member Author

@thomasjpfan How do we document n_features_in_? In the merged PRs, I don't see entries as attribute in the docstrings. Another question is how we want to deal the attribute n_features_ in BaggingClassifier. Do we want to deprecate that one or do we just replace it by n_features_in_?

@thomasjpfan
Copy link
Member

How do we document n_features_in_? In the merged PRs, I don't see entries as attribute in the docstrings.

I think we should add them to the docstring. I opened #19351 to start the process of documenting this.

Another question is how we want to deal the attribute n_features_ in BaggingClassifier. Do we want to deprecate that one or do we just replace it by n_features_in_?

I would say to deprecate it.

@glemaitre
Copy link
Member

I would say to deprecate it.

Yep, this seems the right way.

@jeremiedbb
Copy link
Member

I was going for the compose module and it turns out n_features_in_ is already implemented for the TransformedTargetRegressor and ColumnTransformer, so the compose module can be removed from the list. This is done in #20175.

@glemaitre
Copy link
Member

glemaitre commented Jun 9, 2021

TODO in subsequent PR:

@ogrisel
Copy link
Member

ogrisel commented Jun 15, 2021

Yeah!!!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
help wanted Moderate Anything that requires some knowledge of conventions and best practices
Projects
None yet
Development

No branches or pull requests

5 participants