Skip to content

fix: [branch-1.1] treat -0.0 and 0.0 as one value in arrays_overlap on Spark 4.0.5, 4.1.4 and 4.2.1 - #7265

Open
snmvaughan wants to merge 2 commits into
apache:branch-1.1from
snmvaughan:backport-6989-branch-1.1
Open

snmvaughan wants to merge 2 commits into
apache:branch-1.1from
snmvaughan:backport-6989-branch-1.1

Conversation

@snmvaughan

Copy link
Copy Markdown
Contributor

Which issue does this PR close?

Backport of #6989 (squash commit 3565f2f) to branch-1.1, for #6768.

Rationale for this change

branch-1.1 has the bug #6989 fixes on main. Spark 4.0.5, 4.1.4 and 4.2.1 normalize each flat FLOAT or DOUBLE element before arrays_overlap looks it up (SPARK-59602), so -0.0 and 0.0 are one value, and Spark 4.2.0 gets the same answer by normalizing the arguments in the plan (SPARK-54918). On branch-1.1, CometArraysOverlap treats floating-point elements as compatible and runs the native spark_arrays_overlap, which keeps the zeros apart. So on those releases arrays_overlap(array(0.0), array(-0.0)) returns false where Spark returns true, by default. See #6768.

What changes are included in this PR?

git cherry-pick -x of 3565f2f, adapted because branch-1.1 predates two changes #6989 builds on:

  • branch-1.1 has no ArraySetSupport.normalizesFloats (feat: normalize floats in native array_distinct and array_union #6563), so this adds it next to normalizesArgumentsInPlan, for arrays_overlap only. array_distinct and array_union keep branch-1.1's 4.2.0-only check.
  • arrays_overlap.rs takes normalize_float from math_funcs::internal and keeps branch-1.1's own NaN keying, since branch-1.1 predates the float_semantics module (refactor: move native -0.0 and NaN handling into one float_semantics module #6400). Otherwise the native change is the same: SparkArraysOverlap has a normalize_floats flag and is registered as both spark_arrays_overlap and spark_arrays_overlap_normalized, and CometArraysOverlap.nativeFunction picks the variant by the Spark version.
  • The new test pins the version boundaries itself, since branch-1.1 doesn't have the test that does on main.
  • The user-guide floating-point page gets the arrays_overlap section only. The contributor-guide pages are dropped, since that guide isn't published from release branches.

Backports to other branches: none for branch-1.2, which already has #6989.

How are these changes tested?

The native tests come with the cherry-pick, and the flat FLOAT and DOUBLE tests check both variants. On this branch, all 978 datafusion-comet-spark-expr unit tests pass, cargo fmt --check, cargo clippy --all-targets --workspace -- -D warnings and spotless are clean, and the Scala code compiles. I haven't run the Scala suites locally. arrays_overlap native variant by Spark version covers the version boundaries and the variant convert asks for.

…, 4.1.4 and 4.2.1 (apache#6989)

* fix: treat -0.0 and 0.0 as one value in arrays_overlap on Spark 4.0.5, 4.1.4 and 4.2.1

Spark 4.0.5, 4.1.4 and 4.2.1 normalize each flat FLOAT or DOUBLE element
before arrays_overlap looks it up in its hash set of boxed values
(SPARK-59602), so -0.0 and 0.0 are one value, as they already were on
4.2.0, which normalizes the arguments in the plan (SPARK-54918). The
native kernel kept the zeros apart on every version, so on those
releases it returned false where Spark returns true.

Register a second variant, spark_arrays_overlap_normalized, whose flat
float arms key elements by normalize_float instead of canonicalize_nan,
and have CometArraysOverlap pick it wherever
ArraySetSupport.normalizesFloats holds. Earlier releases keep the
existing kernel. Both variants treat every NaN as one value and compare
nested elements in Spark's SQL ordering.

Closes apache#6768.

* review: name the variant in arrays_overlap errors and trim the version table

Use self.name() in the unsupported-type errors so spark_arrays_overlap_normalized reports itself,
and test it on the array and scalar paths. Reduce the native docs to the two equality policies and
point at CometArraysOverlap.nativeFunction for the version mapping. Keep one Spark version on each
side of the boundary in the routing test and the convert assertion.

Adapted for branch-1.1:

- branch-1.1 has no ArraySetSupport.normalizesFloats (apache#6563), so this adds
  it next to normalizesArgumentsInPlan, for arrays_overlap only.
  array_distinct and array_union keep branch-1.1's 4.2.0-only check.
- arrays_overlap.rs takes normalize_float from math_funcs::internal and
  keeps branch-1.1's own NaN keying, since branch-1.1 predates the
  float_semantics module (apache#6400).
- The new test pins the version boundaries itself, since branch-1.1
  doesn't have the test that does on main.
- The user-guide floating-point page gets the arrays_overlap section only.
  The contributor-guide pages are dropped, since that guide isn't
  published from release branches.

(cherry picked from commit 3565f2f)
@github-actions github-actions Bot added bug Something isn't working area:expressions Expression evaluation labels Oct 27, 2026
@snmvaughan snmvaughan changed the title fix: [branch-1.1] treat -0.0 and 0.0 as one value in arrays_overlap on Spark 4.0.5, 4.1.4 and 4.2.1 fix: [branch-1.1] treat -0.0 and 0.0 as one value in arrays_overlap on Spark 4.0.5, 4.1.4 and 4.2.1 (#6989) Oct 27, 2026
@snmvaughan snmvaughan changed the title fix: [branch-1.1] treat -0.0 and 0.0 as one value in arrays_overlap on Spark 4.0.5, 4.1.4 and 4.2.1 (#6989) fix: [branch-1.1] treat -0.0 and 0.0 as one value in arrays_overlap on Spark 4.0.5, 4.1.4 and 4.2.1 Oct 27, 2026

@andygrove andygrove left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @snmvaughan

@andygrove
andygrove marked this pull request as ready for review October 27, 2026 22:48
@andygrove

Copy link
Copy Markdown
Member

@snmvaughan could you fix conflicts?

Resolves the import conflict with apache#7266 in CometArrayExpressionSuite: the
serde import takes both sides' names.

@comphead comphead left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @snmvaughan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area:expressions Expression evaluation bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants