Skip to content

Leaderboard link - #29

Open
TonyBagnall wants to merge 2 commits into
mainfrom
leaderboard-link
Open

TonyBagnall wants to merge 2 commits into
mainfrom
leaderboard-link

Conversation

@TonyBagnall

Copy link
Copy Markdown
Contributor

Summary

  • What does this PR change?

Checklist

  • I have updated documentation if needed.
  • I have added tests or validation steps if needed.
  • If this PR submits results, it follows results/schema.md.

TonyBagnall and others added 2 commits September 11, 2026 16:51
DisjointCNN, TimesURL and XCM were the last three without it, and all seven of
the Hali run's estimators returned. EmoPain joins the scored set, taking it from
56 to 57 of 64, and DisjointCNN, TimesURL and XCM each reach 66.

The dataset never needed rescaling. aeon's check_collection_variance flags pairs
with std <= 1e-7 and a nonzero range, and all 1733 of EmoPain's sit in channels
13 to 25, which are sparse rather than mis-scaled: 84% of their values are below
1e-5 while their peaks reach 1.55, the same range as the motion channels. aeon
relegated the check to a warning in #3598, and running on Hali with an aeon past
that commit was the whole fix.

XCM's result carries 'window_size': 0.8, so it is the fixed-parameter run the
other 65 use rather than the cross-validated search the lookup name now resolves
to. That was pinned in the Hali configuration for exactly this reason.

Accuracies span 0.628 to 0.848, with PatchMTSC and TimesURL highest and
DisjointCNN lowest, so nothing looks degenerate despite the flat channels.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
The ledger said "OOM at 64GB, exhausted the top memory tier (64GB)". Both halves
are wrong. The attempts reached 128 GB, and at that tier the job does not run out
of memory: it dies with "Segmentation fault (core dumped)" and no Python
traceback, three times.

The confusion is understandable. The five attempts at and below 64 GB were
genuine OOM kills, and the controller classifies a job that vanishes without
writing an error as OOM, which is the right default for a kill and the wrong one
for a segfault.

It matters because it changes what closes USCActivity. More memory has already
been tried and does not help; this needs a reproduction and a fix in RDST or
below it. Two details narrow it: USCActivity is 43060 cases, and RDST segfaults
on exactly one other dataset in the archive, PPGDalia_disc, which is also
large-case, so a numba routine indexing past the end once the case count is large
is the obvious suspect rather than anything about memory.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant