Some notes on how to compute the various quantities. Mostly so I don't lose them. Based on the example given in "Splitting categorical predictors ..".

# contingency matrix, given in the example, would have to construct it
labels = ["PS", "NP", "PR"]  # unused, just for completeness
categories = ["G","B","P","DO","LO","Y","R"]

C = np.array([[20, 3, 1], [19,4,2], [25,4,7], [64,4,20], [16,1,5], [100,2,3], [200,3,4]])
P = (C / C.sum(axis=1).reshape(-1,1))
pbar = C.sum(axis=0) / C.sum()

sigma = np.zeros((3,3))
for a in range(P.shape[0]):
  sigma +=  (C.sum(axis=1)[a] * np.outer((P[a, :] - pbar), (P[a,:] - pbar).T))

w, v = np.linalg.eig(sigma)
v0 = v[:, np.argmax(w)]

for a, category in enumerate(categories):
    print(category, a, v0 @ P[a, :])

Each categorical value of a feature should be replaced by v0 @P[a, :], where a is the index that corresponds to the value of the category.

An open question for me is how to measure how good this kind of transformation is compared to the exhaustive split

I assume that we should at least benchmark as in:

https://scikit-learn.org/dev/auto_examples/ensemble/plot_gradient_boosting_categorical.html#sphx-glr-auto-examples-ensemble-plot-gradient-boosting-categorical-py

I am not against having this encoder until we can show that it works in practice and that it kind of scales. However, I think that we should tend to have a similar user experience for tree-based models (DT and RF, even exact GBDT) as the HGBDT, meaning going towards the implementation proposed in #24907, where the magic happens within the trees.

From a quick read of #18894 which seems to be the "source" of #24907 the proposal there is to use a category encoder inside hist gradient boosting. This means users won't have to create a pipeline anymore to do the encoding themselves, the estimator takes care of it (kinda like a "built in" pipeline). Having an additional transformer like the one proposed here that can deal with nominal (no order) categories seems like a good thing.

Hey @betatim - is there a possibility I could help contribute on this? Would love to help and learn. Thank you.

My current plan is to write a bit of code and open a PR tomorrow. I'm not sure yet how we could best collaborate on the PR (maybe Prs to the PR?). Getting another pair of eyes on it is good though because reviewer time is often the bottleneck. So maybe that is a way to collaborate.

Totally up for it @betatim, PR to a PR or with anything that could help you save time. Looking forward to it.

For linking purposes, #17323 introduces "impact encoder" or "target encoder" that converts categories into numerical values. I plan on revisiting it soon and likely bring it closer to cuml's TargetEncoder.

As for this issue, I suspect there are not enough citations to adopt the proposed feature.

Do you know how many citations the target encoding in cuml (or really any of the many variations of target encoding) have? The cuml docs link to https://maxhalford.github.io/blog/target-encoding/ which, after a quick browse, doesn't link to a paper.

I think one problem that the approach from Splitting on categorical predictors in random forests has is that it has "target leakage". The values of y are used during the construction of the features. This means the features contain information about what the value of y is. Same as all the other target encoders. So we need a way to solve that, some form of splitting the data like the cuml TargetEncoder does?

So we need a way to solve that, some form of splitting the data like the cuml TargetEncoder does?

Yea, the implementations of TargetEncoder that do not leak target data are the ones that splits the data multiple times during training. In the past, I ran benchmarks that shows that data splitting is required for TargetEncoder to work. There is also this benchmark paper that concludes the same thing.

For reference, here are some repos containing benchmarks from different sources:

• https://github.com/DenisVorotyntsev/CategoricalEncodingBenchmark
• https://github.com/jorisvandenbossche/target-encoder-benchmarks
• https://github.com/thomasjpfan/sk_encoder_cv (I experimented with some target encoding schemes trying to keep fit.transform == fit_transform. None of these experimental encoding schemes fit in scikit-learn, because we do not to invent anything here).

With the data splitting, we will unfortunately end up with fit(X, y).transform(X) != fit_transform(X, y). During fit, the training data is split such that a subset of the data is used to encode the categories in the other subset. At the end of fit, all the training data is used to encode the categories, which is used during prediction time.

TLDR: If we include a target encoder in scikit-learn, it likely will be the one that splits the data in fit where fit.transform != fit_transform. This breaks our API convention, but it is required for a target encoder to work. In our glossary entry for fit_transform, we do allow for this inconsistency.

Another big library that contains many different categorical encoders https://contrib.scikit-learn.org/category_encoders/