sunchao opened a new issue, #5468:
URL: https://github.com/apache/datafusion-comet/issues/5468

   ### Describe the bug
   
   Native `WindowGroupLimitExec` can drop rows that Spark retains when a scalar 
`FLOAT` or `DOUBLE` ordering key contains different NaN representations or both 
zero signs. This is a follow-up to #4870.
   
   Spark considers all NaNs equal and greater than non-NaN values, and treats 
`-0.0` and `+0.0` as equal. Arrow row encoding compares their raw total-order 
representations instead. Consequently, native `RANK` / `DENSE_RANK` cutoffs can 
split one Spark peer group. Native sorting also needs to agree: with a 
secondary ordering key, sorting by raw NaN payload or zero sign can make equal 
peers noncontiguous.
   
   ### Steps to reproduce
   
   On Spark 3.5 or later, enable native execution and 
`spark.comet.exec.localTableScan.enabled=true`, keeping 
`spark.comet.exec.strictFloatingPoint=false`.
   
   Build a local table with runtime NaNs, for example 
`java.lang.Double.longBitsToDouble(0x7ff8000000000001L)` and 
`java.lang.Double.longBitsToDouble(0xfff8000000000002L)`, plus finite values 
and a partition containing both zero signs. Avoid a Parquet round trip that can 
canonicalize NaN payloads. Filter a query of this shape to its top rank:
   
   ```sql
   SELECT * FROM (
     SELECT *, RANK() OVER (PARTITION BY p ORDER BY v DESC NULLS LAST) AS rnk
     FROM floating_window_peers
   ) WHERE rnk <= 1
   ```
   
   A regression fixture retaining eight rows in Spark returns only four in 
unpatched Comet. This reproduces for both `FLOAT` and `DOUBLE` with native 
Sort, Window, and WindowGroupLimit operators. Adding a secondary ordering key 
also exposes the sorting inconsistency.
   
   ### Expected behavior
   
   Scalar floating-point sort keys, window peer comparisons, and native 
range-partition keys/boundaries should use consistent Spark-compatible 
normalization. Only comparison keys should change; returned values must 
preserve their original NaN payloads and zero signs.
   
   ### Additional context
   
   The existing strict-floating-point fallback remains an opt-out. 
Floating-point values nested in arrays or structs are a separate compatibility 
limitation.
   


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