getChan opened a new issue, #23808: URL: https://github.com/apache/datafusion/issues/23808
### Rationale for this change `CastExpr::check_bigger_cast` is used to determine whether a cast is a widening (order-preserving) conversion. Currently, it classifies all `(Int8 | Int16 | Int32 | UInt8 | UInt16 | UInt32) -> (Float32 | Float64)` and `(Int64 | UInt64) -> Float64` as widening casts. However, integer-to-float conversions can lose precision when the integer value exceeds the mantissa bit limit (24 bits for `Float32`, 53 bits for `Float64`). For example, `Int32 -> Float32` loses precision for integers greater than 2^24 (16,777,216): ```rust assert_eq!(16_777_216_i32 as f32, 16_777_217_i32 as f32); // true! (both yield 16777216.0f32) ``` Because distinct integer inputs can collapse to the same float output, these casts are **not strictly 1-to-1 (injective)**. When used in multi-column ordering analysis (e.g. `[CAST(a AS Float32), b]`), this value collapse can invalidate the ordering of subsequent sort keys (`b`). ### What changes should be made? Modify `CastExpr::check_bigger_cast` to only treat integer-to-float conversions without precision loss as widening casts: - `Float32` (24-bit mantissa): Allow `Int8`, `Int16`, `UInt8`, `UInt16` (<= 16 bits). Exclude `Int32`, `UInt32`. - `Float64` (53-bit mantissa): Allow `Int8`, `Int16`, `Int32`, `UInt8`, `UInt16`, `UInt32` (<= 32 bits). Exclude `Int64`, `UInt64`. ```rust // Proposed change in CastExpr::check_bigger_cast | (Int8 | Int16 | UInt8 | UInt16, Float32) | (Int8 | Int16 | Int32 | UInt8 | UInt16 | UInt32, Float64) ``` ### Are there any breaking changes? No breaking API changes. This improves optimizer soundness by preventing invalid sort substitution when precision loss occurs. ### Reference Discussion: https://github.com/apache/datafusion/pull/23807#discussion_r3632161143 -- 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]
