pycaret object oriented interface and contraction

@ngupta23, after playing around with pycaret a bit, I would suggest we adopt an object oriented interface between the two packages. Let me know what you think.

Currently, pycaret can use sktime estimators, but what would be really great if:

• it can export fitted and “blueprint” estimators after the “easy user workflow” is run
• it can reference “stock” estimators like detrend/deseaslonalize/something which is currently used as a list of defaults

What I would find useful here is work on two things:

• the described export functionality
• a “contraction” operation: this is a function contraction where you pass a composite estimator, e.g., Pipeline(("step1", Deseasonalize(sp=12)), ("step2", ARIMA(p=4, d=3, q=2))). The output is a class which behaves like an sktime forecaster (or estimator of the same type). Paramters of the contracted composite are mapped onto parameters of the class. In contract you can choose which parameters are visible/exposed, and which are not. Defaults are set to the settings of the argument.

For instance,

contraction(
    Pipeline(("step1", Deseasonalize(sp=12)), ("step2", ARIMA(p=4, d=3, q=2))),
    param_expose = ["step2__p", "step2__d"]
    )

would give an estimator class which has parameters sp and q, their defaults being 12 and 2. The parameters p and d are not visible in that class, but the internal behaviour has these set to 4 and 3.

This way, you can define your pycaret default forecasters as shorthands PycaretForecaster1, PycaretForecaster2 or whatever you like, and plugging them as defaults into the workflow should be much more convenient.

With the sktime machinery, we can also easily adopt this for scikit-learn native estimators, so it would not just be restricted to forecasting.

[ngupta23]

Actually, I mean this for the hard-coded pipelines that come with pycaret. That would give you an easy option to “fix” the pycaret curated pipelines to easily usable shorthands.

But the idea also extends to users, if they have their “favourite” pipelines for their deployment use cases.

Yes, I was thinking more of the lines of what @mloning did for the M4 benchmarking where he created various combinations of pipelines. There is no way we can include all possible combinations of model pipelines in pycaret. So we need to provide additional flexibility for users to provide their own pipeline.

We will eventually also move these internal model pipelines into its own dedicated package so that after deployment, the exported models can be used without installing the heavy pycaret package (would just need sktime and the lightweight model package).

Let’s discuss in the combined design session.

@Yard1 @pycaret

[fkiraly]

We will eventually also move these internal model pipelines into its own dedicated package so that after deployment, the exported models can be used without installing the heavy pycaret package (would just need sktime and the lightweight model package).

Excellent idea!

I think mlr and mlj follow similar models, but not sure how precisely this would look like for sktime, so looking forward to the discussion.