getChan opened a new pull request, #23809:
URL: https://github.com/apache/datafusion/pull/23809

   ## Which issue does this PR close?
   
   - Closes #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 `Int32 -> 
Float32`, `UInt32 -> Float32`, `Int64 -> Float64`, and `UInt64 -> Float64` as 
widening casts.
   
   However, integer-to-float conversions for 32-bit and 64-bit integers lose 
precision when values exceed the mantissa bit limit (24 bits for `Float32`, 53 
bits for `Float64`). For example:
   `16_777_216_i32 as f32 == 16_777_217_i32 as f32` (both yield 16777216.0f32).
   
   Because distinct integer inputs can collapse to the same float output, these 
casts are not strictly 1-to-1 (injective) and can break suffix sort key 
ordering in multi-column ordering analysis (e.g. `[CAST(a AS Float32), b]`).
   
   ## What changes are included in this PR?
   
   - Updated `CastExpr::check_bigger_cast` to exclude precision-losing 
integer-to-float conversions (`Int32/UInt32 -> Float32` and `Int64/UInt64 -> 
Float64`).
   - Added unit test `test_check_bigger_cast_precision_loss` to verify 
precision-losing casts return `false` while exact conversions (`Int16 -> 
Float32`, `Int32 -> Float64`, etc.) continue to return `true`.
   
   ## Are these changes tested?
   
   Yes, new unit test `test_check_bigger_cast_precision_loss` in `cast.rs`.
   
   ## Are there any user-facing changes?
   
   No breaking API changes. Internal optimizer behavior fix.
   


-- 
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]

Reply via email to