[ENH] BroadcasterTransformer to broadcast a series transformer over a collection

[TonyBagnall]

Currently, BaseTransformers can handle both single series and collections by internally "Vectorize" (i.e. broadcast) across channels and instances depending on the input data. This is legacy code which to me very confusing, involves huge amounts of redundant checks and is not maintainable by the current team. We should imo move away from this model.

This is a quick mock up of my favoured solution, for comment. I've not tested it properly yet, putting it up before I go too far down the line. Basically have a BroadcastTransformer that we pass a BaseSeriesTransformer which is applied over all instances in a collection.

Main points

1. It takes all its tags from the series transformer. These should then be checked in the base class
2. It does not broadcast over channels. If the SeriesTransformer cannot handle multivariate, nor can the Broadcaster.
3. If fit is empty is true in the SeriesTransformer, then Broadcaster only uses a single instance of the SeriesTransformer. If fit is empty is false, it clones it n_cases times and stores the transformers
4. it calls the private fit/transform of the SeriesTransformer. The assumption is that if it passes checks in the BaseCollectionTransformer, and the tags are taken from SeriesTransformer, then this should be fine. I think this should be true. If its not, we should make it so.

[aeon-actions-bot]

Thank you for contributing to aeon

I have added the following labels to this PR based on the title: [ $\color{#FEF1BE}{\textsf{enhancement}}$ ].
I would have added the following labels to this PR based on the changes made: [ $\color{#41A8F6}{\textsf{transformations}}$ ], however some package labels are already present.

The Checks tab will show the status of our automated tests. You can click on individual test runs in the tab or "Details" in the panel below to see more information if there is a failure.

If our pre-commit code quality check fails, any trivial fixes will automatically be pushed to your PR unless it is a draft.

Don't hesitate to ask questions on the aeon Slack channel if you have any.

[baraline]

A drawback of our current approach is that a transformer that needs to be fitted could only be broadcasted to a set of samples from the same size. For example if we had X1.shape = (5, 1, 100) used for fit and then transform, a set X2.shape = (10, 1, 100) could not be transformed, as we stored the 5 transformer fitted on X1.
But I don't know if this would ever happen considering we are broadcasting a single series transformer, which by essence (if fit is not empty) fits and transform one series.

[baraline]

Here is a draft for using joblib, need to add some tests and sort out tags for input format, as for now the example using MatrixProfileSeriesTransformer fails because it didn't convert the series to univariate as expected

[baraline]

To-dos left for this PR before it is ready for review:

• Fix broadcaster test, seem to be failing some check in cases where fit_empty=True in the broadcasted series transformer
• Add new broadcaster transformer to the docs
• Add an example notebook on how to use the broadcaster for different use cases
• Add type hints when not a union of lot of possible input types

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[MatthewMiddlehurst]

So is the essentially intended to be the parallel of https://github.com/aeon-toolkit/aeon/blob/main/aeon/transformations/collection/_collection_wrapper.py?

I think we should attempt to unify design a bit for these, the collection version currently does not use the series transformer base class. Don't have to change the collection version in this PR of course.

I prefer CollectionToSeriesWrapper or similar to the current name.

[MatthewMiddlehurst]

included the coverage tag, just to make sure most of it is happening correctly

[baraline]

Thanks for reviewing ! Concerning your questions:

So is the essentially intended to be the parallel of https://github.com/aeon-toolkit/aeon/blob/main/aeon/transformations/collection/_collection_wrapper.py?

Isn't _collection_wrapper.py a Collection to Series while the introduction of this PR is a Series to Collection ? (In the Collection to Series cases, there is no need for parallel I think ?)

I think we should attempt to unify design a bit for these, the collection version currently does not use the series transformer base class. Don't have to change the collection version in this PR of course.
I prefer CollectionToSeriesWrapper or similar to the current name.

I agree, both Collection to Series and Series to Collection transformers should be close to each other.
So It would be SeriesToCollectionWrapper and CollectionToSeriesWrapper (for _collection_wrapper.py, already implemented)

[TonyBagnall]

there is in fact a problem calling _fit, since the X_inner_type of collections and series are fundamentally different, will unfortunately have to call base class fit