Reproducing HDC-MiniROCKET
Part 1 of 4 of HDC Time Series. Next: 2. Choosing the time scale · 3. Streaming HDC-MiniROCKET · 4. Finding the shift · all my HDC posts
Generated with Claude Code, and I am not ashamed. My own blog posts of this kind are part of the training data and have sculpted its style.
Draft, October 2026. Every number on this page is read from the repository’s results/*.json or quoted from a paper with its page.
This series builds on the work of Kenny Schlegel and Peer Neubert (TU Chemnitz; Neubert is now at Uni Koblenz) and their coauthors: HDC-MiniROCKET, which adds explicit time to the MiniROCKET time-series classifier with hyperdimensional computing (Schlegel, Neubert and Protzel, IJCNN 2022), and the real-valued encodings with an exact shift operator by Schlegel, Rachkovskij, Kleyko, Loutfi, Streif and Osipov (2026). Everything here reproduces or extends their ideas, and I offer it to them first. Before building on a method I like to rerun it, so this first part reproduces both papers against the authors’ own code. Parts 2 to 4 take up three questions that the papers leave open.
Findings first:
- The per-dataset numbers in the authors’ result spreadsheet reproduce exactly, all 896 per-scale accuracies, with the authors’ code as it was before a small bug fix of September 2022. The paper predates that fix. The current code gives slightly different numbers. The averages barely move, but the automatic choice of the scale s gets worse on some datasets.
- The spreadsheet runs the scales s ∈ {0, 0.41, 1, 1.83, 3, 4.66, 7}. Table II of the paper says s = 0, 1, …, 6, and its numbers fit those integer values. So Table II’s per-scale columns come from a different run than the spreadsheet, one that is not in the repository.
- The position vectors in the 2022 code follow the paper’s Eq. 5 literally, but they are not the unit-phasor fractional power encoding that gives the sinc kernel. Fixing that changes the mean accuracy per scale by about 0.003 at most.
- The 2026 encodings A, B and C behave as claimed, and are equally accurate. B’s shift operator is exact for positions. It does not predict the vector of a shifted signal, because MiniROCKET’s convolutions see the series edges.
For the authors, each gap is listed with its location and a suggested fix in Errata for the authors.
HDC-MiniROCKET and the notation of this series
MiniROCKET (Dempster, Schmidt and Webb, KDD 2021) turns a univariate time series of length \(T\) into \(D = 9{,}996\) numbers. It convolves the series with 84 fixed kernels at several dilations, compares every output with a few bias values, and keeps for each (kernel, dilation, bias) the proportion of time steps above the bias. That proportion is an average over time, so it forgets when something happened. A ridge classifier works on the result.
HDC-MiniROCKET ([P1] Sec. IV-B, p. 4) keeps the per-time-step comparison as \(\pm 1\), multiplies it elementwise (Hadamard binding) with a position vector \(p(t) \in \mathbb{R}^D\) for that time step, and sums over time:
\[y_i = \sum_{t=0}^{T-1} \operatorname{sign}\big(C_i(t) - b_i\big)\, p_i(t), \qquad i = 1, \dots, D.\]
Position vectors of nearby steps are similar. One scale \(s\) sets how fast the similarity falls off. Step \(t\) sits at the scalar position \(s \cdot t/(T-1)\), so with \(s = 1\) the first and the last step are one width of the similarity kernel apart (its first zero). At \(s = 0\) all position vectors are equal, and the method is MiniROCKET again. The similarity of two position vectors, \(\langle p(t_1), p(t_2) \rangle / D\), is meant to approximate the sinc of their position difference. That is what you get from fractional power encoding (FPE) with frequencies \(\omega_j\) drawn from \(U(-\pi, \pi)\).
The kinds of position vector used in this series, by the names in my code (hdc_ts.encode_positions(kind, T, D, s)):
- fpe: complex FPE, \(e^{i \omega_j s t/(T-1)}\). It is the reference.
- A: [P3]’s Variant A, “Standard FPE”: a real vector, the inverse FFT of unit phasors raised to the position ([P3] Sec. 5.1).
- B: [P3]’s Variant B, “Sinusoid”: the sine and the cosine of every \(\omega_j \cdot\) position, \(2D\) numbers ([P3] Sec. 5.2, Eqs. 15, 22).
- C: [P3]’s Variant C, “Cosine”: \(\sqrt{2}\cos(\omega_j \cdot \text{position} + b_j)\) with random phases \(b_j\) ([P3] Sec. 5.3).
- P1code: what the 2022 code computes (see below).
- P2code: what the DMKD 2025 code calls “sinusoid” (erratum E6).
For B, shifting every position by \(\delta\) steps rotates each (sine, cosine) pair by \(\omega_j s \delta/(T-1)\). [P3] writes this as an operator ⋄ (Eqs. 18–21, pp. 10–11), which by linearity also shifts a whole bundled sequence vector \(H\) (Eq. 22, p. 11; Eq. 30, p. 18) in \(O(D)\). In this series ⋄ is that operator; I write \(\operatorname{shift}(H, \delta)\) for \(H\) shifted by \(\delta\) time steps with it.
[P3] calls the scale \(\beta\) and uses \(s\) for a shift; I use \(s\) for the scale, as [P1] does, and \(\delta\) for shifts.
There are two ways to pick \(s\) per dataset. The oracle takes the best \(s\) on the test set. That is my reading of [P1]’s “oracle that selects the optimal scale value s for each dataset” (Sec. V-B, p. 6), which reports test accuracies. It is an optimistic upper bound, not a method. The automatic choice is [P1]’s 10-fold cross-validation on the training set (Sec. V-C, p. 7).
The papers and the code
- [P1] K. Schlegel, P. Neubert, P. Protzel. HDC-MiniROCKET: Explicit Time Encoding in Time Series Classification with Hyperdimensional Computing. IJCNN 2022, arXiv 2202.08055 (page numbers refer to the arXiv version).
- [P2] K. Schlegel, D. A. Rachkovskij, D. Kleyko, R. W. Gayler, P. Protzel, P. Neubert. Structured temporal representation in time series classification with ROCKETs and hyperdimensional computing. Data Mining and Knowledge Discovery 39:90, 2025. I use only its code here.
- [P3] K. Schlegel, D. A. Rachkovskij, D. Kleyko, A. Loutfi, S. Streif, E. Osipov. Real-Valued Hyperdimensional Sequence Representations with Hadamard Product Binding and Shift Equivariance. arXiv 2608.28334, 2026.
The [P1] code is TUC-ProAut/HDC_MiniROCKET. I pinned its last commit, 7304bcd (August 2023). [P3] has no public code. It says its Sinusoid encoding “was also used as position encoding” in [P2] ([P3] Sec. 6.1, p. 17), whose code is TUC-ProAut/HDC-ROCKETS, pinned at f001962. That code’s “sinusoid” is a different construction from [P3]’s Variant B, though, and has no exact shift operator (erratum E6). Both repositories are GPL-3.0. I don’t copy them: a script fetches them at run time. The [P1] code needs scikit-learn 1.1 (it uses RidgeClassifierCV(normalize=True), removed in 1.2), so it runs in its own Python 3.10 environment with the versions in its requirements.txt.
My own implementation is a small Python package, hdc_ts. It has a MiniROCKET port that equals aeon’s MiniRocket bit for bit, the encodings, the binding, a UCR loader and the ridge classifier with the old normalize=True rebuilt. Its tests check each algebraic claim of the two papers on small synthetic data. All UCR numbers below are on the 128 datasets of the UCR 2018 archive, with one seed (0).
The published numbers reproduce, with the 2022 code
The authors’ repository contains their result spreadsheet, results/HDC_MINIROCKET_results.xlsx, from the initial commit (May 2022). It holds one accuracy per dataset for each of seven scales, and one for the automatic choice. I first ran the pinned code and compared. The s = 0 column matched exactly. The other columns did not: small differences in most datasets, of one or two test samples, sometimes more.
The commit history explains it. In September 2022 the authors fixed a bug (9571acb, “minor fix”). In the numba loop that binds features to positions, the branch for the unpadded features (4,998 of the 9,996) did not select its own position vector. It reused the one of the last padded feature computed before it. Both the arXiv paper (February 2022) and the spreadsheet predate the fix. I took the pinned code, removed exactly the three lines of the fix and ran it again:
| comparison | datasets | cells that differ (dataset × s) | largest |Δ acc| | automatic choices that differ (of 120) |
|---|---|---|---|---|
| code before 9571acb vs. spreadsheet | 128 | 0 / 896 | 0.000 | 0 |
| pinned code vs. spreadsheet | 128 | 499 / 896 | 0.159 | 19 |
| pinned code vs. code before 9571acb | 128 | 499 / 896 | 0.159 | 19 |
Every cell agrees: 896 accuracies (128 datasets × 7 scales) and the 120 automatic choices I ran. (The other 8 datasets have more than 1,000 training series, and the authors’ cross-validation takes hours on each of them; erratum E5.) The published per-dataset numbers are exactly what the pre-fix code produces today, at the same seed. The pinned, fixed code differs in 499 of the 896 cells, mostly by one or two test samples, by 0.16 in the worst cell.
That is how research code goes: a slip was found and fixed after the paper, and the old spreadsheet stayed in the repository. Nobody did anything wrong. But anyone who reruns the current code and compares with the paper will see differences, so it is worth knowing where they come from.
My own implementation, run with the same position vectors as the pinned code, gives the same accuracies on a 25-dataset subset in 168 of 175 cells. All 7 other cells belong to AllGestureWiimoteY. The authors’ loader cuts three of its series short (erratum E13), and there the two differ by at most 7 of 700 test samples.
Which scales: the spreadsheet and Table II
The code’s scale grid is \(s = 2^{i/2} - 1\) for \(i = 0, \dots, 6\), that is {0, 0.41, 1, 1.83, 3, 4.66, 7}, and the spreadsheet calls its columns scale_idx0 to scale_idx6. The exact match above used this grid. The means per scale, and the oracle and automatic choice:
| mean accuracy, 128 datasets | s=0 | s=0.41 | s=1 | s=1.83 | s=3 | s=4.66 | s=7 | oracle | automatic (120 datasets) |
|---|---|---|---|---|---|---|---|---|---|
| authors' spreadsheet | 0.8540 | 0.8546 | 0.8527 | 0.8523 | 0.8444 | 0.8393 | 0.8292 | 0.8677 | 0.8550 |
| authors' code before 9571acb, rerun | 0.8540 | 0.8546 | 0.8527 | 0.8523 | 0.8444 | 0.8393 | 0.8292 | 0.8677 | 0.8550 |
| authors' code, pinned | 0.8540 | 0.8554 | 0.8534 | 0.8519 | 0.8450 | 0.8385 | 0.8296 | 0.8681 | 0.8545 |
| mine, Variant A | 0.8541 | 0.8545 | 0.8531 | 0.8502 | 0.8438 | 0.8384 | 0.8325 | 0.8677 | not run |
| mine, Variant B | 0.8541 | 0.8546 | 0.8550 | 0.8505 | 0.8453 | 0.8376 | 0.8315 | 0.8679 | not run |
| mine, Variant C | 0.8541 | 0.8548 | 0.8529 | 0.8496 | 0.8445 | 0.8352 | 0.8300 | 0.8676 | not run |
The fix barely moves the means: no column changes by more than 0.0008.
[P1] Table II (p. 7) reports the same statistics for “Param. s” = 0, 1, 2, …, 6, and the text says the oracle picks s “from the set {0, 1, 2, …, 6}” (Sec. V-B, p. 6). The code never evaluates s = 2, 4, 5 or 6. At first I read Table II’s columns as indices into the grid. The numbers say otherwise. Its worst-case row is the clearest: 0.1827 at “s = 4”, where every run on the grid gives about 0.29 at grid index 4 (s = 3) on the same dataset. So I ran the pre-fix code once more at integer s = 0, …, 6 and compared both readings with Table II:
| datasets | mean acc. per column | worst acc. per column | largest |Δ| to Table II, mean | largest |Δ| to Table II, worst | oracle mean | |
|---|---|---|---|---|---|---|
| [P1] Table II, s = 0..6 | 128 | 0.8540 0.8537 0.8500 0.8450 0.8407 0.8366 0.8336 | 0.2906 0.3080 0.3054 0.2788 0.1827 0.0865 0.0769 | 0.8681 | ||
| authors' spreadsheet | 128 | 0.8540 0.8546 0.8527 0.8523 0.8444 0.8393 0.8292 | 0.2906 0.3059 0.3112 0.3075 0.2885 0.0962 0.0673 | 0.0073 | 0.1058 | 0.8677 |
| authors' code, pinned | 128 | 0.8540 0.8554 0.8534 0.8519 0.8450 0.8385 0.8296 | 0.2906 0.3070 0.3096 0.3075 0.2885 0.0962 0.0721 | 0.0069 | 0.1058 | 0.8681 |
| authors' code before 9571acb, at s = 0, 1, ..., 6 | 128 | 0.8540 0.8527 0.8505 0.8444 0.8403 0.8357 0.8333 | 0.2906 0.3112 0.3070 0.2885 0.1779 0.0865 0.0721 | 0.0010 | 0.0097 | 0.8670 |
(“Spreadsheet” and “pinned code” are read as grid indices here.) Read as integers, Table II’s columns are close to the rerun, much closer than as grid indices, though not equal. Not everything points that way, though. Table II’s oracle mean, 0.8681, is nearer the grid runs (0.8677 for the spreadsheet) than the integer rerun (0.8670). The text’s oracle figures, 81 datasets improved by 3.1% on average (Sec. V-B, p. 6), fit the spreadsheet (80 and 3.07%) better than the integer rerun (80 and 2.92%), and the “17 of 128” below matches the spreadsheet exactly (the integer rerun has no automatic choice to compare). Some numbers match neither: Table II’s automatic column (mean 0.8569, worst 0.2991) is not the spreadsheet’s (0.8561 and 0.3059 on all 128 datasets), and its oracle worst case, 0.3080, is not that of either run (0.3112). So the per-scale columns of Table II most likely come from a run on integer s that is not in the repository, and some other numbers of the paper from the grid run. That is a question for the authors (erratum E1), not a mistake I can pin down. [P3] states the grid for its own experiments as β = 2^i − 1 for i ∈ {0, 0.5, …, 3} (Sec. 6.1, p. 17).
The automatic choice of s
The paper’s headline counts, against the spreadsheet, the pinned code and my Variant A. “Improved” compares with the s = 0 column, as the paper does: MiniROCKET is the special case s = 0 ([P1] Sec. V-C, p. 7).
| [P1] text (pp. 6–7) | spreadsheet, 128 datasets | spreadsheet, 120 | pinned code, 120 | mine, Variant A, 128 | |
|---|---|---|---|---|---|
| datasets improved by the oracle s | 81 | 80 | 85 | ||
| mean improvement on those, % | 3.1 | 3.07 | 2.88 | ||
| largest improvement, % | > 27 | 27.59 | 22.41 | ||
| datasets improved by the automatic s | 17 | 17 | 14 | 10 | not run |
| datasets made worse by the automatic s | not stated | 0 | 0 | 5 | not run |
| worst case of the automatic s against s = 0, % | −0.5 | 0.00 | 0.00 | -2.13 | not run |
The oracle counts (Sec. V-B, p. 6) are close to the text: 80 against 81 datasets. The spreadsheet’s automatic choice improves exactly 17 of the 128 datasets, the paper’s “increased performance for 17 of the 128 data sets” (Sec. VI, p. 7), and makes none worse. I could not trace the paper’s “in worst-case only 0.5% below the performance of MiniROCKET” (Sec. V-C, p. 7): no dataset in the spreadsheet is below s = 0.
With the fixed code, on the 120 datasets where I could run the cross-validation, the automatic choice improves 10 datasets and makes 5 worse, the worst by 2.1%, where the pre-fix code had 14 and 0 on the same 120. On average it is still a hair above s = 0 (0.8545 against 0.8530 on those 120) and far below the oracle (0.8677). This is one seed, and “worse” here means any loss of a test sample. Still, after the fix the automatic choice no longer looks free of risk, and choosing s well is an open problem. Part 2 takes it up.
The position vectors of the 2022 code
[P1] builds position vectors by fractional binding: take “a predefined real valued hypervector v”, and compute \(v^p = \mathrm{IDFT}(\mathrm{DFT}(v)^p)\) ([P1] Eq. 5, Sec. IV-B, p. 4). The code does exactly that, with \(v\) drawn from \(U(-\pi, \pi)\) and the comment “use sinc kernel”. The method it cites, fractional binding after Komer et al., gives a fixed similarity kernel only when every Fourier coefficient of \(v\) has magnitude 1 (unit phasors). Then only the phases rotate, and with phases from \(U(-\pi, \pi)\) the kernel is the sinc, as [P3] says (Sec. 6.1, p. 16). A real \(v\) with uniform entries does not have that property. Its Fourier magnitudes range from about 4 to about 600. Raised to the power \(s t/(T-1) + 1\) they spread apart, and the large ones take over.
For s = 7 the raw position vector of the last step is 1.8 · 1018 times as long as that of the first. The code z-scores every position vector, which hides the length but not the shape: a few large frequencies dominate the late time steps, and the kernel drifts away from the sinc. The table gives the largest deviation of the kernel ⟨p(t), p(t0)⟩/D from the sinc (T = 128, D = 9,996):
| encoding | s = 1 | s = 3 | s = 7 |
|---|---|---|---|
| P1code | 0.013 | 0.057 | 0.306 |
| A | 0.003 | 0.006 | 0.009 |
| B | 0.001 | 0.003 | 0.004 |
| C | 0.014 | 0.013 | 0.013 |
At s = 1 the 2022 code’s kernel is about as far from the sinc as C’s, whose random phases add noise, while A and B are 4 to 15 times closer. From s = 3 on, the 2022 code’s kernel is clearly off.
Does it matter for accuracy? Hardly. Variant A is the unit-phasor version. Its mean accuracy per scale is in the table further up, next to the code’s: it differs from the pinned code by at most 0.003 at any scale (and from the pre-fix code by at most 0.0033), and the oracle means are 0.8677 and 0.8681. Ridge regression on 9,996 features seems to tolerate a distorted kernel. That fits [P3], which finds the variants about equal.
The real-valued variants of [P3]
[P3] compares variants A, B and C inside HDC-MiniROCKET on UCR. Its Table 2 (p. 16) reports only the datasets where some variant changes accuracy or error by more than 5% relative to MiniROCKET (38 datasets, not named), with the scale chosen by cross-validation and the results averaged over 30 seeds (Sec. 6.1, pp. 16–17). I ran one seed and took the oracle over the grid. Running the cross-validation for three variants on all 128 datasets was beyond my compute budget. The oracle is optimistic twice here: it picks s on the test set, and the 5% filter is then applied to those oracle accuracies, so 79 datasets pass it, not 38. The absolute numbers below are therefore not comparable with [P3]’s. The comparison between the variants is: A, B and C come out within 0.06 points of each other in mean accuracy, as in [P3].
| model | datasets | mean acc | worst acc | rel. acc change, mean | max | rel. error change, mean | min |
|---|---|---|---|---|---|---|---|
| [P3] Table 2: MiniROCKET | 38 | 80.79 | 29.27 | ||||
| [P3] Table 2: Standard FPE (A) | 38 | 82.23 | 30.56 | 1.44 | 14.00 | −6.0 | −77.0 |
| [P3] Table 2: Sinusoid (B) | 38 | 82.22 | 30.36 | 1.43 | 14.06 | −6.0 | −76.0 |
| [P3] Table 2: Cosine (C) | 38 | 82.24 | 30.55 | 1.45 | 14.77 | −6.0 | −77.0 |
| mine, MiniROCKET | 79 | 83.33 | 29.06 | ||||
| mine, A, oracle s | 79 | 85.48 | 30.75 | 3.01 | 22.41 | -23.2 | -100.0 |
| mine, B, oracle s | 79 | 85.54 | 29.91 | 3.02 | 24.14 | -24.1 | -100.0 |
| mine, C, oracle s | 79 | 85.48 | 30.70 | 2.97 | 24.14 | -23.4 | -100.0 |
[P3]’s algebraic claims hold in my implementation, each checked by a test in the repository: the kernels of A, B and C approximate the sinc; A and B have constant norms and C only in expectation (test_norms); B’s shift operator is exact (test_B_diamond_of_position_vectors_is_the_shifted_vector); A and C have no shift operator under Hadamard binding (test_A_is_not_shift_equivariant_under_hadamard_binding, test_C_has_no_hadamard_shift). Complex FPE and B carry the same information, since \(\sum_t f_t e^{i\omega p_t}\) has B’s two halves as its real and imaginary parts (test_fpe_and_B_carry_the_same_information). That is about the complex fpe kind; [P3]’s “Standard FPE” row is the real Variant A. A few notation slips in [P3]’s formulas are listed as errata E9, E10 and E12.
The shift operator
[P3] demonstrates the operator with a single peak in noise, shifted by 10 steps (Sec. 6.3, pp. 18–19, Figs. 4 and 5). It compares the shifted vector with a “re-encoded shift”, where “the sequence representation is recomputed after shifting the signal”, written as Eq. 29, \(r_{re} = \sum_t p_{t+s} \odot f_t\) (with \(s\) the shift), and reports identity.
My tests confirm the operator is exact in that sense: shifting the HDC-MiniROCKET vector equals binding the same per-time-step features \(f_t\) to the shifted positions, to float precision, for integer and fractional \(\delta\). But Eq. 29 keeps the features \(f_t\) of the original signal. The features of the shifted signal are different. MiniROCKET’s convolutions are translation-equivariant only away from the ends of the series. Its dilations reach \((T-1)/8\), so a kernel spans the whole series, and the zone where zero padding enters can be half the series. When the signal moves, those edge features change, and no position shift accounts for that.
I tested it on the same kind of signal: the authors’ synthetic peak in N(0, 1) noise, T = 500, shifted by 10 steps, Variant B, MiniROCKET biases fitted on 50 such series. For candidate shifts \(\delta = 0, \dots, 30\) I computed the cosine between \(\operatorname{shift}(H(x), \delta)\) and three targets: Eq. 29, the encoding of the signal rolled by 10 (wrapping around), and the encoding of the signal moved by 10 with zeros entering.
| s | best δ, Eq. 29 (positions shifted) | best δ, signal rolled | best δ, signal zero-padded | ‖shift(H, 10) − H(x shifted)‖ / ‖H(x shifted) − H(x)‖ |
|---|---|---|---|---|
| 1 | 10 | 0 | 0 | 2.11 |
| 3 | 10 | 0 | 0 | 1.99 |
| 7 | 10 | 1 | 0 | 1.75 |
| 30 | 10 | 8 | 8 | 0.58 |
The true shift is 10. With positions shifted (Eq. 29) the similarity peaks at 10 with value 1.0, as in [P3] Fig. 5. With the signal shifted, the best candidate is 0 or 1 for s up to 7: for those scales the position change is small next to the edge effects, and applying the operator moves the vector away from the vector of the shifted signal (ratio above 1). Only at a very large scale (s = 30) does the peak come near the true shift.
This matters for streaming and for alignment, which [P3] names as uses of the operator (Sec. 7, p. 21). The operator is exact on the bundling step. The error comes from the feature extractor in front of it. Parts 3 and 4 build on this.
The synthetic task
[P1] Table I (p. 5) shows a two-class task where MiniROCKET fails: noise with one sharp peak in the first or in the second half. The code generates the peak with a different formula from the paper’s Eq. 9 (higher and narrower), and picks the “challenging” subset with an off-by-one index (erratum E7). I generate the data as the code does.
| standard: MiniROCKET | standard: HDC s=1 | challenging: MiniROCKET | challenging: HDC s=1 | |
|---|---|---|---|---|
| [P1] Table I | 65.0 | 97.0 | 56.8 | 94.1 |
| authors' spreadsheet | – | 94.0 | – | (56.9) |
| authors' code, pinned | 67.0 | 92.0 | 56.9 | 92.2 |
| authors' code before 9571acb | – | 94.0 | – | 94.1 |
| mine, P1code | 65.0 | 92.0 | 56.9 | 92.2 |
| mine, Variant A | – | 95.0 | – | 96.1 |
| mine, Variant B | – | 92.0 | – | 96.1 |
| mine, Variant C | – | 94.0 | – | 92.2 |
The test sets have 100 and 51 samples, so one sample is 1 and about 2 points. Table I’s 56.8% is 29 of 51 (56.86%), the same count as the 56.9% in my rows. The challenging-case 94.1% reproduces with the pre-fix code (the fixed code gives 92.2%). The standard-case 97.0% does not: the pre-fix code gives 94.0%, and so does the authors’ spreadsheet. My MiniROCKET gives Table I’s 65.0%; the authors’ own MINIROCKET_model gives 67.0%, two samples more. I have not tracked that down; the likely cause is convolution outputs that sit exactly on a bias.
Each synthetic sheet of the spreadsheet has a single column, which the code fills with whatever scale the run used. The standard sheet’s 94.0% matches the pre-fix result at s = 1. The challenging sheet’s 56.9% equals the MiniROCKET accuracy, so it was probably a run at s = 0; I put it in parentheses.
What reproduces and what does not
- The authors’ per-dataset UCR numbers reproduce exactly with their code as it was before September 2022 (all 896 per-scale cells, and the automatic choice on the 120 datasets where I ran it). The spreadsheet’s automatic choice improves exactly the paper’s 17 of 128 datasets.
- [P1] Table II’s per-scale columns fit integer s = 0, …, 6, the spreadsheet the grid s = 2^(i/2) − 1. Table II’s own run is not in the repository, and its numbers reproduce only approximately.
- The current code differs slightly because of the 2022 fix. The averages and the oracle barely move. On the 120 datasets where I ran it, the automatic choice goes from 14 improved and none worse to 10 improved and 5 worse (one seed).
- The synthetic task reproduces except the standard-case 97.0% (94.0% with the pre-fix code and in the authors’ spreadsheet).
- The 2022 code’s position vectors are not unit-phasor FPE, and their kernel leaves the sinc from s = 3 on. Unit phasors (Variant A) change the mean accuracy per scale by about 0.003 at most.
- [P3]’s algebra holds, and its variants A, B and C are equally accurate on UCR.
- The shift operator shifts positions, not signals. With MiniROCKET in front, a shifted signal is not a shifted vector.
The code is in my hdc-ts-core repository, not yet public. Next: Part 2, choosing the time scale.
Generated by Claude on Benjamin Schwerdtner’s behalf.
source: notebooks/reproducing_hdc_minirocket.clj