[BUG] Fix Catch22 TypingError on float32 input with outlier features - #3747
[BUG] Fix Catch22 TypingError on float32 input with outlier features#3747Nandinisingh07 wants to merge 4 commits into
Conversation
The outlier_series placeholder in _transform_case_numba was hardcoded to float64, which numba's nopython mode could not unify with the float32 z-normalised series produced for features 13/14 (outlier_include / outlier_include_n), raising a TypingError for any float32 input when outlier_norm=True. Fixed by deriving the placeholder's dtype from the input series via series[:0] / 1, matching the promotion rule _as_normalised_float already uses elsewhere (float32 stays float32, everything else becomes float64). Verified against all dependent estimators: Catch22, Catch22Classifier, Catch22Clusterer, CanonicalIntervalForestClassifier, DrCIFClassifier, RISTClassifier, HIVECOTEV2. Adds a regression test covering both outlier_norm=True and False on float32 input.
aeon-actions-bot
Bot
added
bug
Thank you for contributing to
|
|
Hii! |
baraline
left a comment
baraline
left a comment
There was a problem hiding this comment.
Hi, thanks for working on this, some comments
| float32 z-normalised series produced for features 13/14 (outlier_include / | ||
| outlier_include_n), raising a TypingError for float32 input. | ||
| """ | ||
| X = np.random.default_rng(0).standard_normal((6, 1, 40)).astype(np.float32) |
There was a problem hiding this comment.
This needs to be replaced with the existing testing utils (make_example_3d_numpy) to generate 3D data. You need to keep the float32 cast
There was a problem hiding this comment.
Updated to use make_example_3d_numpy with the float32 cast kept — see db44123.
There was a problem hiding this comment.
This will be float64 by default, extracting/storing features with float64 precision on a float32 input is against our goal I think.
Any thoughts on this ? @TonyBagnall @MatthewMiddlehurst
There was a problem hiding this comment.
Fixed in 7a5a783 — c22 is now built via _zeros_promoted(X[0], n_feats * len(X)), so it keeps the input's dtype instead of defaulting to float64.
| # / 1 applies the same dtype promotion z_normalise_series_with_mean | ||
| # uses internally (float32 stays float32, everything else becomes | ||
| # float64), so this placeholder always matches the real value's dtype. | ||
| outlier_series = series[:0] / 1 |
There was a problem hiding this comment.
Even if we override the value afterward, I'd rather want a helper function to init an empty array to the correct type/shape.
There was a problem hiding this comment.
Added the _zeros_promoted helper as requested in 7a5a783 — it's used both here and for the c22 buffer above.
…d helper for dtype-preserving c22 output
|
@baraline @TonyBagnall @MatthewMiddlehurst All checks are passing. Ready for another look whenever you get a chance! |
2 participants
Reference Issues/PRs
Fixes #3721
What does this implement/fix? Explain your changes.
Catch22raised anumba.core.errors.TypingErrorfor any float32 inputwhen
outlier_norm=True(the default), via the compiled 3D-input path_transform_case_numba.The
outlier_seriesplaceholder used for features 13/14(
outlier_include/outlier_include_n) was hardcoded tonp.float64.When the real z-normalised series was computed for a float32 input series,
numba's nopython mode could not unify the float64 placeholder type with
the float32 array being assigned to it, and compilation failed.
The fix derives the placeholder's dtype from the input series itself via
series[:0] / 1, matching the same dtype-promotion rule already used by_as_normalised_floatelsewhere in the codebase (float32 stays float32,every other dtype normalises to float64).
Does your contribution introduce a new dependency? If yes, which one?
No.
What should a reviewer concentrate their feedback on?
series[:0] / 1) versus theoriginal
np.empty(0, np.float64)placeholder, and whether thisaligns with
_as_normalised_float's documented promotion rule.(float32 input,
outlier_norm=Trueandoutlier_norm=False).Any other comments?
Verified manually against all 6 estimators listed in #3721 as affected:
Catch22,Catch22Classifier,Catch22Clusterer,CanonicalIntervalForestClassifier,DrCIFClassifier,RISTClassifier,HIVECOTEV2— all pass cleanly with no dtype errors on float32 input.PR checklist
[DEP] or [GOV]