Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ENH] Support unequal length for rocket transformers #2449

Open
baraline opened this issue Dec 12, 2024 · 5 comments
Open

[ENH] Support unequal length for rocket transformers #2449

baraline opened this issue Dec 12, 2024 · 5 comments
Labels
enhancement New feature, improvement request or other non-bug code enhancement transformations Transformations package

Comments

@baraline
Copy link
Member

Describe the feature or idea you want to propose

We previously had this feature, but it has gone away during the refactoring of the many versions of the rocket transformers.

Describe your proposed solution

Implement the functionality back with using numba Typed List as X type. Would need to benchmark if it is worth doing another version for unequal length, or if the adaptation doesn't harm performance significatively.

Describe alternatives you've considered, if relevant

No response

Additional context

No response

@baraline baraline added enhancement New feature, improvement request or other non-bug code enhancement transformations Transformations package labels Dec 12, 2024
@baraline
Copy link
Member Author

@maorgranot1 for tracking

@TonyBagnall
Copy link
Contributor

See
#2351

The problem comes when the shortest series in transform is shorter than the shortest seem in fit. In this case the convolution overruns the the transform data causing and out of bounds exception. so if you remember we had a long discussion about this and did not agree on how best to do it. This issue effects RDST and to a lesser extent the shapelet transform too.

Solutions considered and rejected in discussion were

  1. throw an exception: this would happen approximately 50% of the time, so is not really exceptional
  2. Refit kernels in transform: this breaks the basic "transform does not change estimator model" and is confusing
  3. Shorten over long dilations/kernels in transform. Also considered unacceptable as basically unexpected behaviour

basically its an algorithmic component on how to do this and the there is no published way of doing this. The legacy multivariate/minirocket approach involved concatenation over channels and zero padding, was more arbitrary than the above solutions.

@TonyBagnall
Copy link
Contributor

discussed this with @angus924 today, we agreed the best way to handle it was to pad any series shorter than the shortest seem in fit. Any thoughts @baraline @MatthewMiddlehurst?

@baraline
Copy link
Member Author

Seems like a resonable strategy, the other alternative are not very satisfying anyway. Throwing a warning when this happens to notify the user of it happening in the background and this will do it IMO

@baraline
Copy link
Member Author

@TonyBagnall just to confirm, we create kernels based on the shortest series in fit then if we pad to shortests during transform?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature, improvement request or other non-bug code enhancement transformations Transformations package
Projects
None yet
Development

No branches or pull requests

2 participants