[BUG] Preserve float32 dtype in affected transformers. by 4nmus · Pull Request #3752 · aeon-toolkit/aeon

4nmus · 2026-08-17T17:42:53Z

Reference Issues/PRs

Fixes part of #3723.

What does this implement/fix? Explain your changes.

Preserves float32 output precision in the following transformers:
DWTTransformer
Resizer
SlopeTransformer
SupervisedIntervals
PLASeriesTransformer

Previously, these transformers could unnecessarily promote float32 input to float64 through explicit casts or default NumPy allocations.
The changes preserve the following dtype behavior:
-float32 input produces float32 output
-float64 input produces float64 output
-integer input is promoted to float64

Regression tests were added or updated to verify dtype behavior for float32, float64, and integer inputs.

ClaSPTransformer, which is mentioned in #3723, is not included in this PR because its existing float64 conversion is related to a separate Numba typing constraint.

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

No.

Any other comments?

ClaSPTransformer still returns float64 since it forces the input to be float64 due to Numba.

PR checklist

For all contributions

I've added myself to the list of contributors. Alternatively, you can use the @all-contributors bot to do this for you after the PR has been merged.
The PR title starts with either [ENH], [MNT], [DOC], [BUG], [REF], [DEP] or [GOV] indicating whether the PR topic is related to enhancement, maintenance, documentation, bugs, refactoring, deprecation or governance.

For new estimators and functions

I've added the estimator/function to the online API documentation.
(OPTIONAL) I've added myself as a __maintainer__ at the top of relevant files and want to be contacted regarding its maintenance. Unmaintained files may be removed. This is for the full file, and you should not add yourself if you are just making minor changes or do not want to help maintain its contents.

For developers with write access

(OPTIONAL) I've updated aeon's CODEOWNERS to receive notifications about future changes to these files.

baraline

Thanks for working on this, the issue is a bit more complex than simply casting the output, we want the internal computation to be performed in the appropriate precision, to benefit from the reduced memory footprint.

I didn't comment on _dwt, _slope and _pla as the issues are the same that those pointed out in intervals.

If you need any pointers don't hesitate to ask questions.

baraline · 2026-08-25T15:03:37Z

+    [
+        (np.float32, np.float32),
+        (np.float64, np.float64),
+        (np.int64, np.float64),


need to also add int32, float64

baraline · 2026-08-25T15:06:01Z

-        return Xt
+        out_dtype = np.float32 if X.dtype == np.float32 else np.float64
+        return Xt.astype(dtype=out_dtype, copy=False)



We shouldn't neet to cast the input here, it must natively used float32 (or 64) in the generate intervals function.

What we want is that if we have a float 32 input, computation are made on float 32 to benefit from the reduced memory footprint (and computation time to some extent)

I removed final cast. The input is promoted once and interval buffers now use X.dtype, so float32 is preserved throughout the SupervisedIntervals.

baraline · 2026-08-25T15:07:10Z

+        out_dtype = np.float32 if X.dtype == np.float32 else np.float64
+        Xt = np.zeros((X.shape[0], len(transform)), dtype=out_dtype)


Same comment as above, we want the interval computation to use 32 bit precision, not simply cast the output.

So _transform_intervals itself should return the appropriate dtype already.

_transform_intervals now returns values in the working X.dtype, and _transform allocates its result directly with that dtype instead of correcting the dtype

baraline · 2026-08-25T15:07:32Z

+    [
+        (np.float32, np.float32),
+        (np.float64, np.float64),
+        (np.int64, np.float64),


similar to before, add int32, float64

baraline · 2026-08-25T15:07:52Z

+)
+def test_dwt_preserves_float_precision(dtype, expected_dtype):
+    """Check dwt preserves float32 and promotes proper dtype output."""
+    X = np.arange(16, dtype=dtype).reshape(2, 1, 8)


use the testing utils functions to generate testing data, as you did in the inerval tests (make_example_3d_numpy)

now uses make_example_3d_numpy

baraline · 2026-08-25T15:08:45Z

+    [
+        (np.float32, np.float32),
+        (np.float64, np.float64),
+        (np.int64, np.float64),


also int32, float64

baraline · 2026-08-25T15:08:57Z

+    [
+        (np.float32, np.float32),
+        (np.float64, np.float64),
+        (np.int64, np.float64),


also int32,float64

baraline · 2026-08-25T15:09:39Z

+    X = np.array(
+        [[[4, 6, 10, 12, 8, 6, 5, 5]]],
+        dtype=dtype,
+    )


again, use the testing utils to generate data

Updated to use make_example_3d_numpy

baraline · 2026-08-25T15:10:21Z

+        np.array([[0, 1, 2, 3]], dtype=dtype),
+        np.array([[0, 2, 4, 6, 8]], dtype=dtype),


I don't think the current testing util to generate variable length list allows dtype args, so this one is fine for now.

4nmus · 2026-08-30T19:41:33Z

Thank you for the review! I updated implementation so that computations itself preserve float32 within in _pla, _supervised_intervals and _slope. However, there is an issue within _supervised_intervals: row_* feature funcitons force float64 regardless of changes, it's already covered in #3724 / #3749 so I kept the SupervisedIntervals working arrays and interval buffers in X.dtype and just normalized feature outputs at that boundary. I also added fixedd and added int32 in tests. I hope that is what was missing.

baraline · 2026-09-01T12:26:18Z

Great ! Overall looks fine but I'll try to have a closer look at it this week.

Thanks for continuing to work on this.

baraline · 2026-09-01T13:45:52Z

@MatthewMiddlehurst, do you think it would be worth having a internal estimator attribute (would tag system be appropriate to declare the capability ?) with the input precision (32/64) set during fit and reused across all the estimator declarations ?
It would avoid using the same dtype everytime and would make a clean standard across all estimators to declare and use the precision.

We can set it during input preprocessing similarly to how @4nmus wrote it in the test :

internal_dtype = np.float32 if input_dtype == np.float32 else dtype = np.float64

[BUG] Preserve float32 dtype in affected transformers.

7a1e22e

4nmus requested review from MatthewMiddlehurst and TonyBagnall as code owners August 17, 2026 17:42

4nmus and others added 2 commits August 17, 2026 20:34

Preserve float32 dtype in SupervisedIntervals

b83634c

Merge branch 'main' into fix-float32-transformers-3723

c4737dd

baraline requested changes Aug 25, 2026

View reviewed changes

4nmus added 2 commits August 30, 2026 18:22

Merge branch 'main' into fix-float32-transformers-3723

ee0267e

Fixed float32 computation within: _supervised_intervals, _pla, _slope

6818aa2

4nmus requested a review from baraline August 30, 2026 19:59

Merge branch 'main' into fix-float32-transformers-3723

45504fb

		out_dtype = np.float32 if X.dtype == np.float32 else np.float64
		Xt = np.zeros((X.shape[0], len(transform)), dtype=out_dtype)

		np.array([[0, 1, 2, 3]], dtype=dtype),
		np.array([[0, 2, 4, 6, 8]], dtype=dtype),

Uh oh!

Conversation

4nmus commented Aug 17, 2026

Reference Issues/PRs

What does this implement/fix? Explain your changes.

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

Any other comments?

PR checklist

For all contributions

For new estimators and functions

For developers with write access

Uh oh!

baraline left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

4nmus commented Aug 30, 2026

Uh oh!

baraline commented Sep 1, 2026

Uh oh!

baraline commented Sep 1, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

baraline commented Sep 1, 2026 •

edited

Loading