-
-
Notifications
You must be signed in to change notification settings - Fork 34
SLEP 014 Pandas in Pandas out #37
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
Changes from 5 commits
c82c7f7
40e4831
d078039
e3aa624
3147fab
7647a57
fd25211
570f3e2
2d86336
914f76e
e326d67
d13fb43
b1d5a86
8ffde79
ea502da
665dd5e
aed332b
aac9998
f7abc34
a999266
4588fc4
85c1c7c
c9eb0ee
653e476
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,173 @@ | ||
.. _slep_014: | ||
|
||
============================== | ||
SLEP014: Pandas In, Pandas Out | ||
============================== | ||
|
||
:Author: Thomas J Fan | ||
:Status: Under Review | ||
:Type: Standards Track | ||
:Created: 2020-02-18 | ||
|
||
Abstract | ||
######## | ||
|
||
This SLEP proposes using pandas DataFrames for propagating feature names | ||
through ``scikit-learn`` estimators. | ||
|
||
Motivation | ||
########## | ||
|
||
``scikit-learn`` is generally used as a part of a larger data processing | ||
pipeline. When this pipeline is used to transform data, the result is a | ||
NumPy array, which discards column names. The current workflow for | ||
extracting the feature names requires calling ``get_feature_names`` on the | ||
transformer that created the feature. This interface can be cumbersome when used | ||
together with a pipeline with multiple column names:: | ||
|
||
import pandas as pd | ||
import numpy as np | ||
from sklearn.compose import make_column_transformer | ||
from sklearn.preprocessing import OneHotEncoder, StandardScaler | ||
from sklearn.pipeline import make_pipeline | ||
from sklearn.linear_model import LogisticRegression | ||
|
||
X = pd.DataFrame({'letter': ['a', 'b', 'c'], | ||
'pet': ['dog', 'snake', 'dog'], | ||
'num': [1, 2, 3]}) | ||
y = [0, 0, 1] | ||
orig_cat_cols, orig_num_cols = ['letter', 'pet'], ['num'] | ||
|
||
ct = make_column_transformer( | ||
(OneHotEncoder(), orig_cat_cols), (StandardScaler(), orig_num_cols)) | ||
pipe = make_pipeline(ct, LogisticRegression()).fit(X,y) | ||
|
||
cat_names = (pipe['columntransformer'] | ||
.named_transformers_['onehotencoder'] | ||
.get_feature_names(orig_cat_cols)) | ||
|
||
feature_names = np.r_[cat_names, orig_num_cols] | ||
|
||
The ``feature_names`` extracted above corresponds to the features directly | ||
passed into ``LogisticRegression``. As demonstrated above, the process of | ||
extracting ``feature_names`` requires knowing the order of the selected | ||
categories in the ``ColumnTransformer``. Furthemore, if there is feature | ||
selection in the pipeline, such as ``SelectKBest``, the ``get_support`` method | ||
would need to be used to select column names that were selected. | ||
thomasjpfan marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
||
Solution | ||
######## | ||
|
||
The pandas ``DataFrame`` has been widely adopted by the Python Data ecosystem to | ||
store data with feature names. This SLEP proposes using a ``DataFrame`` to | ||
track the feature names as the data is transformed. With this feature, the | ||
API for extracting feature names would be:: | ||
|
||
from sklearn import set_config | ||
set_config(pandas_inout=True) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. minor nit, but I think |
||
|
||
pipe.fit(X, y) | ||
X_trans = pipe[:-1].transform(X) | ||
|
||
print(X_trans.columns.tolist() | ||
['letter_a', 'letter_b', 'letter_c', 'pet_dog', 'pet_snake', 'num'] | ||
|
||
Enabling Functionality | ||
###################### | ||
|
||
The following enhancements are **not** a part of this SLEP. These features are | ||
made possible if this SLEP gets accepted. | ||
|
||
1. Allows estimators to treat columns differently based on name or dtype. For | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In what way is this enabled by the present SLEP? I assume this means something more expansive: that we will try to retain dtype in outputting a dataframe e.g. after feature selection. Otherwise this pertains to the handling of Pandas input, which is done on a case-by-case basis already? |
||
example, the categorical dtype is useful for tree building algorithms. | ||
|
||
2. Storing feature names inside estimators for model inspection:: | ||
|
||
from sklearn import set_config | ||
set_config(store_feature_names_in=True) | ||
|
||
pipe.fit(X, y) | ||
|
||
pipe['logisticregression'].feature_names_in_ | ||
|
||
3. Allow for extracting the feature names of estimators in meta-estimators:: | ||
|
||
from sklearn import set_config | ||
set_config(store_feature_names_in=True) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. we probably should have the default values of these configs somewhere. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. The default of |
||
|
||
est = BaggingClassifier(LogisticRegression()) | ||
est.fit(X, y) | ||
|
||
# Gets the feature names used by an estimator in the ensemble | ||
est.estimators_[0].feature_names_in_ | ||
|
||
Considerations | ||
############## | ||
|
||
Index alignment | ||
--------------- | ||
|
||
Operations are index aligned when working with ``DataFrames``. Interally, | ||
``scikit-learn`` will ignore the alignment by operating on the ndarray as | ||
suggested by `TomAugspurger <https://github.com/scikit-learn/enhancement_proposals/pull/25#issuecomment-573859151>`_:: | ||
|
||
def transform(self, X, y=None): | ||
X, row_labels, input_type = check_array(X) | ||
# X is a ndarray | ||
result = ... | ||
# some hypothetical function that recreates a DataFrame / DataArray, | ||
# preserving row labels, attaching new features names. | ||
return construct_result(result, output_feature_names, row_labels, input_type) | ||
|
||
Memory copies | ||
------------- | ||
|
||
As noted in `pandas #27211 <https://github.com/pandas-dev/pandas/issues/27211>`_, | ||
there is not a guarantee that there is a zero-copy round-trip going from numpy | ||
to a ``DataFrame``. In other words, the following may lead to a memory copy in | ||
a future version of ``pandas``:: | ||
|
||
X = np.array(...) | ||
X_df = pd.DataFrame(X) | ||
X_again = np.asarray(X_df) | ||
|
||
This is an issue for ``scikit-learn`` when estimators are placed into a | ||
pipeline. For example, consider the following pipeline:: | ||
|
||
set_config(pandas_inout=True) | ||
pipe = make_pipeline(StandardScaler(), LogisticRegression()) | ||
pipe.fit(X, y) | ||
|
||
Interally, ``StandardScaler.fit_transform`` will operate on a ndarray and | ||
wrap the ndarray into a ``DataFrame`` as a return value. This is will be | ||
piped into ``LogisticRegression.fit`` which calls ``check_array`` on the | ||
``DataFrame``, which may lead to a memory copy in a future version of | ||
``pandas``. This leads to unnecessary overhead from piping the data from one | ||
estimator to another. | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Personally, I think that for some transformers (like StandardScaler) could rather easily work column-wise to avoid such copying overhead. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. and it could even have the option of being "in-place" :D There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. We can try to support this. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yes |
||
|
||
Backward compatibility | ||
###################### | ||
|
||
The ``set_config(pandas_inout=True)`` global configuration flag will be set to | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. maybe more like There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I had something like that initially, but it feels like "We will always output pandas, even if the input is numpy arrays". (Naming is hard) |
||
``False`` by default to ensure backward compatibility. When this flag is False, | ||
the output of all estimators will be a ndarray. | ||
|
||
Alternatives | ||
############ | ||
|
||
- :ref:`SLEP012 Custom InputArray Data Structure <slep_012>` | ||
|
||
References and Footnotes | ||
------------------------ | ||
|
||
.. [1] Each SLEP must either be explicitly labeled as placed in the public | ||
domain (see this SLEP as an example) or licensed under the `Open | ||
Publication License`_. | ||
|
||
.. _Open Publication License: https://www.opencontent.org/openpub/ | ||
|
||
|
||
Copyright | ||
--------- | ||
|
||
This document has been placed in the public domain. [1]_ |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -11,3 +11,4 @@ SLEPs under review | |
slep007/proposal | ||
slep012/proposal | ||
slep013/proposal | ||
slep014/proposal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If we go for SLEP000, this would be a
Draft