Add Clasp for time series segmentation (CIKM'21 publication)

[patrickzib]

Reference Issues/PRs

#1346

What does this implement/fix? Explain your changes.

This request implements ClaSP, a novel time series segmentation method published at CIKM '21.

The segmentation is implemented as an annotator, and the profile in ClaSP is implemented as a SeriesToSeriesTransformer.

[review-notebook-app]

Check out this pull request on 

See visual diffs & provide feedback on Jupyter Notebooks.

---

Powered by ReviewNB

[patrickzib]

@fkiraly two things I forgot to mention in my last commit :)

• find_dominant_window_sizes(ts): yes, this is a public utility function, as it is called e.g. in the notebook.

• The notebook and ClaSP use pd.Series. However, the formatting of pd.Series is not pretty in Jupyter Notebooks, thus it is wrapped by a pd.DataFrame for displaying purposes only. I wrote a comment above the call in the notebook.

[fkiraly]

Apologies for the wait - to speed things up, I've resolved some merge conflicts outside the remit of the PR, in the _config and test files.

Since it's partly my fault letting you wait that things got out of sync. Kindly check whether all is fine and feel free to revert.

[fkiraly]

I think the interfaces are now good - there are a few things I'd like to iterate on, but let's do that once the estimator is in.

However, we need to improve a few docstrings before this can be merged, or the automated documentation will not render properly.

I'm adding the comments below, please action those and then we can merge.

[patrickzib]

@fkiraly I have addresses your comments.

I appreciate your comments and the time you invest in reviewing. I also love sktime and its idea, which is why I am very willing to contribute. But please consider: you are starting to expect a level of industry-grade polishing of the code, which is barely present in the other module in sktime. But was for sure not present at the start of their development.

I spent some work days on this pull request now. And as of now, I am a bit unsure, if I will push our research to sktime in future times, as it is so time demanding to contribute.

Thus, there should be some debate on how to lower the burden of contributing to sktime.

[TonyBagnall]

Hi Patrick, don't let Franz put you off, it's his way. I'll take a look when I'm back, off for half term

[fkiraly]

I spent some work days on this pull request now. And as of now, I am a bit unsure, if I will push our research to sktime in future times, as it is so time demanding to contribute.

@patrickzib, what I've said above is that I'm happy to merge as long as the tests are!
Thanks a lot for your great contribution!

Sorry for the back-and-forth, that's related to the fact that this is a new "type" of estimator, and we've been consolidating design decisions together with the algorithm itself.

At the same time, I also need to think about our users, for whom clear usage and well-documented code is of course better - it's a difficult balance to strike sometimes. I'd say that balance is somewhere in the middle between "research-grade" and "industry-grade", so if both of us grow equally frustrated (coming from different directions) perfection is achieved.

We also wanted to write you an email about contributions, but since I read your frustration, perhaps it's better to say some of this in public: we really appreciate your dedication and your work! We were also thinking of asking you to take the lead on some annotation, changepoint, or segmentation related area if you would like to?

[fkiraly]

happy

[patrickzib]

@fkiraly thank you :)