mbutrovich opened a new issue, #11597: URL: https://github.com/apache/arrow-rs/issues/11597
### Describe the bug The rustdoc of `arrow_arith::aggregate::min` and `max` says "any NaN values are considered to be greater than any other non-null value" ([aggregate.rs](https://github.com/apache/arrow-rs/blob/72887ed91c80002bb7ec755ce1e964bab07bebea/arrow-arith/src/aggregate.rs#L990-L992), [aggregate.rs](https://github.com/apache/arrow-rs/blob/72887ed91c80002bb7ec755ce1e964bab07bebea/arrow-arith/src/aggregate.rs#L1005-L1007)). The kernels compare with IEEE 754 totalOrder, as #5031 decided and as `ArrowNativeTypeOp` documents ([arithmetic.rs](https://github.com/apache/arrow-rs/blob/72887ed91c80002bb7ec755ce1e964bab07bebea/arrow-array/src/arithmetic.rs#L38-L39)). Under totalOrder a NaN with the sign bit set is below every other value. So `min` returns it, and `max` never does. ### To Reproduce ```rust use arrow_arith::aggregate::{max, min}; use arrow_array::Float64Array; fn main() { let neg_nan = f64::from_bits(f64::NAN.to_bits() | (1 << 63)); let a = Float64Array::from(vec![1.0, neg_nan, f64::NEG_INFINITY]); let m = min(&a).unwrap(); println!("min = {m} (sign bit {}), max = {:?}", m.is_sign_negative(), max(&a)); // min = NaN (sign bit true), max = Some(1.0) } ``` ### Expected behavior The rustdoc describes what the kernels do. For example: "Floating point values are compared by IEEE 754 totalOrder (see [`f64::total_cmp`]), so a positive NaN is greater than any other value and a negative NaN is less than any other value." ### Additional context The behavior matches #5031, so this is a documentation fix only. Found with property-based tests that build arrays in every physical layout the Arrow format allows. -- 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]
