Here is a silly example:

import lightgbm as lgb
import pandas as pd
from sklearn.compose import ColumnTransformer
from sklearn.preprocessing import FunctionTransformer, OneHotEncoder

ct = ColumnTransformer(
    [
        ("x1", FunctionTransformer(lambda x: 2 * x.to_numpy()), ["x1"]),
        ("x2", OneHotEncoder(sparse=False), ["x2"]),
    ]
)

df = pd.DataFrame({"y": [0, 2, 5], "x1": [0, 1, 2], "x2": ["i", "i", "ii"]})
dft = ct.fit_transform(df)

estimator = lgb.LGBMRegressor(min_child_samples=1).fit(dft, df["y"])

# compute partial dependency (advantage: no unnecessary transformations)

ix = ct.transformers_output_["x2"]
dft[:, ix] = ct.named_transformers_["x2"].transform(pd.DataFrame({"x2": ["i"] * 3}))
estimator.predict(dft).mean()

# compute total gain from an untransformed feature

ix = ct.transformers_output_["x2"]
estimator.booster_.feature_importance(importance_type="gain")[ix].sum()

The attribute becomes more valuable when you construct the column transformer programmatically, so it may contain many transformers and it isn't obvious which is responsible for what column.

This type of correspondence is related to SLEP 003.

Very true. But SLEP 003 refers to a slightly different problem: the relation between the inputs and outputs of a single transformer. It does not address the fact that we can't tell which transformers in a ColumnTransformer generated which columns.

Consider the example above:

import numpy as np
from sklearn.compose import ColumnTransformer
from sklearn.preprocessing import Normalizer

ct = ColumnTransformer(
    [("norm1", Normalizer(norm="l1"), [1, 2]), ("norm2", Normalizer(norm="l1"), [0, 3])]
)
X = np.array([[0.0, 1.0, 2.0, 2.0], [1.0, 1.0, 0.0, 1.0]])
Xt = ct.fit_transform(X)

Xt has four columns. Each Normalizer generates two of those columns.

I could use the proposed get_feature_dependence of the first Normalizer to determine that column 1 of X is responsible for the first column in the output of this particular transformer. But I don't know which column of Xt corresponds to the first column in the output of "norm1". So I am not much wiser in the end.

On the other hand, I can combine transformers_output_ and get_feature_dependence to have a full mapping from each input column to each column in the output data, which is more informative.

I tried to make the docstrings more explicit, spun off the tests and changed the values in the dictionary to slices. Happy to change the name of the attribute too.

What is the state on this? I would be interested in this as well. @jnothman @thomasjpfan

Slices may not be the best representation, because the selected columns can be disjoint. In this case a boolean mask would be better.

With either solution, it may conflict with the discussion in #14251, which is if we are okay with allowing columns in transform, if they were not seen in fit.

it may conflict with the discussion in #14251

As far as I understand, #14251 is about input columns. This PR only relates transformers to columns in the output.

Slices may not be the best representation, because the selected columns can be disjoint

As far as I understand, columns in the output are never disjoint (unlike input columns, which are not the object of this PR).

As far as I understand, columns in the output are never disjoint (unlike input columns, which are not the object of this PR).

Ah yes, you are correct. This PR does not conflict with the issue.

I think it would be useful to extend one of the examples to showcase the new attribute, thus increasing the visibility of the new attribute. It may be difficult to find a examples to extend because we usually place the column transformer into a pipeline, where we do not need to connection between the name and the index of the feature output indices.

I think it would be useful to extend one of the examples to showcase the new attribute, thus increasing the visibility of the new attribute. It may be difficult to find a examples to extend because we usually place the column transformer into a pipeline, where we do not need to connection between the name and the index of the feature output indices

@thomasjpfan wouldn't this be a perfect match for the categorical_features of HistGradientBoosting ? #18394 (comment)

Thank you for working on this @lbittarello !