Yaoxuan Wu created FLINK-40930:
----------------------------------
Summary: MIN/MAX on FLOAT/DOUBLE return NaN only if NaN is the
first input row (order-dependent result)
Key: FLINK-40930
URL: https://issues.apache.org/jira/browse/FLINK-40930
Project: Flink
Issue Type: Bug
Components: Table SQL / Runtime
Affects Versions: 2.3.0
Reporter: Yaoxuan Wu
MIN and MAX on DOUBLE give a different result for the same values depending on
whether NaN is the first input row:
{code:java}
SET 'parallelism.default' = '1';
SELECT MIN(x), MAX(x) FROM (SELECT CAST(s AS DOUBLE) AS x FROM (VALUES ('NaN'),
('-8'), ('7')) AS v(s));
-- NaN, NaN
SELECT MIN(x), MAX(x) FROM (SELECT CAST(s AS DOUBLE) AS x FROM (VALUES ('-8'),
('NaN'), ('7')) AS v(s));
-- -8, 7 {code}
With parallelism > 1 the result depends on which row each partition sees first.
Cause: `MinAggFunction` accumulates with `operand < min ? operand : min` (MAX
symmetrically with `>`). If NaN arrives first it becomes the accumulator and
stays, because every `x < NaN` is FALSE; if it arrives later, `NaN < min` is
FALSE and it is ignored.
Expected: MIN/MAX should treat NaN consistently, independent of the row order
(e.g. NaN as the largest value, as Spark and PostgreSQL do).
Related: FLINK-40927 (inconsistent NaN semantics across planner and runtime),
FLINK-40923.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
