Skip to content

Fix mixed numeric extrema - #806

Open
mattfaltyn wants to merge 1 commit into
knowsys:mainfrom
mattfaltyn:fix-mixed-numeric-minmax
Open

Fix mixed numeric extrema#806
mattfaltyn wants to merge 1 commit into
knowsys:mainfrom
mattfaltyn:fix-mixed-numeric-minmax

Conversation

@mattfaltyn

Copy link
Copy Markdown
Contributor

Summary

  • compare mixed Int64, Float, and Double inputs to #min and #max by numeric value
  • promote mixed numeric extrema to Double, matching Nemo's existing numeric promotion behavior
  • preserve same-type and nonnumeric aggregate ordering
  • cover every mixed numeric type pair, both magnitude orientations, and both input orders

Why

#min and #max compared StorageValueT directly. Its ordering groups values by storage variant, so mixed numeric aggregates could silently return the wrong value: for example, #min(10, 1.0) returned 10, while #max(10, 1.0) returned 1.0.

The fix is scoped to extrema aggregation so storage and sorting behavior that relies on the global StorageValueT ordering remains unchanged.

Fixes #805.

Testing

  • cargo test --verbose
  • RUSTFLAGS=-Dwarnings cargo clippy --all-targets --workspace --verbose
  • cargo fmt --all -- --check
  • RUSTFLAGS=-Dwarnings RUSTDOCFLAGS=-Dwarnings cargo doc --workspace
  • cargo test --offline --workspace aggregates::processors::processor::test
  • reproduced the original program through nemo-cli and confirmed min = 1.0, max = 10.0

@github-project-automation github-project-automation Bot moved this to Todo in nemo Aug 16, 2026
@mattfaltyn
mattfaltyn marked this pull request as ready for review August 16, 2026 19:22
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

Status: Todo

Development

Successfully merging this pull request may close these issues.

Mixed numeric #min/#max compare storage types instead of values

1 participant