transformer/regressor API question

[BalzaniEdoardo]

Hi everyone in the scikit-learn community. First of all, thanks for the amazing package!

Lately, I have been developing a package for statistical analysis time series in neuroscience, and I wanted to conform more to the scikit-learn API. However, the main class for constructing features in the package (called Basis) can receive multiple inputs, typical syntax,

feature = Basis.compute_features(x1, x2,...)

I would like for this constructor to conform to the transformer API, so that one could call sklearn pipelines on it, so i ended up with a sort of hack, a class that basically makes my constructor a transformer,

class TransformerBasis:

    def __init__(self, basis):
        self._basis = basis

    def fit(self, X: NDArray, y=None):
        self._basis.set_kernel(*X.T)
        return self

    def transform(self, X: NDArray, y=None) -> NDArray:
        return self._basis._compute_features(*X.T)

    def fit_transform(self, X, y=None):
        return self._basis.compute_features(*X.T)

Q1: is there a better way to comply with the transformer API than the one I have currently adopted (without changing the API for Basis drastically)?

Q2: why is the signature for the transformer's fit , transform and fit_transform methods so restrictive, allowing for one positional and one optional argument? why would something like def fit(*X, y=None):, with the assumption of matched first dimension, be a bad idea?

Thanks in advance!
Edoardo

[glemaitre]

Q1: is there a better way to comply with the transformer API than the one I have currently adopted (without changing the API for Basis drastically)?

Your code makes me think about the GaussianProcess in scikit-learn. basis would be equivalent to kernel parameters (https://github.com/scikit-learn/scikit-learn/blob/f07e0138b/sklearn/gaussian_process/kernels.py) and the transformer would be the role of the regressor/classifier (GaussianProcessRegressor or GaussianProcessClassifier) that take kernel as a parameter.

So I would probably check if the design pattern is close to this.

Q2: why is the signature for the transformer's fit , transform and fit_transform methods so restrictive, allowing for one positional and one optional argument? why would something like def fit(*X, y=None):, with the assumption of matched first dimension, be a bad idea?

Scikit-learn was thought and designed for structured data such as tabular data learning. Generally, this is a bad idea to think about to much generic design and/or thinking about use-cases that one doesn't have at hand.

So X here is expected and it is strictly designed to be a matrix of n_samples by n_features.
This said, today we start to have an experimental support for accepting metadata and route them to the estimator: https://scikit-learn.org/dev/metadata_routing.html#metadata-routing. I don't know if this could be helpful for your use-case.

[BalzaniEdoardo]

Thanks for the answer. The kernel has a very similar design indeed!

For GPs it makes total sense to have it as part of the model, for now, in my case, I thought of the basis as a "feature constructor" similar to sklearn.preprocessing.PolynomialFeatures but it could be easily incorporated as parameter.

This was very helpful, I'll look more into the metadata-routing!