[ENH] univariate MiniRocket via 2D input and float32/float64 kernels without casting

[sssilvar]

Reference Issues/PRs

None.

What does this implement/fix? Explain your changes.

Adds univariate MiniRocket support to the existing compute API:

• rocket_fit / rocket_transform now accept a 2D (n_instances, n_timepoints) panel in addition to 3D. 2D input is the single-channel case (n_instances, 1, n_timepoints).
• No separate univariate functions: on one channel, the multivariate algorithm always selects channel 0, and bias fitting re-seeds before drawing instance indices. The result is bit-identical to a dedicated univariate path. The same holds in sktime: MiniRocket and MiniRocketMultivariate produce identical features on single-channel input.
• Empty panels and inputs that are not 2D or 3D are rejected with a ValueError.
• The Cython kernels are fused over float32/float64 (as in [ENH] Add multirocket multivariate cython implementation #7), so float64 input is no longer copied to float32. Values are rounded to float32 as they are read, so results are bit-identical to casting first and match sktime MiniRocket, which works in float32. Computing natively in float64 was 1.5–1.9× slower in transform and would drift from sktime.

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

No.

What should a reviewer concentrate their feedback on?

• Whether accepting 2D input in rocket_fit / rocket_transform is the preferred way to expose the univariate case.
• Computing in float32 for float64 input (matching sktime MiniRocket) rather than natively in float64 as in [ENH] Add multirocket multivariate cython implementation #7.

Any other comments?

2D output matches sktime MiniRocket across multiple seeds, kernel counts and dilation limits. 2D and (n, 1, d) input give identical parameters and features, including the threaded path.
float64 and integer input give parameters and features identical to casting to float32 first.

PR checklist

For all contributions

• I have added myself to the list of contributors.
• Optionally, I have updated sktime CODEOWNERS to receive notifications about future changes to these files.
• I have added unit tests and made sure they pass locally.

For new estimators

• I have added the estimator to the README estimator table.

🤖 Generated with Claude Code

[fkiraly]

Looks great, the reuse is also good.

The only thing I am confused about is that the function names are now rocket vs minirocket, but both are, in fact, minirocket, just uni vs multivariate?

I am also confused about the following: suppose we pass an X of size (n, 1, d) to rocket_fit, how does this compare to passing the same X of size (n, d) to minirocket_fit, and so on?

Is this the same, or a different function?

If it is a different function, what exactly differs?

[sssilvar]

Thanks @fkiraly, good catch: they are the same function. For X of shape (n, 1, d), rocket_fit/rocket_transform and the former minirocket_fit/minirocket_transform on X[:, 0] gave bit-identical parameters and features. With one channel, the multivariate path always selects 1 channel (index 0), both re-seed before drawing instance indices, and both call the same Cython kernels. The only differences were the input shape (2D vs 3D) and the parameter tuple layout (3 vs 5 elements). The same holds in sktime itself: MiniRocket and MiniRocketMultivariate produce identical features on single-channel input; the split there is historical, since each has its own numba kernel.

So I dropped the separate univariate functions. rocket_fit/rocket_transform now also accept 2D (n_instances, n_timepoints) input as the univariate case. Tests check 2D output against sktime MiniRocket and check that 2D and (n, 1, d) input give identical results.

[fkiraly]

Perfect. So I did suspect correctly that these were just minor variations of the same function! That already bothered me about the implementations in sktime.

One minor nit, you committed a uv.lock, I would recommend you add that to the gitignore and remove from the PR, or it accidentally ships with the package.

[sssilvar]

Perfect. So I did suspect correctly that these were just minor variations of the same function! That already bothered me about the implementations in sktime.

One minor nit, you committed a uv.lock, I would recommend you add that to the gitignore and remove from the PR, or it accidentally ships with the package.

Done by accident, indeed. I've added the file to the gitignore.