Theodus opened a new issue, #24432: URL: https://github.com/apache/datafusion/issues/24432
### Describe the bug The optimized grouped accumulators for floating-point `MIN` and `MAX` use `partial_cmp` rather than the total ordering used by the non-grouped accumulators. Comparisons with NaN return `None`, causing the grouped update to overwrite the current value. The partial ordering also considers `+0.0` and `-0.0` equal, retaining whichever occurs first. As a result, grouped `MIN` and `MAX` can return different results depending on input order, batching, or partitioning. ### To Reproduce For one group, the optimized grouped accumulators produce these incorrect results (`NaN` is positive): ```text MAX([NaN, 1.0]) = 1.0 MIN([1.0, NaN]) = NaN MAX([-0.0, +0.0]) = -0.0 MIN([+0.0, -0.0]) = +0.0 ``` Reordering the same inputs changes the results. ### Expected behavior Grouped and non-grouped `MIN`/`MAX` should use the same deterministic total ordering for floating-point values. Under the ordering already used by `ScalarValue` and the non-grouped accumulators: ```text MAX([NaN, 1.0]) = NaN MIN([1.0, NaN]) = 1.0 MAX([-0.0, +0.0]) = +0.0 MIN([+0.0, -0.0]) = -0.0 ``` Results should not depend on row order, batch boundaries, or partitioning. ### Additional context The grouped Float16, Float32, and Float64 accumulators should use `total_cmp`, matching the non-grouped implementation. Their initial values must also be the extrema of the total ordering: the finite `MIN`/`MAX` constants are not valid identities when infinities and NaNs are included. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
