[ENH] New transformation based pipeline classifiers

[MatthewMiddlehurst]

Implements new feature based pipelines for summary statistics, random intervals (with a new transformer to generate them) and a TSFresh based pipeline from an upcoming workshop paper by me and @TonyBagnall. We can probably close #1063 after this unless there are any objections.

There is quite a lot going on here, but the majority of new lines and file changes are just tests.

Does your contribution introduce a new dependency? If yes, which one?

No

What should a reviewer concentrate their feedback on?

The new estimators, they are relatively simple and most are basic transformer > classifier pipelines.
Files of interest are:

sktime/classification/feature_based/_fresh_prince.py
sktime/classification/feature_based/_random_interval_classifier.py
sktime/classification/feature_based/_summary_classifier.py
sktime/transformations/panel/random_intervals.py

[TonyBagnall]

Question: why are we introducing n classifiers following the pattern [transformer][classifier], but not a generic pipeline object that implements this pattern?

Makes sense to have shorthands, but it would be more robust if the shorthand is a shorthand for the composable pipeline?

we already have a pipeline, or do you mean a wrapper for a pipeline where transformer and classifier are specified in constructor? Something like a PipelineClassifier? Seems a bit superfluous and I thought you liked using pipelines directly, but I see no reason why not have one.

I agree its best to not have commented out code. Maybe put it all in a directory in contrib called regenerate tests or somesuch?

[MatthewMiddlehurst]

RE: Commented out sections for tests, that is a bigger issue than this PR (same pattern follows for most tests), but I don't mind doing it in a separate PR with all the others.

[TonyBagnall]

RE: Commented out sections for tests, that is a bigger issue than this PR (same pattern follows for most tests), but I don't mind doing it in a separate PR with all the others.

lets discuss at the dev meeting, I'll put together an agenda

[TonyBagnall]

@fkiraly could you rereview in the light of comments above please? ta

[TonyBagnall]

we agreed at the dev meeting to centralise the commented out code in a separate PR. @fkiraly does this answer your issues?

[fkiraly]

@fkiraly does this answer your issues?

Yes, happy if there's a separate issue that says what needs to be done.

What did you decide on the boilerplate/DRY issue?

[MatthewMiddlehurst]

I still don't really see an issue with the current set-up, issues such as SummaryClassifier multivariate output and extra functionality like train estimates in FreshPrince would not lend well to a generic pipeline.

Im not against having a generic pipeline wrapper for users. Using such a wrapper in the current pipelines would require a bit of unwrapping for the above cases, however.

[TonyBagnall]

so to summarise, we thought a wrapper containing a configurable pipeline was a layer of wrapping too far, and it is in fact preferable to encourage users to use a Pipeline, since sklearn users are familiar with them. There is not that much code repetition and not all classifiers could use the base class.

[fkiraly]

questions answered, looks fine to me now.

Can you please remove commented out code before you merge?

[TonyBagnall]

questions answered, looks fine to me now.

Can you please remove commented out code before you merge?

this is deferred to here #1765